[Bug 98874] Desktop suddenly freezes, login via ssh possible, no error messages, unable to power off
https://bugs.freedesktop.org/show_bug.cgi?id=98874 --- Comment #6 from Michel Dänzer --- Please attach the output of glxinfo. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/608d0f89/attachment.html>
Question regarding clocks in the DW-HDMI DT bindings
Hi Mike, On Monday 28 Nov 2016 13:56:11 Michael Turquette wrote: > On Fri, Nov 25, 2016 at 7:22 AM, Laurent Pinchart wrote: > > On Friday 25 Nov 2016 10:56:53 Andy Yan wrote: > >> On 2016å¹´11æ25æ¥ 07:26, Laurent Pinchart wrote: > >>> On Friday 25 Nov 2016 00:16:00 Vladimir Zapolskiy wrote: > On 11/25/2016 12:07 AM, Fabio Estevam wrote: > > On Thu, Nov 24, 2016 at 7:16 PM, Laurent Pinchart wrote: > >> Hi Andy, > >> > >> As the author of the DW-HDMI DT bindings this question is addressed > >> to you, but information from anyone is more than welcome. > >> > >> The DT bindings specify two clocks named "iahb" and "isfr" but don't > >> describe them. While I assume that the "isfr" clock corresponds to > >> the "isfrclk" input signal of the DW HDMI, there is no "iahb" clock > >> described in the IP core datasheet. > > > > i.MX6Q has a DW-HDMI IP block. > > > > The names in the devicetree binding matches the ones listed at the > > i.MX6Q Reference Manual - Table 33-1. HDMI Clocks > > correct, for your convenience the table is copied below: > > Clock name | Clock Root | Description > ---++- > iahbclk | ahb_clk_root | Bus clock > icecclk | ckil_sync_clk_root | CEC low-frequency clock (32kHZ) > ihclk| ahb_clk_root | Module clock > isfrclk | video_27m_clk_root | Internal SFR clock (video clock > 27MHz) > > Here AHB stands for ARM Advanced High-performance Bus. > >>> > >>> That's what I suspected. I believe the "iahb" name is wrong, as the DW > >>> HDMI TX IP core clearly documents the bus clock as being called > >>> "iapbclk". We could rename that in the DT bindings (with compatibility > >>> code in the driver to keep supporting the old name) but it might not be > >>> worth it. The bindings should however document that the "iahb" clock is > >>> the IP core's "iapbclk" bus clock. > >> > >> I got the clock name from I.MX6Q TRM, I also checked the name again > >> with Rockchip IC design team now, hope to get some new information soon. > > > > Thank you. While at it, could you ask them which version of the DW HDMI IP > > used in the SoC ? > > > >>> Another question I have about the bus clock (CC'ing the devicetree > >>> mailing list as well as the clock maintainers) is whether it should be > >>> made optional. The clock is obviously mandatory from a hardware point > >>> of view (given that APB is a synchronous bus and thus requires a > >>> clock), but in some SoCs (specifically for the Renesas SoCs) that clock > >>> is always on and can't be controlled. We already omit bus clocks in DT > >>> for most IP cores when the clock can never be controlled (and we also > >>> omit a bunch of other clocks that we don't even know exist), so it > >>> could make sense to make the clock optional. Otherwise there would be > >>> runtime overhead trying to handle a clock that can't be controlled. > >> > >> If this is the case on Renesas SOCs, we can consider make the clock as > >> optional. Or move all the clock operations to platform specific > >> code(dw_hdmi-rockchip.c/dw_hdmi-imx.c)? > > > > I'd prefer keeping the code generic, otherwise we'd end up with platform- > > specific code that would perform the same operations on most platforms. > > I'll submit a patch soon to make the clock optional, we can discuss it > > then. > > Yes, let's keep the code generic. Absence of a "standard' clock is OK > and we should accept the small overhead incurred in providing a > solution that works for everyone. This prevents hardware-specific > hacks in the driver. > > Related: we really should model bus clocks whenever possible. I've > seen other attempts to merge functional/logic and bus clocks into a > single entity (e.g. a single struct clk_hw/clk_core that turns both > clocks on and off) and this defeats some fine-grained power management > scenarios that the hardware designers had in mind when creating > separate controls for the clocks. Sure, but that wasn't really the question :-) When the bus clock is separately controllable then I agree it should be modelled separately in DT. In my case the bus clock is always on, and I'm thus wondering whether it would be better to make it optional in DT to reduce the runtime overhead incurred by trying to control something that can't be controlled. > By the way while we're discussing DW HDMI bindings specific to iMX, > I would recommend to remove utterly hackish and iMX only "gpr" > property from the example in bindings/display/bridge/dw_hdmi.txt -- Regards, Laurent Pinchart
[PATCH v3 0/2] drm/bridge: adv7511: Enable regulators
The patch below added regulator supplies to the ADV533 HDMI bridge on the DB410c, but the corresponding DT binding doc wasn't updated to list them: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=28546b09551190c727c94d1c5c96ca609065beb2 The first patch adds the regulator supply props to the binding docs for both ADV7511 and ADV7533. The second patch updates the drm bridge driver to enable these regulators. Changes in v3: - Revert back to having a common supply for AVDD, DVDD, PVDD pins. - Dropped the DB410c DT patches. Changes in v2: - Provide the regulator supply for ADV7511 too in the binding docs. - Update the driver to manage regulators for both ADV7511 and ADV7533. - Have separate supply entries for AVDD, DVDD, PVDD, A2VDD pins. - Use regulator_bulk_* API to configure regulators. Archit Taneja (2): dt-bindings: drm/bridge: adv7511: Add regulator bindings drm/bridge: adv7511: Initialize regulators .../bindings/display/bridge/adi,adv7511.txt| 9 +++ drivers/gpu/drm/bridge/adv7511/adv7511.h | 4 ++ drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 79 +++--- 3 files changed, 83 insertions(+), 9 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH v3 2/2] drm/bridge: adv7511: Initialize regulators
Maintain a table of regulator names expect by ADV7511 and ADV7533.
Use regulator_bulk_* api to configure these.
Initialize and enable the regulators during probe itself. Controlling
these dynamically is left for later.
Signed-off-by: Archit Taneja
---
v3:
- Drop the additional 1.8V supply names
drivers/gpu/drm/bridge/adv7511/adv7511.h | 4 ++
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 79
2 files changed, 74 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 992d76c..18ec627 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -329,6 +330,9 @@ struct adv7511 {
struct gpio_desc *gpio_pd;
+ struct regulator_bulk_data *supplies;
+ int num_supplies;
+
/* ADV7533 DSI RX related params */
struct device_node *host_node;
struct mipi_dsi_device *dsi;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 2177440..f123fbb 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -843,6 +843,51 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge)
* Probe & remove
*/
+static const char * const adv7511_supply_names[] = {
+ "avdd",
+ "v3p3",
+};
+
+static const char * const adv7533_supply_names[] = {
+ "avdd",
+ "v3p3",
+ "v1p2",
+};
+
+static int adv7511_init_regulators(struct adv7511 *adv)
+{
+ struct device *dev = &adv->i2c_main->dev;
+ const char * const *supply_names;
+ int i, ret;
+
+ if (adv->type == ADV7511) {
+ supply_names = adv7511_supply_names;
+ adv->num_supplies = ARRAY_SIZE(adv7511_supply_names);
+ } else {
+ supply_names = adv7533_supply_names;
+ adv->num_supplies = ARRAY_SIZE(adv7533_supply_names);
+ }
+
+ adv->supplies = devm_kcalloc(dev, adv->num_supplies,
+sizeof(*adv->supplies), GFP_KERNEL);
+ if (!adv->supplies)
+ return -ENOMEM;
+
+ for (i = 0; i < adv->num_supplies; i++)
+ adv->supplies[i].supply = supply_names[i];
+
+ ret = devm_regulator_bulk_get(dev, adv->num_supplies, adv->supplies);
+ if (ret)
+ return ret;
+
+ return regulator_bulk_enable(adv->num_supplies, adv->supplies);
+}
+
+static void adv7511_uninit_regulators(struct adv7511 *adv)
+{
+ regulator_bulk_disable(adv->num_supplies, adv->supplies);
+}
+
static int adv7511_parse_dt(struct device_node *np,
struct adv7511_link_config *config)
{
@@ -943,6 +988,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
if (!adv7511)
return -ENOMEM;
+ adv7511->i2c_main = i2c;
adv7511->powered = false;
adv7511->status = connector_status_disconnected;
@@ -960,13 +1006,21 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
if (ret)
return ret;
+ ret = adv7511_init_regulators(adv7511);
+ if (ret) {
+ dev_err(dev, "failed to init regulators\n");
+ return ret;
+ }
+
/*
* The power down GPIO is optional. If present, toggle it from active to
* inactive to wake up the encoder.
*/
adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd", GPIOD_OUT_HIGH);
- if (IS_ERR(adv7511->gpio_pd))
- return PTR_ERR(adv7511->gpio_pd);
+ if (IS_ERR(adv7511->gpio_pd)) {
+ ret = PTR_ERR(adv7511->gpio_pd);
+ goto uninit_regulators;
+ }
if (adv7511->gpio_pd) {
mdelay(5);
@@ -974,12 +1028,14 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
}
adv7511->regmap = devm_regmap_init_i2c(i2c, &adv7511_regmap_config);
- if (IS_ERR(adv7511->regmap))
- return PTR_ERR(adv7511->regmap);
+ if (IS_ERR(adv7511->regmap)) {
+ ret = PTR_ERR(adv7511->regmap);
+ goto uninit_regulators;
+ }
ret = regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, &val);
if (ret)
- return ret;
+ goto uninit_regulators;
dev_dbg(dev, "Rev. %d\n", val);
if (adv7511->type == ADV7511)
@@ -989,7 +1045,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
else
ret = adv7533_patch_registers(adv7511);
if (ret)
- return ret;
+ goto uninit_regulators;
regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, edid_i2c_addr);
regmap_write(adv7511->regma
[PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings
Add the regulator supply properties needed by ADV7511 and ADV7533. The regulators are specified as optional properties since there can be boards which have a fixed supply directly routed to the pins, and these may not be modelled as regulator supplies. Cc: devicetree at vger.kernel.org Acked-by: Rob Herring Signed-off-by: Archit Taneja --- v3: - Revert back to having a common avdd-supply property for the 1.8V supplies Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt index 6532a59..13d53bc 100644 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt @@ -56,6 +56,15 @@ Optional properties: - adi,disable-timing-generator: Only for ADV7533. Disables the internal timing generator. The chip will rely on the sync signals in the DSI data lanes, rather than generate its own timings for HDMI output. +- avdd-supply: A common 1.8V supply that powers up the AVDD, DVDD and PVDD + pins. On ADV7511, it also feeds to the BGVDD pin. On ADV7533, it also powers + up the A2VDD pin. +- v3p3-supply: A 3.3V supply that powers up the pin called DVDD_3V on + ADV7511 and V3P3 on ADV7533. + +ADV7533 specific supplies: +- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be + either 1.2V or 1.8V. Required nodes: -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH v3 2/2] drm/bridge: adv7511: Initialize regulators
Hi Archit,
Thank you for the patch.
On Tuesday 29 Nov 2016 11:37:42 Archit Taneja wrote:
> Maintain a table of regulator names expect by ADV7511 and ADV7533.
> Use regulator_bulk_* api to configure these.
>
> Initialize and enable the regulators during probe itself. Controlling
> these dynamically is left for later.
>
> Signed-off-by: Archit Taneja
> ---
> v3:
> - Drop the additional 1.8V supply names
>
> drivers/gpu/drm/bridge/adv7511/adv7511.h | 4 ++
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 79 +
> 2 files changed, 74 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h index 992d76c..18ec627 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -329,6 +330,9 @@ struct adv7511 {
>
> struct gpio_desc *gpio_pd;
>
> + struct regulator_bulk_data *supplies;
> + int num_supplies;
num_supplies is always positive, you can make it an unsigned int.
> +
> /* ADV7533 DSI RX related params */
> struct device_node *host_node;
> struct mipi_dsi_device *dsi;
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 2177440..f123fbb
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -843,6 +843,51 @@ static int adv7511_bridge_attach(struct drm_bridge
> *bridge) * Probe & remove
> */
>
> +static const char * const adv7511_supply_names[] = {
> + "avdd",
> + "v3p3",
> +};
> +
> +static const char * const adv7533_supply_names[] = {
> + "avdd",
> + "v3p3",
> + "v1p2",
> +};
> +
> +static int adv7511_init_regulators(struct adv7511 *adv)
> +{
> + struct device *dev = &adv->i2c_main->dev;
> + const char * const *supply_names;
> + int i, ret;
Same comment for i.
Apart from that,
Reviewed-by: Laurent Pinchart
> +
> + if (adv->type == ADV7511) {
> + supply_names = adv7511_supply_names;
> + adv->num_supplies = ARRAY_SIZE(adv7511_supply_names);
> + } else {
> + supply_names = adv7533_supply_names;
> + adv->num_supplies = ARRAY_SIZE(adv7533_supply_names);
> + }
> +
> + adv->supplies = devm_kcalloc(dev, adv->num_supplies,
> + sizeof(*adv->supplies), GFP_KERNEL);
> + if (!adv->supplies)
> + return -ENOMEM;
> +
> + for (i = 0; i < adv->num_supplies; i++)
> + adv->supplies[i].supply = supply_names[i];
> +
> + ret = devm_regulator_bulk_get(dev, adv->num_supplies, adv->supplies);
> + if (ret)
> + return ret;
> +
> + return regulator_bulk_enable(adv->num_supplies, adv->supplies);
> +}
> +
> +static void adv7511_uninit_regulators(struct adv7511 *adv)
> +{
> + regulator_bulk_disable(adv->num_supplies, adv->supplies);
> +}
> +
> static int adv7511_parse_dt(struct device_node *np,
> struct adv7511_link_config *config)
> {
> @@ -943,6 +988,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
> struct i2c_device_id *id) if (!adv7511)
> return -ENOMEM;
>
> + adv7511->i2c_main = i2c;
> adv7511->powered = false;
> adv7511->status = connector_status_disconnected;
>
> @@ -960,13 +1006,21 @@ static int adv7511_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id) if (ret)
> return ret;
>
> + ret = adv7511_init_regulators(adv7511);
> + if (ret) {
> + dev_err(dev, "failed to init regulators\n");
> + return ret;
> + }
> +
> /*
>* The power down GPIO is optional. If present, toggle it from active
to
>* inactive to wake up the encoder.
>*/
> adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd", GPIOD_OUT_HIGH);
> - if (IS_ERR(adv7511->gpio_pd))
> - return PTR_ERR(adv7511->gpio_pd);
> + if (IS_ERR(adv7511->gpio_pd)) {
> + ret = PTR_ERR(adv7511->gpio_pd);
> + goto uninit_regulators;
> + }
>
> if (adv7511->gpio_pd) {
> mdelay(5);
> @@ -974,12 +1028,14 @@ static int adv7511_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id) }
>
> adv7511->regmap = devm_regmap_init_i2c(i2c, &adv7511_regmap_config);
> - if (IS_ERR(adv7511->regmap))
> - return PTR_ERR(adv7511->regmap);
> + if (IS_ERR(adv7511->regmap)) {
> + ret = PTR_ERR(adv7511->regmap);
> + goto uninit_regulators;
> + }
>
> ret = regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, &val);
> if (ret)
> - return ret;
> + goto uninit_regulators;
> dev_dbg(dev, "Rev. %d\n", val);
>
> if (adv7511->type == ADV7511)
> @@ -989,7 +1045,7 @@ sta
[PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings
Hi Archit, Thank you for the patch. On Tuesday 29 Nov 2016 11:37:41 Archit Taneja wrote: > Add the regulator supply properties needed by ADV7511 and ADV7533. > > The regulators are specified as optional properties since there can > be boards which have a fixed supply directly routed to the pins, and > these may not be modelled as regulator supplies. That's why we have support for dummy supplies in the kernel, isn't it ? Isn't it better to make the supplies mandatory in the bindings (and obviously handling them as optional in the driver for backward-compatibility) ? Apart from that, Acked-by: Laurent Pinchart > Cc: devicetree at vger.kernel.org > Acked-by: Rob Herring > Signed-off-by: Archit Taneja > --- > v3: > - Revert back to having a common avdd-supply property for the 1.8V > supplies > > Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 9 ++ > 1 file changed, 9 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt > b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt index > 6532a59..13d53bc 100644 > --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt > +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt > @@ -56,6 +56,15 @@ Optional properties: > - adi,disable-timing-generator: Only for ADV7533. Disables the internal > timing generator. The chip will rely on the sync signals in the DSI data > lanes, rather than generate its own timings for HDMI output. > +- avdd-supply: A common 1.8V supply that powers up the AVDD, DVDD and PVDD > + pins. On ADV7511, it also feeds to the BGVDD pin. On ADV7533, it also > powers > + up the A2VDD pin. > +- v3p3-supply: A 3.3V supply that powers up the pin called DVDD_3V on > + ADV7511 and V3P3 on ADV7533. > + > +ADV7533 specific supplies: > +- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be > + either 1.2V or 1.8V. > > Required nodes: -- Regards, Laurent Pinchart
[RFC][PATCH 1/5 v2] drm/bridge: adv7511: Use work_struct to defer hotplug handing to out of irq context
Hi John,
Thank you for the patch.
On Monday 28 Nov 2016 21:04:40 John Stultz wrote:
> I was recently seeing issues with EDID probing, where
> the logic to wait for the EDID read bit to be set by the
> IRQ wasn't happening and the code would time out and fail.
>
> Digging deeper, I found this was due to the fact that
> IRQs were disabled as we were running in IRQ context from
> the HPD signal.
>
> Thus this patch changes the logic to handle the HPD signal
> via a work_struct so we can be out of irq context.
>
> With this patch, the EDID probing on hotplug does not time
> out.
>
> Cc: David Airlie
> Cc: Archit Taneja
> Cc: Wolfram Sang
> Cc: Lars-Peter Clausen
> Cc: Laurent Pinchart
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> v2: Reworked to properly fix the issue rather then
> just delaying for 200ms
>
> drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 ++
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 12 +++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h index 992d76c..2a1e722 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -317,6 +317,8 @@ struct adv7511 {
> bool edid_read;
>
> wait_queue_head_t wq;
> + struct work_struct irq_work;
> +
I'd call this hpd_work.
> struct drm_bridge bridge;
> struct drm_connector connector;
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 8dba729..b38e743
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -402,6 +402,14 @@ static bool adv7511_hpd(struct adv7511 *adv7511)
> return false;
> }
>
> +static void adv7511_irq_work(struct work_struct *work)
> +{
> + struct adv7511 *adv7511 = container_of(work, struct adv7511,
irq_work);
> +
> + drm_helper_hpd_irq_event(adv7511->connector.dev);
> +}
> +
> +
One blank line is enough.
Apart from that,
Reviewed-by: Laurent Pinchart
> static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd)
> {
> unsigned int irq0, irq1;
> @@ -419,7 +427,7 @@ static int adv7511_irq_process(struct adv7511 *adv7511,
> bool process_hpd) regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
>
> if (process_hpd && irq0 & ADV7511_INT0_HPD && adv7511->bridge.encoder)
> - drm_helper_hpd_irq_event(adv7511->connector.dev);
> + schedule_work(&adv7511->irq_work);
>
> if (irq0 & ADV7511_INT0_EDID_READY || irq1 & ADV7511_INT1_DDC_ERROR) {
> adv7511->edid_read = true;
> @@ -1006,6 +1014,8 @@ static int adv7511_probe(struct i2c_client *i2c, const
> struct i2c_device_id *id) goto err_i2c_unregister_edid;
> }
>
> + INIT_WORK(&adv7511->irq_work, adv7511_irq_work);
> +
> if (i2c->irq) {
> init_waitqueue_head(&adv7511->wq);
--
Regards,
Laurent Pinchart
[RFC][PATCH 2/5 v2] drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event()
Hi John,
Thank you for the patch.
On Monday 28 Nov 2016 21:04:41 John Stultz wrote:
> In chasing down a previous issue with EDID probing from calling
> drm_helper_hpd_irq_event() from irq context, Laurent noticed
> that the DRM documentation suggests that
> drm_kms_helper_hotplug_event() should be used instead.
>
> Thus this patch replaces drm_helper_hpd_irq_event() with
> drm_kms_helper_hotplug_event().
>
> Cc: David Airlie
> Cc: Archit Taneja
> Cc: Wolfram Sang
> Cc: Lars-Peter Clausen
> Cc: Laurent Pinchart
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index b38e743..2caca0c
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -406,7 +406,7 @@ static void adv7511_irq_work(struct work_struct *work)
> {
> struct adv7511 *adv7511 = container_of(work, struct adv7511,
irq_work);
>
> - drm_helper_hpd_irq_event(adv7511->connector.dev);
> + drm_kms_helper_hotplug_event(adv7511->connector.dev);
That's nice, but you must first update adv7511->connector.status (and as an
optimization only call drm_kms_helper_hotplug_event() if the status has
changed).
> }
--
Regards,
Laurent Pinchart
[Bug 98874] Desktop suddenly freezes, login via ssh possible, no error messages, unable to power off
https://bugs.freedesktop.org/show_bug.cgi?id=98874 --- Comment #7 from Matthias Nagel --- Created attachment 128261 --> https://bugs.freedesktop.org/attachment.cgi?id=128261&action=edit glxinfo -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/1c8a441d/attachment.html>
[Bug 98874] Desktop suddenly freezes, login via ssh possible, no error messages, unable to power off
https://bugs.freedesktop.org/show_bug.cgi?id=98874 Matthias Nagel changed: What|Removed |Added Attachment #128253|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/88c35dc6/attachment.html>
[PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings
On 11/29/2016 12:03 PM, Laurent Pinchart wrote: > Hi Archit, > > Thank you for the patch. > > On Tuesday 29 Nov 2016 11:37:41 Archit Taneja wrote: >> Add the regulator supply properties needed by ADV7511 and ADV7533. >> >> The regulators are specified as optional properties since there can >> be boards which have a fixed supply directly routed to the pins, and >> these may not be modelled as regulator supplies. > > That's why we have support for dummy supplies in the kernel, isn't it ? Isn't > it better to make the supplies mandatory in the bindings (and obviously > handling them as optional in the driver for backward-compatibility) ? I'm a bit unclear on this. I thought we couldn't add mandatory properties once the device is already present in DT for one or more platforms. Say, if we do make it mandatory for future additions, we would need to have DT property for the supplies for the new platforms. If the regulators on these boards are fixed supplies, they would be need to be modeled using "regulator-fixed", possibly without any input supply. Is that what you're suggesting? Thanks, Archit > > Apart from that, > > Acked-by: Laurent Pinchart > >> Cc: devicetree at vger.kernel.org >> Acked-by: Rob Herring >> Signed-off-by: Archit Taneja >> --- >> v3: >> - Revert back to having a common avdd-supply property for the 1.8V >> supplies >> >> Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 9 ++ >> 1 file changed, 9 insertions(+) >> >> diff --git >> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt >> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt index >> 6532a59..13d53bc 100644 >> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt >> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt >> @@ -56,6 +56,15 @@ Optional properties: >> - adi,disable-timing-generator: Only for ADV7533. Disables the internal >> timing generator. The chip will rely on the sync signals in the DSI data >> lanes, rather than generate its own timings for HDMI output. >> +- avdd-supply: A common 1.8V supply that powers up the AVDD, DVDD and PVDD >> + pins. On ADV7511, it also feeds to the BGVDD pin. On ADV7533, it also >> powers >> + up the A2VDD pin. >> +- v3p3-supply: A 3.3V supply that powers up the pin called DVDD_3V on >> + ADV7511 and V3P3 on ADV7533. >> + >> +ADV7533 specific supplies: >> +- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be >> + either 1.2V or 1.8V. >> >> Required nodes: > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v2 01/13] devicetree/bindings: display: Document common panel properties
Hi Rob, On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart wrote: > On Monday 21 Nov 2016 10:48:15 Rob Herring wrote: > > On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote: > >> Document properties common to several display panels in a central > >> location that can be referenced by the panel device tree bindings. > > > > Looks good. Just one comment... > > > > [...] > > > >> +Connectivity > >> + > >> + > >> +- ports: Panels receive video data through one or multiple connections. > >> While > >> + the nature of those connections is specific to the panel type, the > >> + connectivity is expressed in a standard fashion using ports as > >> specified in > >> + the device graph bindings defined in > >> + Documentation/devicetree/bindings/graph.txt. > > > > We allow panels to either use graph binding or be a child of the display > > controller. > > I knew that some display controllers use a phandle to the panel (see the > fsl,panel and nvidia,panel properties), but I didn't know we had panels as > children of display controller nodes. I don't think we should allow that for > anything but DSI panels, as the DT hierarchy is based on control buses. Are > you sure we have other panels instantiated through that mechanism ? Ping ? Please note that this file documents properties common to multiple panel DT bindings, but in no way makes it mandatory to use the OF graph bindings for panels. The decision is left to individual bindings. > > Using the graph is preferred, but in the simple cases just a child node is > > sufficient. This should be described here or somewhere in this doc. -- Regards, Laurent Pinchart
[RFC PATCH 1/3] drm: Add support for Amlogic Meson Graphic Controller
Hi Neil,
On Mon, Nov 28, 2016 at 10:34:58AM +0100, Neil Armstrong wrote:
> On 11/28/2016 09:16 AM, Daniel Vetter wrote:
> > On Fri, Nov 25, 2016 at 05:03:09PM +0100, Neil Armstrong wrote:
> >> +static void meson_cvbs_encoder_disable(struct drm_encoder *encoder)
> >> +{
> >> + struct meson_cvbs *meson_cvbs = encoder_to_meson_cvbs(encoder);
> >> +
> >> + meson_venci_cvbs_disable(meson_cvbs->priv);
> >> +}
> >> +
> >> +static void meson_cvbs_encoder_enable(struct drm_encoder *encoder)
> >> +{
> >> + struct meson_cvbs *meson_cvbs = encoder_to_meson_cvbs(encoder);
> >> +
> >> + meson_venci_cvbs_enable(meson_cvbs->priv);
> >> +}
> >
> > Personally I'd remove the indirection above, more direct code is easier to
> > read.
>
> I understand, I'll maybe change the meson_venci_cvbs_XXable to be
> directly added to the ops.
>
> I want to keep the registers setup in separate files and keep a clean
> DRM/HW separation.
I figured this is worth clarifying, and I'm somewhat guessing at your
motivation here for a clean drm/hw split. There's of course various levels
of how much you can split the drm side from your hw backend, but in
general that design approach is really unpopular with upstream. It goes by
the name of "midlayer", and the trouble with it is that it makes
subsystem refactoring more complicated.
For the driver itself it's nice, because it isolates you a bit from drm
core. But that exact isolation is the problem when someone wants (or more
often, needs to) refactor something across the entire subsystem. Then all
these driver-private little (or sometimes much bigger) abstractions get in
the way. That's way I suggested to remove it (both here and in the plane
code), because for upstream the overall subsystem matters more than each
individual driver. GPUs change fast, we need to be able to adapt fast,
too.
Anyway you're driver's pretty small, so personally I don't mind much. I'd
still think removing the indirection would be better though.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] [PATCH] drm/i915: fix compilation warnings on maybe uninitialized pointers
On Mon, Nov 28, 2016 at 06:43:19PM -0500, Jérémy Lefaure wrote:
> Two warnings are produced by gcc (tested with gcc 6.2.1):
>
> drivers/gpu/drm/i915/intel_csr.c: In function âcsr_load_work_fnâ:
> drivers/gpu/drm/i915/intel_csr.c:400:5: error: âfwâ is used
> uninitialized in this function [-Werror=uninitialized]
> if (fw)
>^
> and
>
> In file included from drivers/gpu/drm/i915/i915_drv.h:47:0,
> from drivers/gpu/drm/i915/intel_guc_loader.c:30:
> drivers/gpu/drm/i915/intel_guc_loader.c: In function âintel_guc_initâ:
> ./include/drm/drmP.h:228:2: error: âfwâ may be used uninitialized in this
> function -Werror=maybe-uninitialized]
> drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
> ^~
> drivers/gpu/drm/i915/intel_guc_loader.c:595:25: note: âfwâ was declared
> here
> const struct firmware *fw;
> ^~
>
> When CONFIG_DRM_I915_WERROR is set, those warnings break the build.
>
> Initializing fw pointer to NULL in both cases removes the warnings.
>
> Signed-off-by: Jérémy Lefaure
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_csr.c| 2 +-
> drivers/gpu/drm/i915/intel_guc_loader.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index d7a04bc..3520b3c 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -389,7 +389,7 @@ static void csr_load_work_fn(struct work_struct *work)
> {
> struct drm_i915_private *dev_priv;
> struct intel_csr *csr;
> - const struct firmware *fw;
> + const struct firmware *fw = NULL;
> int ret;
>
> dev_priv = container_of(work, typeof(*dev_priv), csr.work);
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 34d6ad2..ecfee49 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -592,7 +592,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct
> intel_guc_fw *guc_fw)
> {
> struct pci_dev *pdev = dev->pdev;
> struct drm_i915_gem_object *obj;
> - const struct firmware *fw;
> + const struct firmware *fw = NULL;
> struct guc_css_header *css;
> size_t size;
> int err;
> --
> 2.10.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH RFC v3] drm: Add a new connector atomic property for link status
On Mon, Nov 28, 2016 at 05:07:52PM -0800, Manasi Navare wrote: > On Thu, Nov 24, 2016 at 08:51:35AM +0100, Daniel Vetter wrote: > > On Wed, Nov 23, 2016 at 11:28:21PM -0800, Manasi Navare wrote: > > > This is RFC patch for adding a connector link-status property > > > and making it atomic by adding it to the drm_connector_state. > > > This is to make sure its wired properly in > > > drm_atomic_connector_set_property > > > and drm_atomic_connector_get_property functions. > > > > > > v3: > > > * Fixed a build error (Jani Saarinen) > > > v2: > > > * Removed connector->link_status (Daniel Vetter) > > > * Set connector->state->link_status in > > > drm_mode_connector_set_link_status_property > > > (Daniel Vetter) > > > * Set the connector_changed flag to true if connector->state->link_status > > > changed. > > > * Reset link_status to GOOD in update_output_state (Daniel Vetter) > > > * Never allow userspace to set link status from Good To Bad (Daniel > > > Vetter) > > > > > > Cc: Jani Nikula > > > Cc: Daniel Vetter > > > Cc: Ville Syrjala > > > Cc: Chris Wilson > > > Cc: Sean Paul > > > > You lost all the acked-by from AMD about the link-status property. We need > > those. > > > > > Signed-off-by: Manasi Navare > > > > Yeah I think this should work, but obviously testing has the final say. > > Some nitpicks below, then it's r-b: me. But I think we also need to polish > > the kernel-doc a bit more to address Sean Paul's questions. > > -Daniel > > > > I tested it with SNA driver with Chris's changes to read the link-status > property, but It is not able to detect the link-status property being set to > BAD > and hence it does not trigger a new modeset. > Do we need to make any changes to the SNA driver now that this is made a > ATOMIC > property so that GETCONNECTOR IOCTL can still read the correct value > of this property throught drm_atomic_get_property() interface? > > Chris, Daniel, any thoughts? We agreed that it must _not_ be a PROPERTY_ATOMIC property, so that old userspace can see it. > > > @@ -666,6 +683,13 @@ int drm_connector_create_standard_properties(struct > > > drm_device *dev) > > > return -ENOMEM; > > > dev->mode_config.tile_property = prop; > > > > > > + prop = drm_property_create_enum(dev, DRM_MODE_PROP_ATOMIC, > > > "link-status", I.e. remote DRM_MODE_PROP_ATOMIC here. I thought we've discussed this a lot already ...? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v3 00/13] R-Car DU: Use drm bridge API
Hello, This patch series replaces the custom external encoders support implementation in the R-Car DU driver with code based on the DRM bridge API. While the overall diffstat isn't impressive, the rcar-du-drm driver gets notably thinner in the process: 9 files changed, 64 insertions(+), 384 deletions(-) This is offset by a reusable driver for LVDS encoders along with the corresponding DT bindings (+ 218 lines). The series starts with a few cleanups. Patch 01/13 fixes all drivers to include where needed, allowing to remove inclusion of the header from (there are plenty of other headers that need similar cleanup, volunteers are welcome). Patch 02/13 then includes in to fix a compilation warning. The next patche moves copied&pasted code from a large number of drivers to the DRM bridge core drm_bridge_attach() function. The function now links bridges to encoders or other bridges instead of letting the caller perform that operation. Patch 04/13 can then detach bridges in the encoder cleanup function, removing the need to call drm_bridge_detach() explicitly in drivers (all but one of the drivers that use bridges were missing that call). Patches 05/13 and 06/13 add DT bindings for LVDS encoders with a corresponding driver. It supports "dumb" LVDS encoders only, similarly to the dumb-vga-dac driver. One notable difference, though, is that LVDS encoders can't be purely passive, and thus require at least one power supply (and usually multiple of them) and have a few control GPIOs (most notably to control reset, power down, clock polarity and/or LVDS slew rate). However, on many systems those encoders are integrated in such a way that the control pins are pulled up or down appropriately and the power supplies are either always on or shared with other display components that make them operate as if they were always on. For that reason a common drivers for those systems is useful, with simple DT bindings that don't try to cover any device-specific control pin or power supply. To ensure backward compatibility most LVDS encoders should *not* use the common simple "lvds-encoder" compatible string, but should instead define a device-specific compatible string that can then be added to the lvds-encoder driver (patch 08/13). This way, when the need to control pins or supplies will arise, a new driver can be developed matching on the device-specific compatible string, which will then be removed from the simple driver. Existing systems will migrate transparently without requiring a change to their device tree. A similar reasoning applies to VGA DACs, leading to the addition of the "adi,adv7123" compatible string to the dumb-vga-dac driver's OF match table in patch 07/13. Patch 09/13 adds a new type field to the drm_bridge structure to inform bridge users of the bridge type. This is useful for display driver to create a DRM encoder of the appropriate type without having to resort to heuristics. Patches 10/13 and 11/13 update all bridge drivers to initialize the new field to the appropriate value. Patches 12/13 and 13/13 finally migrate the rcar-du-drm driver to the DRM bridge API, removing the custom VGA DAC implementation in patch 12/13 and the table of bridge compatible strings used to find the encoder type in patch 13/13. Changes since v2: - Added patches 01/13 to 04/13. - Rebased on top of latest DRM master branch Changes since v1: - The patches have been rebased on top of the "[PATCH v2 00/13] R-Car DU: Add support for LVDS mode selection" series. - The LVDS encoder DT bindings have been split from the LVDS encoder driver into a separate patch. - The wording of the DRM bridge documentation new property has been updated. Laurent Pinchart (13): drm: Don't include in drm: Fix compilation warning caused by static inline forward declaration drm: bridge: Link encoder and bridge in core code drm: bridge: Detach bridge from encoder at encoder cleanup time drm: bridge: Add LVDS encoder DT bindings drm: bridge: Add LVDS encoder driver drm: bridge: vga-dac: Add adi,adv7123 compatible string drm: bridge: lvds-encoder: Add thine,thc63lvdm83d compatible string drm: Add encoder_type field to the drm_bridge structure drm: bridge: Set bridges' encoder type drm: Set on-chip bridges' encoder type drm: rcar-du: Replace manual bridge implementation with DRM bridge drm: rcar-du: Initialize encoder's type based on the bridge's type .../bindings/display/bridge/lvds-transmitter.txt | 64 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + drivers/gpu/drm/ast/ast_drv.h | 1 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 4 +- drivers/gpu/drm/bochs/bochs.h | 1 + drivers/gpu/drm/bridge/Kconfig | 8 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 + drivers/gpu/drm/bridge/analogix-anx78xx.c | 1 + drivers/gpu/d
[PATCH v3 07/13] drm: bridge: vga-dac: Add adi, adv7123 compatible string
The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be
controlled through a power save pin, and requires a power supply.
However, on most boards where the device is used neither the power save
signal nor the power supply are controllable.
To avoid developing a separate device-specific driver add an
"adi,adv7123" compatible entry to the dumb-vga-dac driver. This will
allow supporting most ADV7123-based boards easily, while allowing future
development of an adv7123 driver when needed without breaking backward
compatibility.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index afec232185a7..b33e3f829e4f 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -204,6 +204,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
static const struct of_device_id dumb_vga_match[] = {
{ .compatible = "dumb-vga-dac" },
+ { .compatible = "adi,adv7123" },
{},
};
MODULE_DEVICE_TABLE(of, dumb_vga_match);
--
Regards,
Laurent Pinchart
[PATCH v3 11/13] drm: Set on-chip bridges' encoder type
Initialize the new drm_bridge::encoder_type field to the right value for
all bridges that model on-SoC IP cores.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 ++
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 ++
drivers/gpu/drm/sti/sti_dvo.c | 2 ++
3 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index a0def0be6d65..7175ecda36e8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -390,6 +390,8 @@ static int exynos_mic_bind(struct device *dev, struct
device *master,
mic->bridge.funcs = &mic_bridge_funcs;
mic->bridge.of_node = dev->of_node;
mic->bridge.driver_private = mic;
+ mic->bridge.encoder_type = DRM_MODE_ENCODER_DSI;
+
ret = drm_bridge_add(&mic->bridge);
if (ret)
DRM_ERROR("mic: Failed to add MIC to the global bridge list\n");
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 5ca1b0fbf937..bb5cf594c721 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1712,6 +1712,8 @@ static int mtk_drm_hdmi_probe(struct platform_device
*pdev)
hdmi->bridge.funcs = &mtk_hdmi_bridge_funcs;
hdmi->bridge.of_node = pdev->dev.of_node;
+ hdmi->bridge.encoder_type = DRM_MODE_ENCODER_TMDS;
+
ret = drm_bridge_add(&hdmi->bridge);
if (ret) {
dev_err(dev, "failed to add bridge, ret = %d\n", ret);
diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index 411dc6ec976e..8912c932078f 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -472,6 +472,8 @@ static int sti_dvo_bind(struct device *dev, struct device
*master, void *data)
bridge->driver_private = dvo;
bridge->funcs = &sti_dvo_bridge_funcs;
bridge->of_node = dvo->dev.of_node;
+ bridge->encoder_type = DRM_MODE_ENCODER_LVDS;
+
err = drm_bridge_add(bridge);
if (err) {
DRM_ERROR("Failed to add bridge\n");
--
Regards,
Laurent Pinchart
[PATCH v3 02/13] drm: Fix compilation warning caused by static inline forward declaration
The drm_crtc_mask() function used in is a static inline defined in . If the first header is included in a compilation unit without the second one, the following compilation warning will be issued. In file included from /drivers/gpu/drm/drm_bridge.c:29:0: /include/drm/drm_encoder.h:192:95: warning: âdrm_crtc_maskâ used but never defined static inline uint32_t drm_crtc_mask(const struct drm_crtc *crtc); Fix this by including the header defining the function instead of using a forward declaration. Signed-off-by: Laurent Pinchart --- include/drm/drm_encoder.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h index cec6ac45c6cc..5f58f65344e0 100644 --- a/include/drm/drm_encoder.h +++ b/include/drm/drm_encoder.h @@ -25,6 +25,7 @@ #include #include +#include #include #include @@ -191,9 +192,6 @@ static inline unsigned int drm_encoder_index(struct drm_encoder *encoder) return encoder->index; } -/* FIXME: We have an include file mess still, drm_crtc.h needs untangling. */ -static inline uint32_t drm_crtc_mask(const struct drm_crtc *crtc); - /** * drm_encoder_crtc_ok - can a given crtc drive a given encoder? * @encoder: encoder to test -- Regards, Laurent Pinchart
[PATCH v3 04/13] drm: bridge: Detach bridge from encoder at encoder cleanup time
Most drivers that use bridges forgot to detach them at cleanup time. Instead of fixing them one by one, detach the bridge in the core drm_encoder_cleanup() function. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/drm_encoder.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c index 5c067719164d..9c1f99646e0d 100644 --- a/drivers/gpu/drm/drm_encoder.c +++ b/drivers/gpu/drm/drm_encoder.c @@ -164,6 +164,9 @@ void drm_encoder_cleanup(struct drm_encoder *encoder) * the indices on the drm_encoder after us in the encoder_list. */ + if (encoder->bridge) + drm_bridge_detach(encoder->bridge); + drm_modeset_lock_all(dev); drm_mode_object_unregister(dev, &encoder->base); kfree(encoder->name); -- Regards, Laurent Pinchart
[PATCH v3 08/13] drm: bridge: lvds-encoder: Add thine, thc63lvdm83d compatible string
The THC63LVDM83D is a transparent LVDS encoder. Unlike dumb LVDS
encoders it can be controlled through a few pins (power down, LVDS
swing, clock edge selection) and requires power supplies. However, on
several boards where the device is used neither the control pins nor the
power supply are controllable.
To avoid developing a separate device-specific driver add a
"thine,thc63lvdm83d" compatible entry to the lvds-encoder driver. This
will allow supporting many THC63LVDM83D-based boards easily, while
allowing future development of an thc63lvdm83d driver when needed
without breaking backward compatibility.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/lvds-encoder.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 576770ea8d7e..16c5ac77824a 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -198,6 +198,7 @@ static int lvds_encoder_remove(struct platform_device *pdev)
static const struct of_device_id lvds_encoder_match[] = {
{ .compatible = "lvds-encoder" },
+ { .compatible = "thine,thc63lvdm83d" },
{},
};
MODULE_DEVICE_TABLE(of, lvds_encoder_match);
--
Regards,
Laurent Pinchart
[PATCH v3 01/13] drm: Don't include in
used to define most of the in-kernel KMS API. It has now been split into separate files for each object type, but still includes most other KMS headers to avoid breaking driver compilation. As a step towards fixing that problem, remove the inclusion of from and include it instead where appropriate. Also remove the forward declarations of the drm_encoder and drm_encoder_helper_funcs structures from as they're not needed in the header. now has to include and contain a forward declaration of struct drm_encoder in order to allow including it as the first header in a compilation unit. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 1 + drivers/gpu/drm/ast/ast_drv.h | 1 + drivers/gpu/drm/bochs/bochs.h | 1 + drivers/gpu/drm/cirrus/cirrus_drv.h | 1 + drivers/gpu/drm/drm_connector.c | 1 + drivers/gpu/drm/drm_crtc_helper.c | 1 + drivers/gpu/drm/drm_edid.c | 1 + drivers/gpu/drm/drm_mode_config.c | 1 + drivers/gpu/drm/drm_of.c| 1 + drivers/gpu/drm/drm_plane_helper.c | 1 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 2 ++ drivers/gpu/drm/gma500/psb_intel_drv.h | 1 + drivers/gpu/drm/i915/intel_drv.h| 1 + drivers/gpu/drm/mgag200/mgag200_drv.h | 1 + drivers/gpu/drm/nouveau/nouveau_connector.h | 1 + drivers/gpu/drm/qxl/qxl_drv.h | 1 + drivers/gpu/drm/radeon/radeon_mode.h| 1 + drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 1 + drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 1 + drivers/gpu/drm/tegra/drm.h | 1 + drivers/gpu/drm/vc4/vc4_drv.h | 2 ++ drivers/gpu/drm/virtio/virtgpu_drv.h| 1 + drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 1 + include/drm/drm_crtc.h | 3 --- include/drm/drm_encoder.h | 3 +++ include/drm/drm_encoder_slave.h | 1 + include/drm/drm_modeset_helper_vtables.h| 1 + 27 files changed, 30 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h index 1e23334b07fb..fac06064a8f5 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h @@ -32,6 +32,7 @@ #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h index 908011d2c8f5..6f3b6f50cf52 100644 --- a/drivers/gpu/drm/ast/ast_drv.h +++ b/drivers/gpu/drm/ast/ast_drv.h @@ -28,6 +28,7 @@ #ifndef __AST_DRV_H__ #define __AST_DRV_H__ +#include #include #include diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h index 32dfe418cc98..f626bab7f5e3 100644 --- a/drivers/gpu/drm/bochs/bochs.h +++ b/drivers/gpu/drm/bochs/bochs.h @@ -4,6 +4,7 @@ #include #include #include +#include #include #include diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h b/drivers/gpu/drm/cirrus/cirrus_drv.h index 2188d6b61b3e..b59aeef4635a 100644 --- a/drivers/gpu/drm/cirrus/cirrus_drv.h +++ b/drivers/gpu/drm/cirrus/cirrus_drv.h @@ -13,6 +13,7 @@ #include +#include #include #include diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index b5c6a8ee831e..5f1e1f190d30 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -23,6 +23,7 @@ #include #include #include +#include #include "drm_crtc_internal.h" #include "drm_internal.h" diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index 5d2cb138eba6..b3fc23313cc3 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -36,6 +36,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7eec18925b70..a9e3cc3990c1 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #define version_greater(edid, maj, min) \ diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c index 2735a5847ffa..09b1d8f267a6 100644 --- a/drivers/gpu/drm/drm_mode_config.c +++ b/drivers/gpu/drm/drm_mode_config.c @@ -20,6 +20,7 @@ * OF THIS SOFTWARE. */ +#include #include #include diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c index 47848ed8ca48..b5f2f0fece99 100644 --- a/drivers/gpu/drm/drm_of.c +++ b/drivers/gpu/drm/drm_of.c @@ -4,6 +4,7 @@ #include #include #include +#include #include static void drm_release_of(struct device *dev, void *data) diff --git a/drivers/gpu/drm/drm_plane_helper.c b/drivers/gpu/drm/drm_plane_helper.c index 7a7dddf604d7..191a5f095cf9 100644 --- a/drivers/gpu/drm/drm_plane_helper.c +++ b/drivers/gpu/drm/drm_plane_helper.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #defin
[PATCH v3 12/13] drm: rcar-du: Replace manual bridge implementation with DRM bridge
The rcar-du driver contains a manual implementation of HDMI and VGA
bridges. Use DRM bridges to replace it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 6 --
drivers/gpu/drm/rcar-du/Makefile | 5 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 104 +--
drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 2 -
drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 134 --
drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h | 35
drivers/gpu/drm/rcar-du/rcar_du_vgacon.c | 82 --
drivers/gpu/drm/rcar-du/rcar_du_vgacon.h | 23 -
8 files changed, 60 insertions(+), 331 deletions(-)
delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h
delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vgacon.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 2bab449add76..06121eeba9e5 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -11,12 +11,6 @@ config DRM_RCAR_DU
Choose this option if you have an R-Car chipset.
If M is selected the module will be called rcar-du-drm.
-config DRM_RCAR_HDMI
- bool "R-Car DU HDMI Encoder Support"
- depends on DRM_RCAR_DU
- help
- Enable support for external HDMI encoders.
-
config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index d3b44651061a..a492e6858691 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -4,10 +4,7 @@ rcar-du-drm-y := rcar_du_crtc.o \
rcar_du_group.o \
rcar_du_kms.o \
rcar_du_lvdscon.o \
-rcar_du_plane.o \
-rcar_du_vgacon.o
-
-rcar-du-drm-$(CONFIG_DRM_RCAR_HDMI)+= rcar_du_hdmienc.o
+rcar_du_plane.o
rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 21262057ef08..d412dc622bfa 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -20,11 +20,9 @@
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
-#include "rcar_du_hdmienc.h"
#include "rcar_du_kms.h"
#include "rcar_du_lvdscon.h"
#include "rcar_du_lvdsenc.h"
-#include "rcar_du_vgacon.h"
/*
-
* Encoder
@@ -63,29 +61,35 @@ static int rcar_du_encoder_atomic_check(struct drm_encoder
*encoder,
struct rcar_du_encoder *renc = to_rcar_encoder(encoder);
struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode;
const struct drm_display_mode *mode = &crtc_state->mode;
- const struct drm_display_mode *panel_mode;
struct drm_connector *connector = conn_state->connector;
struct drm_device *dev = encoder->dev;
- /* DAC encoders have currently no restriction on the mode. */
- if (encoder->encoder_type == DRM_MODE_ENCODER_DAC)
- return 0;
+ /*
+* Only panel-related encoder types require validation here, everything
+* else is handled by the bridge drivers.
+*/
+ if (encoder->encoder_type == DRM_MODE_ENCODER_LVDS) {
+ const struct drm_display_mode *panel_mode;
- if (list_empty(&connector->modes)) {
- dev_dbg(dev->dev, "encoder: empty modes list\n");
- return -EINVAL;
- }
+ if (list_empty(&connector->modes)) {
+ dev_dbg(dev->dev, "encoder: empty modes list\n");
+ return -EINVAL;
+ }
- panel_mode = list_first_entry(&connector->modes,
- struct drm_display_mode, head);
+ panel_mode = list_first_entry(&connector->modes,
+ struct drm_display_mode, head);
- /* We're not allowed to modify the resolution. */
- if (mode->hdisplay != panel_mode->hdisplay ||
- mode->vdisplay != panel_mode->vdisplay)
- return -EINVAL;
+ /* We're not allowed to modify the resolution. */
+ if (mode->hdisplay != panel_mode->hdisplay ||
+ mode->vdisplay != panel_mode->vdisplay)
+ return -EINVAL;
- /* The flat panel mode is fixed, just copy it to the adjusted mode. */
- drm_mode_copy(adjusted_mode, panel_mode);
+ /*
+* The flat panel mode is fixed, just copy it to the adjusted
+* mode.
+*/
+ drm_mode_copy(adjusted_mode, panel_mode);
+ }
if (renc->lvds)
[PATCH v3 03/13] drm: bridge: Link encoder and bridge in core code
Instead of linking encoders and bridges in every driver (and getting it
wrong half of the time, as many drivers forget to set the drm_bridge
encoder pointer), do so in core code. The drm_bridge_attach() function
needs the encoder and optional previous bridge to perform that task,
update all the callers.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 4 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 +-
drivers/gpu/drm/bridge/dw-hdmi.c | 3 +-
drivers/gpu/drm/drm_bridge.c | 46 --
drivers/gpu/drm/drm_simple_kms_helper.c| 4 +-
drivers/gpu/drm/exynos/exynos_dp.c | 5 +--
drivers/gpu/drm/exynos/exynos_drm_dsi.c| 6 +--
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +--
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 5 +--
drivers/gpu/drm/imx/imx-ldb.c | 6 +--
drivers/gpu/drm/imx/parallel-display.c | 4 +-
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 ++--
drivers/gpu/drm/mediatek/mtk_dsi.c | 24 ++-
drivers/gpu/drm/mediatek/mtk_hdmi.c| 11 +++---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 17 +---
drivers/gpu/drm/msm/edp/edp_bridge.c | 2 +-
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 5 +--
drivers/gpu/drm/sti/sti_dvo.c | 3 +-
drivers/gpu/drm/sti/sti_hda.c | 3 +-
drivers/gpu/drm/sti/sti_hdmi.c | 3 +-
drivers/gpu/drm/sun4i/sun4i_rgb.c | 13 +++---
include/drm/drm_bridge.h | 3 +-
23 files changed, 83 insertions(+), 103 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 6119b5085501..e7799b6ee829 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -230,9 +230,7 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device
*dev,
of_node_put(np);
if (bridge) {
- output->encoder.bridge = bridge;
- bridge->encoder = &output->encoder;
- ret = drm_bridge_attach(dev, bridge);
+ ret = drm_bridge_attach(&output->encoder, bridge, NULL);
if (!ret)
return 0;
}
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6e0447f329a2..1835f1fdad19 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1227,12 +1227,10 @@ static int analogix_dp_create_bridge(struct drm_device
*drm_dev,
dp->bridge = bridge;
- dp->encoder->bridge = bridge;
bridge->driver_private = dp;
- bridge->encoder = dp->encoder;
bridge->funcs = &analogix_dp_bridge_funcs;
- ret = drm_bridge_attach(drm_dev, bridge);
+ ret = drm_bridge_attach(dp->encoder, bridge, NULL);
if (ret) {
DRM_ERROR("failed to attach drm bridge\n");
return -EINVAL;
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index b71088dab268..432e0e3fff72 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1841,13 +1841,12 @@ static int dw_hdmi_register(struct drm_device *drm,
struct dw_hdmi *hdmi)
hdmi->bridge = bridge;
bridge->driver_private = hdmi;
bridge->funcs = &dw_hdmi_bridge_funcs;
- ret = drm_bridge_attach(drm, bridge);
+ ret = drm_bridge_attach(encoder, bridge, NULL);
if (ret) {
DRM_ERROR("Failed to initialize bridge with drm\n");
return -EINVAL;
}
- encoder->bridge = bridge;
hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD;
drm_connector_helper_add(&hdmi->connector,
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 0ee052b7c21a..850bd6509ef1 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -26,6 +26,7 @@
#include
#include
+#include
/**
* DOC: overview
@@ -92,32 +93,53 @@ void drm_bridge_remove(struct drm_bridge *bridge)
EXPORT_SYMBOL(drm_bridge_remove);
/**
- * drm_bridge_attach - associate given bridge to our DRM device
+ * drm_bridge_attach - attach the bridge to an encoder's chain
*
- * @dev: DRM device
- * @bridge: bridge control structure
+ * @encoder: DRM encoder
+ * @bridge: bridge to attach
+ * @previous: previous bridge in the chain (optional)
*
- * Called by a kms driver to link one of our encoder/bridge to the given
- * bridge.
+ * Called by a kms driver to link the bridge to an encoder's chain. The
previous
+ * argument specifies the previous bridge in the chain. If
[PATCH v3 09/13] drm: Add encoder_type field to the drm_bridge structure
The drm_bridge object models on- or off-chip hardware encoders and
provide an abstract control API to display drivers. In order to help
display drivers creating the right kind of drm_encoder object, expose
the type of the hardware encoder associated with each bridge.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Clarify documentation
---
include/drm/drm_bridge.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 94e5ee96b3b5..0643b6ce27de 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -194,6 +194,14 @@ struct drm_bridge {
#endif
struct list_head list;
+ /**
+* @encoder_type:
+*
+* Type of the hardware encoder modeled by the bridge as one of the
+* DRM_MODE_ENCODER_* types. For the last bridge in the chain this will
+* usually be identical to the bridge's &drm_encoder encoder_type.
+*/
+ int encoder_type;
const struct drm_bridge_funcs *funcs;
void *driver_private;
};
--
Regards,
Laurent Pinchart
[PATCH v3 13/13] drm: rcar-du: Initialize encoder's type based on the bridge's type
Set the type of the DRM encoder that models the hardware encoders
(bridges) chain based on the type of the last bridge in the chain
instead of hardcoding encoder compatible strings in the display driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 17 ++
drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 1 -
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 37 ++-
3 files changed, 4 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index d412dc622bfa..1adf4a77904e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -156,7 +156,6 @@ static const struct drm_encoder_funcs encoder_funcs = {
};
int rcar_du_encoder_init(struct rcar_du_device *rcdu,
-enum rcar_du_encoder_type type,
enum rcar_du_output output,
struct device_node *enc_node,
struct device_node *con_node)
@@ -194,23 +193,11 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
ret = -EPROBE_DEFER;
goto done;
}
- }
- switch (type) {
- case RCAR_DU_ENCODER_VGA:
- encoder_type = DRM_MODE_ENCODER_DAC;
- break;
- case RCAR_DU_ENCODER_LVDS:
- encoder_type = DRM_MODE_ENCODER_LVDS;
- break;
- case RCAR_DU_ENCODER_HDMI:
- encoder_type = DRM_MODE_ENCODER_TMDS;
- break;
- case RCAR_DU_ENCODER_NONE:
- default:
+ encoder_type = bridge->encoder_type;
+ } else {
/* No external encoder, use the internal encoder type. */
encoder_type = rcdu->info->routes[output].encoder_type;
- break;
}
ret = drm_encoder_init(rcdu->ddev, encoder, &encoder_funcs,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index c1cfbe0d54ce..2b9036e7f6fe 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
@@ -51,7 +51,6 @@ struct rcar_du_connector {
container_of(c, struct rcar_du_connector, connector)
int rcar_du_encoder_init(struct rcar_du_device *rcdu,
-enum rcar_du_encoder_type type,
enum rcar_du_output output,
struct device_node *enc_node,
struct device_node *con_node);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index b5d3f16cfa12..aa84689043ae 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -366,16 +366,6 @@ static int rcar_du_encoders_init_one(struct rcar_du_device
*rcdu,
enum rcar_du_output output,
struct of_endpoint *ep)
{
- static const struct {
- const char *compatible;
- enum rcar_du_encoder_type type;
- } encoders[] = {
- { "adi,adv7123", RCAR_DU_ENCODER_VGA },
- { "adi,adv7511w", RCAR_DU_ENCODER_HDMI },
- { "thine,thc63lvdm83d", RCAR_DU_ENCODER_LVDS },
- };
-
- enum rcar_du_encoder_type enc_type = RCAR_DU_ENCODER_NONE;
struct device_node *connector = NULL;
struct device_node *encoder = NULL;
struct device_node *ep_node = NULL;
@@ -422,30 +412,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device
*rcdu,
of_node_put(entity_ep_node);
- if (encoder) {
- /*
-* If an encoder has been found, get its type based on its
-* compatible string.
-*/
- unsigned int i;
-
- for (i = 0; i < ARRAY_SIZE(encoders); ++i) {
- if (of_device_is_compatible(encoder,
- encoders[i].compatible)) {
- enc_type = encoders[i].type;
- break;
- }
- }
-
- if (i == ARRAY_SIZE(encoders)) {
- dev_warn(rcdu->dev,
-"unknown encoder type for %s, skipping\n",
-encoder->full_name);
- of_node_put(encoder);
- of_node_put(connector);
- return -EINVAL;
- }
- } else {
+ if (!encoder) {
/*
* If no encoder has been found the entity must be the
* connector.
@@ -453,7 +420,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device
*rcdu,
connector = entity;
}
- ret = rcar_du_encoder_init(rcdu, enc_type, output, enco
[PATCH v3 06/13] drm: bridge: Add LVDS encoder driver
The LVDS encoder driver is a DRM bridge driver that supports the
parallel to LVDS encoders that don't require any configuration. The
driver thus doesn't interact with the device, but creates an LVDS
connector for the panel and exposes its size and timing based on
information retrieved from DT.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/Kconfig| 8 ++
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/lvds-encoder.c | 217 ++
3 files changed, 226 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index bd6acc829f97..a4d9657c9477 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -24,6 +24,14 @@ config DRM_DUMB_VGA_DAC
help
Support for RGB to VGA DAC based bridges
+config DRM_LVDS_ENCODER
+ tristate "Transparent parallel to LVDS encoder support"
+ depends on OF
+ select DRM_KMS_HELPER
+ help
+ Support for transparent parallel to LVDS encoders that don't require
+ any configuration.
+
config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 97ed1a5fea9a..7e0bf849c30d 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@ ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
+obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
new file mode 100644
index ..576770ea8d7e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -0,0 +1,217 @@
+/*
+ * Copyright (C) 2016 Laurent Pinchart
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct lvds_encoder {
+ struct device *dev;
+
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+ struct drm_panel *panel;
+};
+
+static inline struct lvds_encoder *
+drm_bridge_to_lvds_encoder(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct lvds_encoder, bridge);
+}
+
+static inline struct lvds_encoder *
+drm_connector_to_lvds_encoder(struct drm_connector *connector)
+{
+ return container_of(connector, struct lvds_encoder, connector);
+}
+
+static int lvds_connector_get_modes(struct drm_connector *connector)
+{
+ struct lvds_encoder *lvds = drm_connector_to_lvds_encoder(connector);
+
+ return drm_panel_get_modes(lvds->panel);
+}
+
+static const struct drm_connector_helper_funcs lvds_connector_helper_funcs = {
+ .get_modes = lvds_connector_get_modes,
+};
+
+static enum drm_connector_status
+lvds_connector_detect(struct drm_connector *connector, bool force)
+{
+ return connector_status_connected;
+}
+
+static const struct drm_connector_funcs lvds_connector_funcs = {
+ .dpms = drm_atomic_helper_connector_dpms,
+ .reset = drm_atomic_helper_connector_reset,
+ .detect = lvds_connector_detect,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = drm_connector_cleanup,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int lvds_encoder_attach(struct drm_bridge *bridge)
+{
+ struct lvds_encoder *lvds = drm_bridge_to_lvds_encoder(bridge);
+ struct drm_connector *connector = &lvds->connector;
+ int ret;
+
+ if (!bridge->encoder) {
+ DRM_ERROR("Missing encoder\n");
+ return -ENODEV;
+ }
+
+ drm_connector_helper_add(connector, &lvds_connector_helper_funcs);
+
+ ret = drm_connector_init(bridge->dev, connector, &lvds_connector_funcs,
+DRM_MODE_CONNECTOR_LVDS);
+ if (ret) {
+ DRM_ERROR("Failed to initialize connector\n");
+ return ret;
+ }
+
+ drm_mode_connector_attach_encoder(&lvds->connector, bridge->encoder);
+
+ ret = drm_panel_attach(lvds->panel, &lvds->connector);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static void lvds_encoder_detach(struct drm_bridge *bridge)
+{
+ struct lvds_encoder *lvds = drm_bridge_to_lvds_encoder(bridge);
+
+ drm_panel_detach(lvds->panel);
+}
+
+static void lvds_encoder_pre_enable(struc
[PATCH v3 10/13] drm: bridge: Set bridges' encoder type
Initialize the new drm_bridge::encoder_type field to the right value for
all external bridge drivers.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 +
drivers/gpu/drm/bridge/analogix-anx78xx.c | 1 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
drivers/gpu/drm/bridge/dw-hdmi.c | 2 ++
drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 ++
drivers/gpu/drm/bridge/parade-ps8622.c | 2 ++
drivers/gpu/drm/bridge/sii902x.c | 2 ++
drivers/gpu/drm/bridge/tc358767.c | 2 ++
9 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 8ed3906dd411..66bbd2073529 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1030,6 +1030,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
adv7511->bridge.funcs = &adv7511_bridge_funcs;
adv7511->bridge.of_node = dev->of_node;
+ adv7511->bridge.encoder_type = DRM_MODE_ENCODER_TMDS;
ret = drm_bridge_add(&adv7511->bridge);
if (ret) {
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a82366a771..62be93f7ffaa 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1437,6 +1437,7 @@ static int anx78xx_i2c_probe(struct i2c_client *client,
}
anx78xx->bridge.funcs = &anx78xx_bridge_funcs;
+ anx78xx->bridge.encoder_type = DRM_MODE_ENCODER_TMDS;
err = drm_bridge_add(&anx78xx->bridge);
if (err < 0) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 1835f1fdad19..f0f9c5024e3e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1229,6 +1229,7 @@ static int analogix_dp_create_bridge(struct drm_device
*drm_dev,
bridge->driver_private = dp;
bridge->funcs = &analogix_dp_bridge_funcs;
+ bridge->encoder_type = DRM_MODE_ENCODER_TMDS;
ret = drm_bridge_attach(dp->encoder, bridge, NULL);
if (ret) {
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index b33e3f829e4f..036c54c849e6 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -182,6 +182,7 @@ static int dumb_vga_probe(struct platform_device *pdev)
vga->bridge.funcs = &dumb_vga_bridge_funcs;
vga->bridge.of_node = pdev->dev.of_node;
+ vga->bridge.encoder_type = DRM_MODE_ENCODER_DAC;
ret = drm_bridge_add(&vga->bridge);
if (ret && !IS_ERR(vga->ddc))
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 432e0e3fff72..0ac28aa76017 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1841,6 +1841,8 @@ static int dw_hdmi_register(struct drm_device *drm,
struct dw_hdmi *hdmi)
hdmi->bridge = bridge;
bridge->driver_private = hdmi;
bridge->funcs = &dw_hdmi_bridge_funcs;
+ bridge->encoder_type = DRM_MODE_ENCODER_TMDS;
+
ret = drm_bridge_attach(encoder, bridge, NULL);
if (ret) {
DRM_ERROR("Failed to initialize bridge with drm\n");
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index f1a99938e924..8be117cc024f 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -349,6 +349,8 @@ static int ptn3460_probe(struct i2c_client *client,
ptn_bridge->bridge.funcs = &ptn3460_bridge_funcs;
ptn_bridge->bridge.of_node = dev->of_node;
+ ptn_bridge->bridge.encoder_type = DRM_MODE_ENCODER_LVDS;
+
ret = drm_bridge_add(&ptn_bridge->bridge);
if (ret) {
DRM_ERROR("Failed to add bridge\n");
diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c
b/drivers/gpu/drm/bridge/parade-ps8622.c
index 6f7c2f9860d2..37ac7211139a 100644
--- a/drivers/gpu/drm/bridge/parade-ps8622.c
+++ b/drivers/gpu/drm/bridge/parade-ps8622.c
@@ -615,6 +615,8 @@ static int ps8622_probe(struct i2c_client *client,
ps8622->bridge.funcs = &ps8622_bridge_funcs;
ps8622->bridge.of_node = dev->of_node;
+ ps8622->bridge.encoder_type = DRM_MODE_ENCODER_LVDS;
+
ret = drm_bridge_add(&ps8622->bridge);
if (ret) {
DRM_ERROR("Failed to add bridge\n");
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 9126d0306ab5..ad4663dea333 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -418,6 +418,8 @@ static int sii902x_probe(struct i2c_client *client,
sii902x->bridge.
[PATCH v3 05/13] drm: bridge: Add LVDS encoder DT bindings
The DT bindings support parallel to LVDS encoders that don't require any
configuration, similarly to the dumb VGA DAC DT bindings.
Signed-off-by: Laurent Pinchart
Acked-by: Rob Herring
---
.../bindings/display/bridge/lvds-transmitter.txt | 64 ++
1 file changed, 64 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
new file mode 100644
index ..fd39ad34c383
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -0,0 +1,64 @@
+Parallel to LVDS Encoder
+
+
+This binding supports the parallel to LVDS encoders that don't require any
+configuration.
+
+LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
+incompatible data link layers have been used over time to transmit image data
+to LVDS panels. This binding targets devices compatible with the following
+specifications only.
+
+[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
+1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
+[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
+Semiconductor
+[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
+Electronics Standards Association (VESA)
+
+Those devices have been marketed under the FPD-Link and FlatLink brand names
+among others.
+
+
+Required properties:
+
+- compatible: Must be "lvds-encoder"
+
+Required nodes:
+
+This device has two video ports. Their connections are modeled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for parallel input
+- Video port 1 for LVDS output
+
+
+Example
+---
+
+lvds-encoder {
+ compatible = "lvds-encoder";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ lvds_enc_in: endpoint {
+ remote-endpoint = <&display_out_rgb>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ lvds_enc_out: endpoint {
+ remote-endpoint = <&lvds_panel_in>;
+ };
+ };
+ };
+};
--
Regards,
Laurent Pinchart
[Intel-gfx] [PATCH] drm/i915: fix compilation warnings on maybe uninitialized pointers
On 29/11/2016 08:56, Daniel Vetter wrote:
> On Mon, Nov 28, 2016 at 06:43:19PM -0500, Jérémy Lefaure wrote:
>> Two warnings are produced by gcc (tested with gcc 6.2.1):
>>
>> drivers/gpu/drm/i915/intel_csr.c: In function âcsr_load_work_fnâ:
>> drivers/gpu/drm/i915/intel_csr.c:400:5: error: âfwâ is used
>> uninitialized in this function [-Werror=uninitialized]
>> if (fw)
>>^
>> and
>>
>> In file included from drivers/gpu/drm/i915/i915_drv.h:47:0,
>> from drivers/gpu/drm/i915/intel_guc_loader.c:30:
>> drivers/gpu/drm/i915/intel_guc_loader.c: In function âintel_guc_initâ:
>> ./include/drm/drmP.h:228:2: error: âfwâ may be used uninitialized in this
>> function -Werror=maybe-uninitialized]
>> drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
>> ^~
>> drivers/gpu/drm/i915/intel_guc_loader.c:595:25: note: âfwâ was declared
>> here
>> const struct firmware *fw;
>> ^~
>>
>> When CONFIG_DRM_I915_WERROR is set, those warnings break the build.
>>
>> Initializing fw pointer to NULL in both cases removes the warnings.
>>
>> Signed-off-by: Jérémy Lefaure
>
> Queued for -next, thanks for the patch.
I just wanted to reply with two things; first who can figure out why
this hasn't been picked up by the compiler before? Or why GCC 6.2.1 on
my machine does not complain? Looks like a real mystery!
And secondly the csr loader is not even checking the return code. I was
about to suggest a v2 but never mind now. Can do it myself.
Regards,
Tvrtko
> -Daniel
>
>> ---
>> drivers/gpu/drm/i915/intel_csr.c| 2 +-
>> drivers/gpu/drm/i915/intel_guc_loader.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_csr.c
>> b/drivers/gpu/drm/i915/intel_csr.c
>> index d7a04bc..3520b3c 100644
>> --- a/drivers/gpu/drm/i915/intel_csr.c
>> +++ b/drivers/gpu/drm/i915/intel_csr.c
>> @@ -389,7 +389,7 @@ static void csr_load_work_fn(struct work_struct *work)
>> {
>> struct drm_i915_private *dev_priv;
>> struct intel_csr *csr;
>> -const struct firmware *fw;
>> +const struct firmware *fw = NULL;
>> int ret;
>>
>> dev_priv = container_of(work, typeof(*dev_priv), csr.work);
>> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
>> b/drivers/gpu/drm/i915/intel_guc_loader.c
>> index 34d6ad2..ecfee49 100644
>> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
>> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
>> @@ -592,7 +592,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct
>> intel_guc_fw *guc_fw)
>> {
>> struct pci_dev *pdev = dev->pdev;
>> struct drm_i915_gem_object *obj;
>> -const struct firmware *fw;
>> +const struct firmware *fw = NULL;
>> struct guc_css_header *css;
>> size_t size;
>> int err;
>> --
>> 2.10.2
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
[PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings
Hi Archit, (CC'ing Mark Brown) On Tuesday 29 Nov 2016 13:41:33 Archit Taneja wrote: > On 11/29/2016 12:03 PM, Laurent Pinchart wrote: > > On Tuesday 29 Nov 2016 11:37:41 Archit Taneja wrote: > >> Add the regulator supply properties needed by ADV7511 and ADV7533. > >> > >> The regulators are specified as optional properties since there can > >> be boards which have a fixed supply directly routed to the pins, and > >> these may not be modelled as regulator supplies. > > > > That's why we have support for dummy supplies in the kernel, isn't it ? > > Isn't it better to make the supplies mandatory in the bindings (and > > obviously handling them as optional in the driver for > > backward-compatibility) ? > > I'm a bit unclear on this. > > I thought we couldn't add mandatory properties once the device is already > present in DT for one or more platforms. You can, as long as you treat them as optional in the driver to retain backward compatibility. The DT bindings should document the properties expected from a new platform (older versions of the bindings will always be available in the git history). > Say, if we do make it mandatory for future additions, we would need to have > DT property for the supplies for the new platforms. If the regulators on > these boards are fixed supplies, they would be need to be modeled > using "regulator-fixed", possibly without any input supply. Is that > what you're suggesting? That's the idea, yes. Clock maintainers have a similar opinion regarding the clock bindings, where a clock that is not optional at the hardware level should be specified in DT even if it's always present. Mark, any opinion ? > > Apart from that, > > > > Acked-by: Laurent Pinchart > > > >> Cc: devicetree at vger.kernel.org > >> Acked-by: Rob Herring > >> Signed-off-by: Archit Taneja > >> --- > >> v3: > >> - Revert back to having a common avdd-supply property for the 1.8V > >> supplies > >> > >> Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 9 > >> 1 file changed, 9 insertions(+) > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt > >> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt index > >> 6532a59..13d53bc 100644 > >> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt > >> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt > >> > >> @@ -56,6 +56,15 @@ Optional properties: > >> - adi,disable-timing-generator: Only for ADV7533. Disables the internal > >> > >> timing generator. The chip will rely on the sync signals in the DSI data > >> lanes, rather than generate its own timings for HDMI output. > >> +- avdd-supply: A common 1.8V supply that powers up the AVDD, DVDD and > >> PVDD > >> + pins. On ADV7511, it also feeds to the BGVDD pin. On ADV7533, it also > >> powers > >> + up the A2VDD pin. > >> +- v3p3-supply: A 3.3V supply that powers up the pin called DVDD_3V on > >> + ADV7511 and V3P3 on ADV7533. > >> + > >> +ADV7533 specific supplies: > >> +- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can > >> be > >> + either 1.2V or 1.8V. > >> > >> Required nodes: -- Regards, Laurent Pinchart
Question regarding clocks in the DW-HDMI DT bindings
Hi Mike, On Monday 28 Nov 2016 22:27:01 Michael Turquette wrote: > On Mon, Nov 28, 2016 at 10:04 PM, Laurent Pinchart wrote: > > On Monday 28 Nov 2016 13:56:11 Michael Turquette wrote: > >> On Fri, Nov 25, 2016 at 7:22 AM, Laurent Pinchart wrote: > >>> On Friday 25 Nov 2016 10:56:53 Andy Yan wrote: > On 2016å¹´11æ25æ¥ 07:26, Laurent Pinchart wrote: > > On Friday 25 Nov 2016 00:16:00 Vladimir Zapolskiy wrote: > >> On 11/25/2016 12:07 AM, Fabio Estevam wrote: > >>> On Thu, Nov 24, 2016 at 7:16 PM, Laurent Pinchart wrote: > Hi Andy, > > As the author of the DW-HDMI DT bindings this question is > addressed to you, but information from anyone is more than welcome. > > The DT bindings specify two clocks named "iahb" and "isfr" but > don't describe them. While I assume that the "isfr" clock > corresponds to the "isfrclk" input signal of the DW HDMI, there is > no "iahb" clock described in the IP core datasheet. > >>> > >>> i.MX6Q has a DW-HDMI IP block. > >>> > >>> The names in the devicetree binding matches the ones listed at the > >>> i.MX6Q Reference Manual - Table 33-1. HDMI Clocks > >> > >> correct, for your convenience the table is copied below: > >> > >> Clock name | Clock Root | Description > >> ---++--- > >> iahbclk | ahb_clk_root | Bus clock > >> icecclk | ckil_sync_clk_root | CEC low-frequency clock (32kHZ) > >> ihclk| ahb_clk_root | Module clock > >> isfrclk | video_27m_clk_root | Internal SFR clock (video clock > >> 27MHz) > >> > >> Here AHB stands for ARM Advanced High-performance Bus. > > > > That's what I suspected. I believe the "iahb" name is wrong, as the > > DW HDMI TX IP core clearly documents the bus clock as being called > > "iapbclk". We could rename that in the DT bindings (with > > compatibility code in the driver to keep supporting the old name) but > > it might not be worth it. The bindings should however document that > > the "iahb" clock is the IP core's "iapbclk" bus clock. > > I got the clock name from I.MX6Q TRM, I also checked the name again > with Rockchip IC design team now, hope to get some new information > soon. > >>> > >>> Thank you. While at it, could you ask them which version of the DW HDMI > >>> IP used in the SoC ? > >>> > > Another question I have about the bus clock (CC'ing the devicetree > > mailing list as well as the clock maintainers) is whether it should > > be made optional. The clock is obviously mandatory from a hardware > > point of view (given that APB is a synchronous bus and thus requires a > > clock), but in some SoCs (specifically for the Renesas SoCs) that > > clock is always on and can't be controlled. We already omit bus clocks > > in DT for most IP cores when the clock can never be controlled (and we > > also omit a bunch of other clocks that we don't even know exist), so > > it could make sense to make the clock optional. Otherwise there would > > be runtime overhead trying to handle a clock that can't be controlled. > > If this is the case on Renesas SOCs, we can consider make the clock as > optional. Or move all the clock operations to platform specific > code(dw_hdmi-rockchip.c/dw_hdmi-imx.c)? > >>> > >>> I'd prefer keeping the code generic, otherwise we'd end up with > >>> platform-specific code that would perform the same operations on most > >>> platforms. I'll submit a patch soon to make the clock optional, we can > >>> discuss it then. > >> > >> Yes, let's keep the code generic. Absence of a "standard' clock is OK > >> and we should accept the small overhead incurred in providing a > >> solution that works for everyone. This prevents hardware-specific > >> hacks in the driver. > >> > >> Related: we really should model bus clocks whenever possible. I've > >> seen other attempts to merge functional/logic and bus clocks into a > >> single entity (e.g. a single struct clk_hw/clk_core that turns both > >> clocks on and off) and this defeats some fine-grained power management > >> scenarios that the hardware designers had in mind when creating > >> separate controls for the clocks. > > > > Sure, but that wasn't really the question :-) When the bus clock is > > separately controllable then I agree it should be modelled separately in > > DT. In my case the bus clock is always on, and I'm thus wondering whether > > it would be better to make it optional in DT to reduce the runtime > > overhead incurred by trying to control something that can't be > > controlled. > > I thought I answered this, but maybe not directly enough :-) > > We should make the clock mandatory in DT if the physical line must be > there. This is regardless of whether a given chip/IP variant has
[PATCH v5 8/8] iommu/rockchip: Enable Rockchip IOMMU on ARM64
Am Montag, 28. November 2016, 16:42:27 schrieb Brian Norris: > Hi, > > On Fri, Jun 24, 2016 at 10:13:33AM +0800, Shunqian Zheng wrote: > > From: Simon Xue > > > > This patch makes it possible to compile the rockchip-iommu driver on > > ARM64, so that it can be used with 64-bit SoCs equipped with this type > > of IOMMU. > > > > Signed-off-by: Simon Xue > > Signed-off-by: Shunqian Zheng > > Signed-off-by: Tomasz Figa > > --- > > > > drivers/iommu/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > > index ad08603..5572621 100644 > > --- a/drivers/iommu/Kconfig > > +++ b/drivers/iommu/Kconfig > > @@ -218,7 +218,7 @@ config OMAP_IOMMU_DEBUG > > > > config ROCKCHIP_IOMMU > > > > bool "Rockchip IOMMU Support" > > > > - depends on ARM > > + depends on ARM || ARM64 > > > > depends on ARCH_ROCKCHIP || COMPILE_TEST > > select IOMMU_API > > select ARM_DMA_USE_IOMMU > > Whatever happened with the rest of this series? Some of the IOMMU bits > made it, but the DRM fixes never did, and so this didn't get applied. > This leaves the whole DRM stack unusable on ARM64 Rockchip systems. > > The patch context has changed a bit on patch 7 (and maybe 6?), so > somebody will need to refresh those on the latest upstream. I've tried forward-porting these when going through Caesars VOP dts patches, but was somewhat unsucessful in my small attempt at the time - see [0]. Heiko [0] https://lkml.org/lkml/2016/11/14/519
[PATCH v2] drm: tilcdc: fix parsing of some DT properties
On 11/28/16 13:37, Bartosz Golaszewski wrote:
> The DT binding for tildc is not consistent with the driver code: there
> are two options - 'max-width' and 'max-pixelclock' specified in the
> documentation which are parsed as 'ti,max-width' and
> 'ti'max-pixelclock' respectively.
>
> Make the driver code consistent with the binding.
>
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Jyri Sarha
I'll pick this up for a pull request that I'll send shortly.
> ---
> v1 -> v2:
> - fix max-pixelclock too
>
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 5efb369..bd0a3bd 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -296,12 +296,12 @@ static int tilcdc_init(struct drm_driver *ddrv, struct
> device *dev)
>
> DBG("Maximum Bandwidth Value %d", priv->max_bandwidth);
>
> - if (of_property_read_u32(node, "ti,max-width", &priv->max_width))
> + if (of_property_read_u32(node, "max-width", &priv->max_width))
> priv->max_width = TILCDC_DEFAULT_MAX_WIDTH;
>
> DBG("Maximum Horizontal Pixel Width Value %dpixels", priv->max_width);
>
> - if (of_property_read_u32(node, "ti,max-pixelclock",
> + if (of_property_read_u32(node, "max-pixelclock",
> &priv->max_pixelclock))
> priv->max_pixelclock = TILCDC_DEFAULT_MAX_PIXELCLOCK;
>
>
[PATCH] drm/doc: Fix indenting in drm_modeset_lock.c comment
This isn't part of the code snippet anymore ... Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_modeset_lock.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c index 9059fe3145a1..3551ae31f143 100644 --- a/drivers/gpu/drm/drm_modeset_lock.c +++ b/drivers/gpu/drm/drm_modeset_lock.c @@ -52,12 +52,12 @@ * drm_modeset_drop_locks(&ctx); * drm_modeset_acquire_fini(&ctx); * - * On top of of these per-object locks using &ww_mutex there's also an overall - * dev->mode_config.lock, for protecting everything else. Mostly this means - * probe state of connectors, and preventing hotplug add/removal of connectors. + * On top of of these per-object locks using &ww_mutex there's also an overall + * dev->mode_config.lock, for protecting everything else. Mostly this means + * probe state of connectors, and preventing hotplug add/removal of connectors. * - * Finally there's a bunch of dedicated locks to protect drm core internal - * lists and lookup data structures. + * Finally there's a bunch of dedicated locks to protect drm core internal + * lists and lookup data structures. */ static DEFINE_WW_CLASS(crtc_ww_class); -- 2.10.2
[PATCH v3 01/13] drm: Don't include in
On Tue, Nov 29, 2016 at 11:04:31AM +0200, Laurent Pinchart wrote: > used to define most of the in-kernel KMS API. It has > now been split into separate files for each object type, but still > includes most other KMS headers to avoid breaking driver compilation. > > As a step towards fixing that problem, remove the inclusion of > from and include it instead where > appropriate. Also remove the forward declarations of the drm_encoder and > drm_encoder_helper_funcs structures from as they're not > needed in the header. > > now has to include and contain a > forward declaration of struct drm_encoder in order to allow including it > as the first header in a compilation unit. > > Signed-off-by: Laurent Pinchart Assuming it all still compiles the various defconfigs we have (I didn't check that, but lgtm otherwise): Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 1 + > drivers/gpu/drm/ast/ast_drv.h | 1 + > drivers/gpu/drm/bochs/bochs.h | 1 + > drivers/gpu/drm/cirrus/cirrus_drv.h | 1 + > drivers/gpu/drm/drm_connector.c | 1 + > drivers/gpu/drm/drm_crtc_helper.c | 1 + > drivers/gpu/drm/drm_edid.c | 1 + > drivers/gpu/drm/drm_mode_config.c | 1 + > drivers/gpu/drm/drm_of.c| 1 + > drivers/gpu/drm/drm_plane_helper.c | 1 + > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 2 ++ > drivers/gpu/drm/gma500/psb_intel_drv.h | 1 + > drivers/gpu/drm/i915/intel_drv.h| 1 + > drivers/gpu/drm/mgag200/mgag200_drv.h | 1 + > drivers/gpu/drm/nouveau/nouveau_connector.h | 1 + > drivers/gpu/drm/qxl/qxl_drv.h | 1 + > drivers/gpu/drm/radeon/radeon_mode.h| 1 + > drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 1 + > drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 1 + > drivers/gpu/drm/tegra/drm.h | 1 + > drivers/gpu/drm/vc4/vc4_drv.h | 2 ++ > drivers/gpu/drm/virtio/virtgpu_drv.h| 1 + > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 1 + > include/drm/drm_crtc.h | 3 --- > include/drm/drm_encoder.h | 3 +++ > include/drm/drm_encoder_slave.h | 1 + > include/drm/drm_modeset_helper_vtables.h| 1 + > 27 files changed, 30 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h > b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h > index 1e23334b07fb..fac06064a8f5 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h > @@ -32,6 +32,7 @@ > > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h > index 908011d2c8f5..6f3b6f50cf52 100644 > --- a/drivers/gpu/drm/ast/ast_drv.h > +++ b/drivers/gpu/drm/ast/ast_drv.h > @@ -28,6 +28,7 @@ > #ifndef __AST_DRV_H__ > #define __AST_DRV_H__ > > +#include > #include > > #include > diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h > index 32dfe418cc98..f626bab7f5e3 100644 > --- a/drivers/gpu/drm/bochs/bochs.h > +++ b/drivers/gpu/drm/bochs/bochs.h > @@ -4,6 +4,7 @@ > #include > #include > #include > +#include > #include > > #include > diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h > b/drivers/gpu/drm/cirrus/cirrus_drv.h > index 2188d6b61b3e..b59aeef4635a 100644 > --- a/drivers/gpu/drm/cirrus/cirrus_drv.h > +++ b/drivers/gpu/drm/cirrus/cirrus_drv.h > @@ -13,6 +13,7 @@ > > #include > > +#include > #include > > #include > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index b5c6a8ee831e..5f1e1f190d30 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -23,6 +23,7 @@ > #include > #include > #include > +#include > > #include "drm_crtc_internal.h" > #include "drm_internal.h" > diff --git a/drivers/gpu/drm/drm_crtc_helper.c > b/drivers/gpu/drm/drm_crtc_helper.c > index 5d2cb138eba6..b3fc23313cc3 100644 > --- a/drivers/gpu/drm/drm_crtc_helper.c > +++ b/drivers/gpu/drm/drm_crtc_helper.c > @@ -36,6 +36,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 7eec18925b70..a9e3cc3990c1 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -35,6 +35,7 @@ > #include > #include > #include > +#include > #include > > #define version_greater(edid, maj, min) \ > diff --git a/drivers/gpu/drm/drm_mode_config.c > b/drivers/gpu/drm/drm_mode_config.c > index 2735a5847ffa..09b1d8f267a6 100644 > --- a/drivers/gpu/drm/drm_mode_config.c > +++ b/drivers/gpu/drm/drm_mode_config.c > @@ -20,6 +20,7 @@ > * OF THIS SOFTWARE. > */ > > +#include > #include > #include > > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c > index 47848ed8ca4
[PATCH v3 02/13] drm: Fix compilation warning caused by static inline forward declaration
On Tue, Nov 29, 2016 at 11:04:32AM +0200, Laurent Pinchart wrote: > The drm_crtc_mask() function used in is a static > inline defined in . If the first header is included in a > compilation unit without the second one, the following compilation > warning will be issued. > > In file included from /drivers/gpu/drm/drm_bridge.c:29:0: > /include/drm/drm_encoder.h:192:95: warning: âdrm_crtc_maskâ used > but never defined > static inline uint32_t drm_crtc_mask(const struct drm_crtc *crtc); > > Fix this by including the header defining the function instead of using > a forward declaration. > > Signed-off-by: Laurent Pinchart Reviewed-by: Daniel Vetter > --- > include/drm/drm_encoder.h | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h > index cec6ac45c6cc..5f58f65344e0 100644 > --- a/include/drm/drm_encoder.h > +++ b/include/drm/drm_encoder.h > @@ -25,6 +25,7 @@ > > #include > #include > +#include > #include > #include > > @@ -191,9 +192,6 @@ static inline unsigned int drm_encoder_index(struct > drm_encoder *encoder) > return encoder->index; > } > > -/* FIXME: We have an include file mess still, drm_crtc.h needs untangling. */ > -static inline uint32_t drm_crtc_mask(const struct drm_crtc *crtc); > - > /** > * drm_encoder_crtc_ok - can a given crtc drive a given encoder? > * @encoder: encoder to test > -- > Regards, > > Laurent Pinchart > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v3 03/13] drm: bridge: Link encoder and bridge in core code
On Tue, Nov 29, 2016 at 11:04:33AM +0200, Laurent Pinchart wrote:
> Instead of linking encoders and bridges in every driver (and getting it
> wrong half of the time, as many drivers forget to set the drm_bridge
> encoder pointer), do so in core code. The drm_bridge_attach() function
> needs the encoder and optional previous bridge to perform that task,
> update all the callers.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 4 +-
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 +-
> drivers/gpu/drm/bridge/dw-hdmi.c | 3 +-
> drivers/gpu/drm/drm_bridge.c | 46
> --
> drivers/gpu/drm/drm_simple_kms_helper.c| 4 +-
> drivers/gpu/drm/exynos/exynos_dp.c | 5 +--
> drivers/gpu/drm/exynos/exynos_drm_dsi.c| 6 +--
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +--
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 5 +--
> drivers/gpu/drm/imx/imx-ldb.c | 6 +--
> drivers/gpu/drm/imx/parallel-display.c | 4 +-
> drivers/gpu/drm/mediatek/mtk_dpi.c | 8 ++--
> drivers/gpu/drm/mediatek/mtk_dsi.c | 24 ++-
> drivers/gpu/drm/mediatek/mtk_hdmi.c| 11 +++---
> drivers/gpu/drm/msm/dsi/dsi_manager.c | 17 +---
> drivers/gpu/drm/msm/edp/edp_bridge.c | 2 +-
> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 2 +-
> drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 5 +--
> drivers/gpu/drm/sti/sti_dvo.c | 3 +-
> drivers/gpu/drm/sti/sti_hda.c | 3 +-
> drivers/gpu/drm/sti/sti_hdmi.c | 3 +-
> drivers/gpu/drm/sun4i/sun4i_rgb.c | 13 +++---
> include/drm/drm_bridge.h | 3 +-
> 23 files changed, 83 insertions(+), 103 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> index 6119b5085501..e7799b6ee829 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> @@ -230,9 +230,7 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device
> *dev,
> of_node_put(np);
>
> if (bridge) {
> - output->encoder.bridge = bridge;
> - bridge->encoder = &output->encoder;
> - ret = drm_bridge_attach(dev, bridge);
> + ret = drm_bridge_attach(&output->encoder, bridge, NULL);
> if (!ret)
> return 0;
> }
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 6e0447f329a2..1835f1fdad19 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1227,12 +1227,10 @@ static int analogix_dp_create_bridge(struct
> drm_device *drm_dev,
>
> dp->bridge = bridge;
>
> - dp->encoder->bridge = bridge;
> bridge->driver_private = dp;
> - bridge->encoder = dp->encoder;
> bridge->funcs = &analogix_dp_bridge_funcs;
>
> - ret = drm_bridge_attach(drm_dev, bridge);
> + ret = drm_bridge_attach(dp->encoder, bridge, NULL);
> if (ret) {
> DRM_ERROR("failed to attach drm bridge\n");
> return -EINVAL;
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index b71088dab268..432e0e3fff72 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1841,13 +1841,12 @@ static int dw_hdmi_register(struct drm_device *drm,
> struct dw_hdmi *hdmi)
> hdmi->bridge = bridge;
> bridge->driver_private = hdmi;
> bridge->funcs = &dw_hdmi_bridge_funcs;
> - ret = drm_bridge_attach(drm, bridge);
> + ret = drm_bridge_attach(encoder, bridge, NULL);
> if (ret) {
> DRM_ERROR("Failed to initialize bridge with drm\n");
> return -EINVAL;
> }
>
> - encoder->bridge = bridge;
> hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD;
>
> drm_connector_helper_add(&hdmi->connector,
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 0ee052b7c21a..850bd6509ef1 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -26,6 +26,7 @@
> #include
>
> #include
> +#include
>
> /**
> * DOC: overview
> @@ -92,32 +93,53 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> EXPORT_SYMBOL(drm_bridge_remove);
>
> /**
> - * drm_bridge_attach - associate given bridge to our DRM device
> + * drm_bridge_attach - attach the bridge to an encoder's chain
> *
> - * @dev: DRM device
> - * @bridge: bridge control structure
> + * @encoder: DRM encoder
> + * @bridge: bridge to attach
> + * @previous: previous bridge in the ch
[PATCH v3 01/13] drm: Don't include in
Hi Daniel, On Tuesday 29 Nov 2016 10:30:36 Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 11:04:31AM +0200, Laurent Pinchart wrote: > > used to define most of the in-kernel KMS API. It has > > now been split into separate files for each object type, but still > > includes most other KMS headers to avoid breaking driver compilation. > > > > As a step towards fixing that problem, remove the inclusion of > > from and include it instead where > > appropriate. Also remove the forward declarations of the drm_encoder and > > drm_encoder_helper_funcs structures from as they're not > > needed in the header. > > > > now has to include and contain a > > forward declaration of struct drm_encoder in order to allow including it > > as the first header in a compilation unit. > > > > Signed-off-by: Laurent Pinchart > > > > Assuming it all still compiles the various defconfigs we have (I didn't > check that, but lgtm otherwise): I've done my best to try and compile all affected drivers. 0day hasn't complained either so far, so we should be good. > Reviewed-by: Daniel Vetter > > > --- > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 1 + > > drivers/gpu/drm/ast/ast_drv.h | 1 + > > drivers/gpu/drm/bochs/bochs.h | 1 + > > drivers/gpu/drm/cirrus/cirrus_drv.h | 1 + > > drivers/gpu/drm/drm_connector.c | 1 + > > drivers/gpu/drm/drm_crtc_helper.c | 1 + > > drivers/gpu/drm/drm_edid.c | 1 + > > drivers/gpu/drm/drm_mode_config.c | 1 + > > drivers/gpu/drm/drm_of.c| 1 + > > drivers/gpu/drm/drm_plane_helper.c | 1 + > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 2 ++ > > drivers/gpu/drm/gma500/psb_intel_drv.h | 1 + > > drivers/gpu/drm/i915/intel_drv.h| 1 + > > drivers/gpu/drm/mgag200/mgag200_drv.h | 1 + > > drivers/gpu/drm/nouveau/nouveau_connector.h | 1 + > > drivers/gpu/drm/qxl/qxl_drv.h | 1 + > > drivers/gpu/drm/radeon/radeon_mode.h| 1 + > > drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 1 + > > drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 1 + > > drivers/gpu/drm/tegra/drm.h | 1 + > > drivers/gpu/drm/vc4/vc4_drv.h | 2 ++ > > drivers/gpu/drm/virtio/virtgpu_drv.h| 1 + > > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 1 + > > include/drm/drm_crtc.h | 3 --- > > include/drm/drm_encoder.h | 3 +++ > > include/drm/drm_encoder_slave.h | 1 + > > include/drm/drm_modeset_helper_vtables.h| 1 + > > 27 files changed, 30 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h index > > 1e23334b07fb..fac06064a8f5 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h > > @@ -32,6 +32,7 @@ > > > > #include > > #include > > > > +#include > > > > #include > > #include > > #include > > > > diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h > > index 908011d2c8f5..6f3b6f50cf52 100644 > > --- a/drivers/gpu/drm/ast/ast_drv.h > > +++ b/drivers/gpu/drm/ast/ast_drv.h > > @@ -28,6 +28,7 @@ > > > > #ifndef __AST_DRV_H__ > > #define __AST_DRV_H__ > > > > +#include > > > > #include > > > > #include > > > > diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h > > index 32dfe418cc98..f626bab7f5e3 100644 > > --- a/drivers/gpu/drm/bochs/bochs.h > > +++ b/drivers/gpu/drm/bochs/bochs.h > > @@ -4,6 +4,7 @@ > > > > #include > > #include > > #include > > > > +#include > > > > #include > > > > #include > > > > diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h > > b/drivers/gpu/drm/cirrus/cirrus_drv.h index 2188d6b61b3e..b59aeef4635a > > 100644 > > --- a/drivers/gpu/drm/cirrus/cirrus_drv.h > > +++ b/drivers/gpu/drm/cirrus/cirrus_drv.h > > @@ -13,6 +13,7 @@ > > > > #include > > > > +#include > > > > #include > > > > #include > > > > diff --git a/drivers/gpu/drm/drm_connector.c > > b/drivers/gpu/drm/drm_connector.c index b5c6a8ee831e..5f1e1f190d30 100644 > > --- a/drivers/gpu/drm/drm_connector.c > > +++ b/drivers/gpu/drm/drm_connector.c > > @@ -23,6 +23,7 @@ > > > > #include > > #include > > #include > > > > +#include > > > > #include "drm_crtc_internal.h" > > #include "drm_internal.h" > > > > diff --git a/drivers/gpu/drm/drm_crtc_helper.c > > b/drivers/gpu/drm/drm_crtc_helper.c index 5d2cb138eba6..b3fc23313cc3 > > 100644 > > --- a/drivers/gpu/drm/drm_crtc_helper.c > > +++ b/drivers/gpu/drm/drm_crtc_helper.c > > @@ -36,6 +36,7 @@ > > > > #include > > #include > > #include > > > > +#include > > > > #include > > #include > > #include > > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > > index 7eec18925b70..a9e3cc3990c1 100644 > > --- a/drivers/gpu/drm/drm_edid.c > > +++ b/drivers/gpu/drm/
[PATCH v3 03/13] drm: bridge: Link encoder and bridge in core code
Hi Daniel,
On Tuesday 29 Nov 2016 10:35:24 Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 11:04:33AM +0200, Laurent Pinchart wrote:
> > Instead of linking encoders and bridges in every driver (and getting it
> > wrong half of the time, as many drivers forget to set the drm_bridge
> > encoder pointer), do so in core code. The drm_bridge_attach() function
> > needs the encoder and optional previous bridge to perform that task,
> > update all the callers.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 4 +-
> > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 +-
> > drivers/gpu/drm/bridge/dw-hdmi.c | 3 +-
> > drivers/gpu/drm/drm_bridge.c | 46 +
> > drivers/gpu/drm/drm_simple_kms_helper.c| 4 +-
> > drivers/gpu/drm/exynos/exynos_dp.c | 5 +--
> > drivers/gpu/drm/exynos/exynos_drm_dsi.c| 6 +--
> > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +--
> > drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 5 +--
> > drivers/gpu/drm/imx/imx-ldb.c | 6 +--
> > drivers/gpu/drm/imx/parallel-display.c | 4 +-
> > drivers/gpu/drm/mediatek/mtk_dpi.c | 8 ++--
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 24 ++-
> > drivers/gpu/drm/mediatek/mtk_hdmi.c| 11 +++---
> > drivers/gpu/drm/msm/dsi/dsi_manager.c | 17 +---
> > drivers/gpu/drm/msm/edp/edp_bridge.c | 2 +-
> > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 2 +-
> > drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 5 +--
> > drivers/gpu/drm/sti/sti_dvo.c | 3 +-
> > drivers/gpu/drm/sti/sti_hda.c | 3 +-
> > drivers/gpu/drm/sti/sti_hdmi.c | 3 +-
> > drivers/gpu/drm/sun4i/sun4i_rgb.c | 13 +++---
> > include/drm/drm_bridge.h | 3 +-
> > 23 files changed, 83 insertions(+), 103 deletions(-)
[snip]
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index 0ee052b7c21a..850bd6509ef1 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -26,6 +26,7 @@
> >
> > #include
> > #include
> > +#include
> >
> > /**
> > * DOC: overview
> > @@ -92,32 +93,53 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > EXPORT_SYMBOL(drm_bridge_remove);
> >
> > /**
> > - * drm_bridge_attach - associate given bridge to our DRM device
> > + * drm_bridge_attach - attach the bridge to an encoder's chain
> > *
> > - * @dev: DRM device
> > - * @bridge: bridge control structure
> > + * @encoder: DRM encoder
> > + * @bridge: bridge to attach
> > + * @previous: previous bridge in the chain (optional)
> > *
> > - * Called by a kms driver to link one of our encoder/bridge to the given
> > - * bridge.
> > + * Called by a kms driver to link the bridge to an encoder's chain. The
> > previous
> > + * argument specifies the previous bridge in the chain. If NULL, the
> > bridge is
> > + * linked directly at the encoder's output. Otherwise it is linked at the
> > + * previous bridge's output.
> > *
> > - * Note that setting up links between the bridge and our encoder/bridge
> > - * objects needs to be handled by the kms driver itself.
> > + * If non-NULL the previous bridge must be already attached by a call to
> > this
> > + * function.
> > *
> > * RETURNS:
> > * Zero on success, error code on failure
> > */
> > -int drm_bridge_attach(struct drm_device *dev, struct drm_bridge *bridge)
> > +int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge
> > *bridge,
> > + struct drm_bridge *previous)
> > {
> > - if (!dev || !bridge)
> > + int ret;
> > +
> > + if (!encoder || !bridge)
> > + return -EINVAL;
> > +
> > + if (previous && (!previous->dev || previous->encoder != encoder))
> > return -EINVAL;
>
> Not sure we want to allow setting both encoder and bridge for chaining.
> I'd kinda expect that for chained use-case the bridge doesn't care that
> much who started the chain. And if not we can always create a helper to
> look up the drm_encoder.
As bridge drivers currently create connectors (I'd like to change that at some
point, but one thing at a time) they need to call
drm_mode_connector_attach_encoder() and thus need to have access to the
drm_encoder object at the beginning of the chain. The drm_bridge structure has
an encoder field, it seems to me that the easiest is to always populate it,
regardless of the position of the bridge in the chain.
> Also, should we convert these to WARN_ON, they're kinda glaring driver (or
> well DT) bugs?
Yes, that seems like a good idea. I can add a patch on top of this one to
convert the checks to WARN_ON, as I'd rather separate that change from the API
change.
> Otherwise looks al
[PATCH] drm: Fix locking cargo-cult in encoder/plane init/cleanup
Encoders&planes can't be hotplugged, we dont need looking for this
since it's all single-threaded driver setup/teardown code. CRTCs
already don't grab locks.
While at it I noticed that plane's are missing the
drm_modeset_lock_fini() call, so add it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_encoder.c | 9 +
drivers/gpu/drm/drm_plane.c | 4 ++--
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index 5c067719164d..992879f15f23 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -110,11 +110,9 @@ int drm_encoder_init(struct drm_device *dev,
{
int ret;
- drm_modeset_lock_all(dev);
-
ret = drm_mode_object_get(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER);
if (ret)
- goto out_unlock;
+ return ret;
encoder->dev = dev;
encoder->encoder_type = encoder_type;
@@ -142,9 +140,6 @@ int drm_encoder_init(struct drm_device *dev,
if (ret)
drm_mode_object_unregister(dev, &encoder->base);
-out_unlock:
- drm_modeset_unlock_all(dev);
-
return ret;
}
EXPORT_SYMBOL(drm_encoder_init);
@@ -164,12 +159,10 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
* the indices on the drm_encoder after us in the encoder_list.
*/
- drm_modeset_lock_all(dev);
drm_mode_object_unregister(dev, &encoder->base);
kfree(encoder->name);
list_del(&encoder->head);
dev->mode_config.num_encoder--;
- drm_modeset_unlock_all(dev);
memset(encoder, 0, sizeof(*encoder));
}
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 419ac313c36f..9147aab182c4 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -221,7 +221,8 @@ void drm_plane_cleanup(struct drm_plane *plane)
{
struct drm_device *dev = plane->dev;
- drm_modeset_lock_all(dev);
+ drm_modeset_lock_fini(&plane->mutex);
+
kfree(plane->format_types);
drm_mode_object_unregister(dev, &plane->base);
@@ -236,7 +237,6 @@ void drm_plane_cleanup(struct drm_plane *plane)
dev->mode_config.num_total_plane--;
if (plane->type == DRM_PLANE_TYPE_OVERLAY)
dev->mode_config.num_overlay_plane--;
- drm_modeset_unlock_all(dev);
WARN_ON(plane->state && !plane->funcs->atomic_destroy_state);
if (plane->state && plane->funcs->atomic_destroy_state)
--
2.10.2
[PATCH v3 04/13] drm: bridge: Detach bridge from encoder at encoder cleanup time
On Tue, Nov 29, 2016 at 11:04:34AM +0200, Laurent Pinchart wrote: > Most drivers that use bridges forgot to detach them at cleanup time. > Instead of fixing them one by one, detach the bridge in the core > drm_encoder_cleanup() function. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/drm_encoder.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c > index 5c067719164d..9c1f99646e0d 100644 > --- a/drivers/gpu/drm/drm_encoder.c > +++ b/drivers/gpu/drm/drm_encoder.c > @@ -164,6 +164,9 @@ void drm_encoder_cleanup(struct drm_encoder *encoder) >* the indices on the drm_encoder after us in the encoder_list. >*/ > > + if (encoder->bridge) > + drm_bridge_detach(encoder->bridge); Means we bake in drm_bridge much more as a core thing, but I guess that's ok. But there's 3 callers of drm_bridge_detach outside of the drm core, can't we remove them and drop the EXPORT_SYMBOL for drm_bridge_detach? What's it still needed for? I think that cleanup should done in this patch here - drm_bridge_detach WARN_ONs if the bridge is already detached ... -Daniel > + > drm_modeset_lock_all(dev); > drm_mode_object_unregister(dev, &encoder->base); > kfree(encoder->name); > -- > Regards, > > Laurent Pinchart > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v3 07/13] drm: bridge: vga-dac: Add adi,adv7123 compatible string
On Tue, Nov 29, 2016 at 11:04:37AM +0200, Laurent Pinchart wrote: > The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be > controlled through a power save pin, and requires a power supply. > However, on most boards where the device is used neither the power save > signal nor the power supply are controllable. > > To avoid developing a separate device-specific driver add an > "adi,adv7123" compatible entry to the dumb-vga-dac driver. This will > allow supporting most ADV7123-based boards easily, while allowing future > development of an adv7123 driver when needed without breaking backward > compatibility. > > Signed-off-by: Laurent Pinchart Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/e9e9fe3e/attachment.sig>
[PATCH v3 06/13] drm: bridge: Add LVDS encoder driver
On Tue, Nov 29, 2016 at 11:04:36AM +0200, Laurent Pinchart wrote:
> The LVDS encoder driver is a DRM bridge driver that supports the
> parallel to LVDS encoders that don't require any configuration. The
> driver thus doesn't interact with the device, but creates an LVDS
> connector for the panel and exposes its size and timing based on
> information retrieved from DT.
>
> Signed-off-by: Laurent Pinchart
Since it's 100% dummy, why put LVDS into the name? This little thing here
could be our generic "wrap drm_panel and attach it to a chain" helper. So
what about calling this _The_ drm_panel_bridge, and also linking it into
docs to feature it a bit more prominently.
I came up with this because I spotted some refactoring belows for building
this helper, until I realized that this driver _is_ the helper I think we
want ;-) Only thing missing is an exported function to instantiate a
bridge with just a drm_panel as the parameter. And putting it into the
drm_kms_helper.ko module.
> +static enum drm_connector_status
> +lvds_connector_detect(struct drm_connector *connector, bool force)
> +{
> + return connector_status_connected;
> +}
We have piles of this exact dummy callback all over, maybe make it the
default and rip them all out?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v3 09/13] drm: Add encoder_type field to the drm_bridge structure
On Tue, Nov 29, 2016 at 11:04:39AM +0200, Laurent Pinchart wrote:
> The drm_bridge object models on- or off-chip hardware encoders and
> provide an abstract control API to display drivers. In order to help
> display drivers creating the right kind of drm_encoder object, expose
> the type of the hardware encoder associated with each bridge.
>
> Signed-off-by: Laurent Pinchart
DRM_MODE_ENCODER_BRIDGE. Problem solved, because in reality no one cares
one iota about the encoder type.
-Daniel
> ---
> Changes since v1:
>
> - Clarify documentation
> ---
> include/drm/drm_bridge.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 94e5ee96b3b5..0643b6ce27de 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -194,6 +194,14 @@ struct drm_bridge {
> #endif
> struct list_head list;
>
> + /**
> + * @encoder_type:
> + *
> + * Type of the hardware encoder modeled by the bridge as one of the
> + * DRM_MODE_ENCODER_* types. For the last bridge in the chain this will
> + * usually be identical to the bridge's &drm_encoder encoder_type.
> + */
> + int encoder_type;
> const struct drm_bridge_funcs *funcs;
> void *driver_private;
> };
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v3 09/13] drm: Add encoder_type field to the drm_bridge structure
On Tuesday 29 Nov 2016 10:56:53 Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 11:04:39AM +0200, Laurent Pinchart wrote: > > The drm_bridge object models on- or off-chip hardware encoders and > > provide an abstract control API to display drivers. In order to help > > display drivers creating the right kind of drm_encoder object, expose > > the type of the hardware encoder associated with each bridge. > > > > Signed-off-by: Laurent Pinchart > > > > DRM_MODE_ENCODER_BRIDGE. Problem solved, because in reality no one cares > one iota about the encoder type. It's exposed to userspace though, are you 100% sure we won't break anything ? -- Regards, Laurent Pinchart
[PATCH] drm/vc4: Fix race between page flip completion event and clean-up
On 28 November 2016 at 22:31, Eric Anholt wrote: > There was a small window where a userspace program could submit > a pageflip after receiving a pageflip completion event yet still > receive EBUSY. > > Signed-off-by: Derek Foreman > Signed-off-by: Eric Anholt > Reviewed-by: Eric Anholt Reviewed-by: Daniel Stone
[PATCH v3 03/13] drm: bridge: Link encoder and bridge in core code
On Tue, Nov 29, 2016 at 11:43:19AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tuesday 29 Nov 2016 10:35:24 Daniel Vetter wrote:
> > On Tue, Nov 29, 2016 at 11:04:33AM +0200, Laurent Pinchart wrote:
> > > Instead of linking encoders and bridges in every driver (and getting it
> > > wrong half of the time, as many drivers forget to set the drm_bridge
> > > encoder pointer), do so in core code. The drm_bridge_attach() function
> > > needs the encoder and optional previous bridge to perform that task,
> > > update all the callers.
> > >
> > > Signed-off-by: Laurent Pinchart
> > >
> > > ---
> > >
> > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 4 +-
> > > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 +-
> > > drivers/gpu/drm/bridge/dw-hdmi.c | 3 +-
> > > drivers/gpu/drm/drm_bridge.c | 46 +
> > > drivers/gpu/drm/drm_simple_kms_helper.c| 4 +-
> > > drivers/gpu/drm/exynos/exynos_dp.c | 5 +--
> > > drivers/gpu/drm/exynos/exynos_drm_dsi.c| 6 +--
> > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +--
> > > drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 5 +--
> > > drivers/gpu/drm/imx/imx-ldb.c | 6 +--
> > > drivers/gpu/drm/imx/parallel-display.c | 4 +-
> > > drivers/gpu/drm/mediatek/mtk_dpi.c | 8 ++--
> > > drivers/gpu/drm/mediatek/mtk_dsi.c | 24 ++-
> > > drivers/gpu/drm/mediatek/mtk_hdmi.c| 11 +++---
> > > drivers/gpu/drm/msm/dsi/dsi_manager.c | 17 +---
> > > drivers/gpu/drm/msm/edp/edp_bridge.c | 2 +-
> > > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 2 +-
> > > drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 5 +--
> > > drivers/gpu/drm/sti/sti_dvo.c | 3 +-
> > > drivers/gpu/drm/sti/sti_hda.c | 3 +-
> > > drivers/gpu/drm/sti/sti_hdmi.c | 3 +-
> > > drivers/gpu/drm/sun4i/sun4i_rgb.c | 13 +++---
> > > include/drm/drm_bridge.h | 3 +-
> > > 23 files changed, 83 insertions(+), 103 deletions(-)
>
> [snip]
>
> > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > > index 0ee052b7c21a..850bd6509ef1 100644
> > > --- a/drivers/gpu/drm/drm_bridge.c
> > > +++ b/drivers/gpu/drm/drm_bridge.c
> > > @@ -26,6 +26,7 @@
> > >
> > > #include
> > > #include
> > > +#include
> > >
> > > /**
> > > * DOC: overview
> > > @@ -92,32 +93,53 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > > EXPORT_SYMBOL(drm_bridge_remove);
> > >
> > > /**
> > > - * drm_bridge_attach - associate given bridge to our DRM device
> > > + * drm_bridge_attach - attach the bridge to an encoder's chain
> > > *
> > > - * @dev: DRM device
> > > - * @bridge: bridge control structure
> > > + * @encoder: DRM encoder
> > > + * @bridge: bridge to attach
> > > + * @previous: previous bridge in the chain (optional)
> > > *
> > > - * Called by a kms driver to link one of our encoder/bridge to the given
> > > - * bridge.
> > > + * Called by a kms driver to link the bridge to an encoder's chain. The
> > > previous
> > > + * argument specifies the previous bridge in the chain. If NULL, the
> > > bridge is
> > > + * linked directly at the encoder's output. Otherwise it is linked at the
> > > + * previous bridge's output.
> > > *
> > > - * Note that setting up links between the bridge and our encoder/bridge
> > > - * objects needs to be handled by the kms driver itself.
> > > + * If non-NULL the previous bridge must be already attached by a call to
> > > this
> > > + * function.
> > > *
> > > * RETURNS:
> > > * Zero on success, error code on failure
> > > */
> > > -int drm_bridge_attach(struct drm_device *dev, struct drm_bridge *bridge)
> > > +int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge
> > > *bridge,
> > > + struct drm_bridge *previous)
> > > {
> > > - if (!dev || !bridge)
> > > + int ret;
> > > +
> > > + if (!encoder || !bridge)
> > > + return -EINVAL;
> > > +
> > > + if (previous && (!previous->dev || previous->encoder != encoder))
> > > return -EINVAL;
> >
> > Not sure we want to allow setting both encoder and bridge for chaining.
> > I'd kinda expect that for chained use-case the bridge doesn't care that
> > much who started the chain. And if not we can always create a helper to
> > look up the drm_encoder.
>
> As bridge drivers currently create connectors (I'd like to change that at
> some
> point, but one thing at a time) they need to call
> drm_mode_connector_attach_encoder() and thus need to have access to the
> drm_encoder object at the beginning of the chain. The drm_bridge structure
> has
> an encoder field, it seems to me that the easiest is to always populate it,
> regardless of the position of the bridge in the chain.
I m
[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 Michel Dänzer changed: What|Removed |Added Component|Driver/Radeon |DRM/Radeon QA Contact|xorg-team at lists.x.org | Product|xorg|DRI Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/6651470f/attachment.html>
[PULL] drm-misc-next
Hi Dave, Big thing is that drm-misc is now officially a group maintainer/committer model thing, with MAINTAINERS suitably updated. Otherwise just the usual pile of misc things all over, nothing that stands out this time around. Backmerge would also be great, since I just noticed that commit 8ae94224c9d72fc4d9aaac93b2d7833cf46d7141 Author: Sebastian Andrzej Siewior Date: Fri Nov 4 19:39:38 2016 +0100 kbuild: add -fno-PIE landed in Linus' tree a bit ago, and having that in drm trees would help with a lot of pain I'm having right now ;-) Cheers, Daniel The following changes since commit 43167f6c7d7172e0a6cb1ecaa1771a2f457fd165: Merge tag 'drm-hisilicon-next-2016-11-17' of http://github.com/zourongrong/linux into drm-next (2016-11-21 11:42:17 +1000) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2016-11-29 for you to fetch changes up to 389f78b361fcdc52a9dbb5382c3922d80b52ed9f: drm: Introduce drm_framebuffer_assign() (2016-11-29 10:22:08 +0100) Arnd Bergmann (3): vgaarb: use valid dev pointer in vgaarb_info() drm/hisilicon/hibmc: mark PM functions __maybe_unused drm: bridge: dw-hdmi: add ASoC dependency Bjorn Helgaas (2): vgaarb: Use dev_printk() when possible vgaarb: Downgrade userspace-triggerable messages to debug Chen-Yu Tsai (1): drm/bridge: dumb-vga-dac: Support a VDD regulator supply Chris Wilson (8): drm: Define drm_mm_for_each_node_in_range() drm: Check against color expansion in drm_mm_reserve_node() drm: Fixup kernel doc for driver->gem_create_object drm: Fix conflicting macro parameter in drm_mm_for_each_node_in_range() drm: Use u64_to_user_ptr() helper for blob ioctls drm: Avoid NULL dereference for DRM_LEGACY debug message drm: Fix shift operations for drm_fb_helper::drm_target_preferred() drm: Introduce drm_framebuffer_assign() Dan Carpenter (1): drm/hisilicon/hibmc: Checking for NULL instead of IS_ERR() Daniel Vetter (9): drm: Nerf DRM_CONTROL nodes MAINTAINERS: Add drm-misc MAINTAINERS: Add Archit as drm bridge maintainer MAINTAINERS: Move dma-buf to drm-misc git drm: document standard connector properties drm/atomic: Unconfuse the old_state mess in commmit_tail MAINTAINERS: Add link to drm-misc documentation drm/doc: Fix links in drm_property.c Merge remote-tracking branch 'airlied/drm-next' into drm-misc-next Gustavo Padovan (2): Revert "dma-buf/sync-file: Avoid enable fence signaling if poll(.timeout=0)" drm/fences: add DOC: for explicit fencing Jani Nikula (1): drm: also move DSI panels to the front of the connector list John Stultz (1): drm/bridge: adv7511: Add Audio support Kuninori Morimoto (1): drm: bridge: add DesignWare HDMI I2S audio support Liviu Dudau (1): drm/atomic: cleanup debugfs entries on un-registering the driver. Srinivas Kandagatla (1): drm/bridge: adv7511: Enable the audio data and clock pads on adv7533 Ville Syrjälä (3): drm: Nuke modifier[1-3] drm/atomic: Constify drm_atomic_crtc_needs_modeset() drm/edid: Consider alternate cea timings to be the same VIC .../bindings/display/bridge/dumb-vga-dac.txt | 2 + Documentation/gpu/drm-kms-helpers.rst | 3 + Documentation/gpu/drm-kms.rst | 12 ++ MAINTAINERS| 23 ++- drivers/dma-buf/sync_file.c| 3 +- drivers/gpu/drm/bridge/Kconfig | 9 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/adv7511/Kconfig | 8 + drivers/gpu/drm/bridge/adv7511/Makefile| 1 + drivers/gpu/drm/bridge/adv7511/adv7511.h | 16 ++ drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 213 + drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 4 + drivers/gpu/drm/bridge/adv7511/adv7533.c | 1 + drivers/gpu/drm/bridge/dumb-vga-dac.c | 33 drivers/gpu/drm/bridge/dw-hdmi-audio.h | 7 + drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c | 141 ++ drivers/gpu/drm/bridge/dw-hdmi.c | 22 ++- drivers/gpu/drm/bridge/dw-hdmi.h | 20 ++ drivers/gpu/drm/drm_atomic.c | 69 ++- drivers/gpu/drm/drm_atomic_helper.c| 78 drivers/gpu/drm/drm_connector.c| 44 + drivers/gpu/drm/drm_debugfs.c | 9 + drivers/gpu/drm/drm_drv.c | 6 - drivers/gpu/drm/drm_edid.c | 66 +-- drivers/gpu/drm/drm_fb_helper.c| 13 +- drivers/gpu/drm/drm_framebuffer.c | 7 + drivers/gpu/drm/drm_lock.c | 3
[PULL] drm-intel-next
Hi Dave, Final 4.10 updates: - fine-tune fb flushing and tracking (Chris Wilson) - refactor state check dumper code for more conciseness (Tvrtko) - roll out dev_priv all over the place (Tvrkto) - finally remove __i915__ magic macro (Tvrtko) - more gvt bugfixes (Zhenyu&team) - better opregion CADL handling (Jani) - refactor/clean up wm programming (Maarten) - gpu scheduler + priority boosting for flips as first user (Chris Wilson) - make fbc use more atomic (Paulo) - initial kvm-gvt framework, but not yet complete (Zhenyu&team) As discussed on irc, there's most likely going to be a super-late gvt pull request in the merge window because the kvm maintainer didn't want to do a shared topic branch because reasons. Annoying, but since gvt overall is new in 4.10, and more so kvm-gvt support the risk should be nil. Cheers, Daniel The following changes since commit b7c0e47d98249c2ddf21ea197b651093c6aaee00: Merge tag 'drm-vc4-next-2016-11-16' of https://github.com/anholt/linux into drm-next (2016-11-17 09:43:56 +1000) are available in the git repository at: git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-next-2016-11-21 for you to fetch changes up to e9cbc4bd0140e1d4e0172e2fe8fe07ba278e5980: drm/i915: Update DRIVER_DATE to 20161121 (2016-11-21 09:45:03 +0100) Final 4.10 updates: - fine-tune fb flushing and tracking (Chris Wilson) - refactor state check dumper code for more conciseness (Tvrtko) - roll out dev_priv all over the place (Tvrkto) - finally remove __i915__ magic macro (Tvrtko) - more gvt bugfixes (Zhenyu&team) - better opregion CADL handling (Jani) - refactor/clean up wm programming (Maarten) - gpu scheduler + priority boosting for flips as first user (Chris Wilson) - make fbc use more atomic (Paulo) - initial kvm-gvt framework, but not yet complete (Zhenyu&team) Arnd Bergmann (1): drm/i915: avoid harmless empty-body warning Bing Niu (1): drm/i915/gvt: don't rely on guest PPGTT entry to free old shadow data Chris Wilson (26): drm/i915: Remove chipset flush after cache flush drm/i915: Spin until breadcrumb threads are complete drm/i915: Only wait upon the execution timeline when unlocked drm/i915: Stop skipping the final clflush back to system pages drm/i915: Fix test on inputs for vma_compare() drm/i915: Give each sw_fence its own lockclass drm/i915: Create distinct lockclasses for execution vs user timelines drm/i915: Split request submit/execute phase into two drm/i915: Defer transfer onto execution timeline to actual hw submission drm/i915: Remove engine->execlist_lock drm/i915/scheduler: Signal the arrival of a new request drm/i915/scheduler: Record all dependencies upon request construction drm/i915/scheduler: Execute requests in order of priorities drm/i915: Store the execution priority on the context drm/i915/scheduler: Boost priorities for flips drm/i915: Add execution priority boosting for mmioflips drm/i915/execlists: Use a local lock for dfs_link access drm/i915: Demote i915_gem_open() debugging from DRIVER to USER drm/i915: Remove stolen object spam drm/i915: Add a few more sanity checks for stolen handling drm/i915: Move frontbuffer CS write tracking from ggtt vma to object drm/i915: Be more careful to drop the GT wakeref drm/i915: Check that each request phase is completed before retiring drm/i915: Don't touch NULL sg on i915_gem_object_get_pages_gtt() error drm/i915: Always flush the dirty CPU cache when pinning the scanout drm/i915: Skip final clflush if LLC is coherent Daniel Vetter (6): Merge tag 'gvt-next-2016-11-07' of https://github.com/01org/gvt-linux into drm-intel-next-queued Merge tag 'for-kvmgt' of git://git.kernel.org/pub/scm/virt/kvm/kvm into drm-intel-next-queued Merge tag 'gvt-next-kvmgt-framework' of https://github.com/01org/gvt-linux into drm-intel-next-queued Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued Merge tag 'gvt-next-2016-11-17' of https://github.com/01org/gvt-linux into drm-intel-next-queued drm/i915: Update DRIVER_DATE to 20161121 Du, Changbin (3): drm/i915/gvt: emulate vgpu engine reset control behavior drm/i915/gvt: fix crash in vgpu_reset_execlist drm/i915/gvt: fix mem leakage in setup_vgpu_mmio for vgpu reset Jani Nikula (4): drm/i915: rename preliminary_hw_support to alpha_support drm/i915/gvt: drop checks for early Skylake revisions drm/i915: make i915 the source of acpi device ids for _DOD drm/i915/opregion: fill in the CADL from connector list, not DIDL Jike Song (7): kvm/page_track: call notifiers with kvm_page_track_notifier_node kvm/page_track: export symbols for external usage drm/i915/gvt: r
[PATCH v3 03/13] drm: bridge: Link encoder and bridge in core code
On 11/29/2016 02:34 PM, Laurent Pinchart wrote:
> Instead of linking encoders and bridges in every driver (and getting it
> wrong half of the time, as many drivers forget to set the drm_bridge
> encoder pointer), do so in core code. The drm_bridge_attach() function
> needs the encoder and optional previous bridge to perform that task,
> update all the callers.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 4 +-
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 +-
> drivers/gpu/drm/bridge/dw-hdmi.c | 3 +-
> drivers/gpu/drm/drm_bridge.c | 46
> --
> drivers/gpu/drm/drm_simple_kms_helper.c| 4 +-
> drivers/gpu/drm/exynos/exynos_dp.c | 5 +--
> drivers/gpu/drm/exynos/exynos_drm_dsi.c| 6 +--
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +--
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 5 +--
> drivers/gpu/drm/imx/imx-ldb.c | 6 +--
> drivers/gpu/drm/imx/parallel-display.c | 4 +-
> drivers/gpu/drm/mediatek/mtk_dpi.c | 8 ++--
> drivers/gpu/drm/mediatek/mtk_dsi.c | 24 ++-
> drivers/gpu/drm/mediatek/mtk_hdmi.c| 11 +++---
> drivers/gpu/drm/msm/dsi/dsi_manager.c | 17 +---
> drivers/gpu/drm/msm/edp/edp_bridge.c | 2 +-
> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 2 +-
> drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 5 +--
> drivers/gpu/drm/sti/sti_dvo.c | 3 +-
> drivers/gpu/drm/sti/sti_hda.c | 3 +-
> drivers/gpu/drm/sti/sti_hdmi.c | 3 +-
> drivers/gpu/drm/sun4i/sun4i_rgb.c | 13 +++---
> include/drm/drm_bridge.h | 3 +-
> 23 files changed, 83 insertions(+), 103 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> index 6119b5085501..e7799b6ee829 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> @@ -230,9 +230,7 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device
> *dev,
> of_node_put(np);
>
> if (bridge) {
> - output->encoder.bridge = bridge;
> - bridge->encoder = &output->encoder;
> - ret = drm_bridge_attach(dev, bridge);
> + ret = drm_bridge_attach(&output->encoder, bridge, NULL);
> if (!ret)
> return 0;
> }
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 6e0447f329a2..1835f1fdad19 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1227,12 +1227,10 @@ static int analogix_dp_create_bridge(struct
> drm_device *drm_dev,
>
> dp->bridge = bridge;
>
> - dp->encoder->bridge = bridge;
> bridge->driver_private = dp;
> - bridge->encoder = dp->encoder;
> bridge->funcs = &analogix_dp_bridge_funcs;
>
> - ret = drm_bridge_attach(drm_dev, bridge);
> + ret = drm_bridge_attach(dp->encoder, bridge, NULL);
> if (ret) {
> DRM_ERROR("failed to attach drm bridge\n");
> return -EINVAL;
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index b71088dab268..432e0e3fff72 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1841,13 +1841,12 @@ static int dw_hdmi_register(struct drm_device *drm,
> struct dw_hdmi *hdmi)
> hdmi->bridge = bridge;
> bridge->driver_private = hdmi;
> bridge->funcs = &dw_hdmi_bridge_funcs;
> - ret = drm_bridge_attach(drm, bridge);
> + ret = drm_bridge_attach(encoder, bridge, NULL);
> if (ret) {
> DRM_ERROR("Failed to initialize bridge with drm\n");
> return -EINVAL;
> }
>
> - encoder->bridge = bridge;
> hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD;
>
> drm_connector_helper_add(&hdmi->connector,
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 0ee052b7c21a..850bd6509ef1 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -26,6 +26,7 @@
> #include
>
> #include
> +#include
>
> /**
> * DOC: overview
> @@ -92,32 +93,53 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> EXPORT_SYMBOL(drm_bridge_remove);
>
> /**
> - * drm_bridge_attach - associate given bridge to our DRM device
> + * drm_bridge_attach - attach the bridge to an encoder's chain
> *
> - * @dev: DRM device
> - * @bridge: bridge control structure
> + * @encoder: DRM encoder
> + * @bridge: bridge to attach
> + * @previous: previous bridge in the chain (optional)
> *
> - * Called by
[PATCH v3 09/13] drm: Add encoder_type field to the drm_bridge structure
On Tue, Nov 29, 2016 at 11:58:44AM +0200, Laurent Pinchart wrote: > On Tuesday 29 Nov 2016 10:56:53 Daniel Vetter wrote: > > On Tue, Nov 29, 2016 at 11:04:39AM +0200, Laurent Pinchart wrote: > > > The drm_bridge object models on- or off-chip hardware encoders and > > > provide an abstract control API to display drivers. In order to help > > > display drivers creating the right kind of drm_encoder object, expose > > > the type of the hardware encoder associated with each bridge. > > > > > > Signed-off-by: Laurent Pinchart > > > > > > > DRM_MODE_ENCODER_BRIDGE. Problem solved, because in reality no one cares > > one iota about the encoder type. > > It's exposed to userspace though, are you 100% sure we won't break anything ? We've added DP, DSI, DPMST and DPI encoder types thus far, no one screamed. We should be fine I think. Connector types are a bit different, userspace (at least X) wants to pretty-print them for xrandr names. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v3 04/13] drm: bridge: Detach bridge from encoder at encoder cleanup time
On 11/29/2016 02:34 PM, Laurent Pinchart wrote: > Most drivers that use bridges forgot to detach them at cleanup time. > Instead of fixing them one by one, detach the bridge in the core > drm_encoder_cleanup() function. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/drm_encoder.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c > index 5c067719164d..9c1f99646e0d 100644 > --- a/drivers/gpu/drm/drm_encoder.c > +++ b/drivers/gpu/drm/drm_encoder.c > @@ -164,6 +164,9 @@ void drm_encoder_cleanup(struct drm_encoder *encoder) >* the indices on the drm_encoder after us in the encoder_list. >*/ > > + if (encoder->bridge) > + drm_bridge_detach(encoder->bridge); This would require the kms driver to still detach the remaining n - 1 bridges in a possible chain. We could probably detach all of them here, or maybe leave detaching of all to the kms driver, and just report a warning here. Archit > + > drm_modeset_lock_all(dev); > drm_mode_object_unregister(dev, &encoder->base); > kfree(encoder->name); > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH] drm: Fix locking cargo-cult in encoder/plane init/cleanup
On 29/11/16 09:45, Daniel Vetter wrote:
> Encoders&planes can't be hotplugged, we dont need looking for this
s/looking/locking/
With that changed:
Reviewed-by: Frank Binns
> since it's all single-threaded driver setup/teardown code. CRTCs
> already don't grab locks.
>
> While at it I noticed that plane's are missing the
> drm_modeset_lock_fini() call, so add it.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_encoder.c | 9 +
> drivers/gpu/drm/drm_plane.c | 4 ++--
> 2 files changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index 5c067719164d..992879f15f23 100644
> --- a/drivers/gpu/drm/drm_encoder.c
> +++ b/drivers/gpu/drm/drm_encoder.c
> @@ -110,11 +110,9 @@ int drm_encoder_init(struct drm_device *dev,
> {
> int ret;
>
> - drm_modeset_lock_all(dev);
> -
> ret = drm_mode_object_get(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER);
> if (ret)
> - goto out_unlock;
> + return ret;
>
> encoder->dev = dev;
> encoder->encoder_type = encoder_type;
> @@ -142,9 +140,6 @@ int drm_encoder_init(struct drm_device *dev,
> if (ret)
> drm_mode_object_unregister(dev, &encoder->base);
>
> -out_unlock:
> - drm_modeset_unlock_all(dev);
> -
> return ret;
> }
> EXPORT_SYMBOL(drm_encoder_init);
> @@ -164,12 +159,10 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
>* the indices on the drm_encoder after us in the encoder_list.
>*/
>
> - drm_modeset_lock_all(dev);
> drm_mode_object_unregister(dev, &encoder->base);
> kfree(encoder->name);
> list_del(&encoder->head);
> dev->mode_config.num_encoder--;
> - drm_modeset_unlock_all(dev);
>
> memset(encoder, 0, sizeof(*encoder));
> }
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 419ac313c36f..9147aab182c4 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -221,7 +221,8 @@ void drm_plane_cleanup(struct drm_plane *plane)
> {
> struct drm_device *dev = plane->dev;
>
> - drm_modeset_lock_all(dev);
> + drm_modeset_lock_fini(&plane->mutex);
> +
> kfree(plane->format_types);
> drm_mode_object_unregister(dev, &plane->base);
>
> @@ -236,7 +237,6 @@ void drm_plane_cleanup(struct drm_plane *plane)
> dev->mode_config.num_total_plane--;
> if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> dev->mode_config.num_overlay_plane--;
> - drm_modeset_unlock_all(dev);
>
> WARN_ON(plane->state && !plane->funcs->atomic_destroy_state);
> if (plane->state && plane->funcs->atomic_destroy_state)
[PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings
On Tue, Nov 29, 2016 at 11:11:03AM +0200, Laurent Pinchart wrote: > On Tuesday 29 Nov 2016 13:41:33 Archit Taneja wrote: > > I thought we couldn't add mandatory properties once the device is already > > present in DT for one or more platforms. > You can, as long as you treat them as optional in the driver to retain > backward compatibility. The DT bindings should document the properties > expected from a new platform (older versions of the bindings will always be > available in the git history). The device probably never worked without power... note that the kernel will substitute in dummy regulators for anything that isn't explicitly mapped so it won't actually break anything. > > Say, if we do make it mandatory for future additions, we would need to have > > DT property for the supplies for the new platforms. If the regulators on > > these boards are fixed supplies, they would be need to be modeled > > using "regulator-fixed", possibly without any input supply. Is that > > what you're suggesting? > That's the idea, yes. Clock maintainers have a similar opinion regarding the > clock bindings, where a clock that is not optional at the hardware level > should be specified in DT even if it's always present. > Mark, any opinion ? It's best practice to always describe the power. The kernel will cope if people don't but it's not unknown for drivers to discover a reason for wanting information about their power and hard to retrofit that if it's not been in there from the get go. Please note that if you're going to CC me into a graphics thread there's a good chance I will miss it, I get copied on quite a lot of graphics related mail that's not really relevant so I often skip it. Changing the subject line would help with that. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/af4fa690/attachment.sig>
[PULL] drm-misc-next
Hi Stephen, drm-misc has slightly moved around, new branches for you to pull in: git://anongit.freedesktop.org/drm/drm-misc for-linux-next-fixes git://anongit.freedesktop.org/drm/drm-misc for-linux-next It's the same aliasing branch concept as for drm-intel, to avoid trouble for you around the merge window. Cheers, Daniel On Tue, Nov 29, 2016 at 11:13 AM, Daniel Vetter wrote: > Hi Dave, > > Big thing is that drm-misc is now officially a group maintainer/committer > model thing, with MAINTAINERS suitably updated. Otherwise just the usual > pile of misc things all over, nothing that stands out this time around. > > Backmerge would also be great, since I just noticed that > > commit 8ae94224c9d72fc4d9aaac93b2d7833cf46d7141 > Author: Sebastian Andrzej Siewior > Date: Fri Nov 4 19:39:38 2016 +0100 > > kbuild: add -fno-PIE > > landed in Linus' tree a bit ago, and having that in drm trees would help > with a lot of pain I'm having right now ;-) > > Cheers, Daniel > > > The following changes since commit 43167f6c7d7172e0a6cb1ecaa1771a2f457fd165: > > Merge tag 'drm-hisilicon-next-2016-11-17' of > http://github.com/zourongrong/linux into drm-next (2016-11-21 11:42:17 +1000) > > are available in the git repository at: > > git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2016-11-29 > > for you to fetch changes up to 389f78b361fcdc52a9dbb5382c3922d80b52ed9f: > > drm: Introduce drm_framebuffer_assign() (2016-11-29 10:22:08 +0100) > > > Arnd Bergmann (3): > vgaarb: use valid dev pointer in vgaarb_info() > drm/hisilicon/hibmc: mark PM functions __maybe_unused > drm: bridge: dw-hdmi: add ASoC dependency > > Bjorn Helgaas (2): > vgaarb: Use dev_printk() when possible > vgaarb: Downgrade userspace-triggerable messages to debug > > Chen-Yu Tsai (1): > drm/bridge: dumb-vga-dac: Support a VDD regulator supply > > Chris Wilson (8): > drm: Define drm_mm_for_each_node_in_range() > drm: Check against color expansion in drm_mm_reserve_node() > drm: Fixup kernel doc for driver->gem_create_object > drm: Fix conflicting macro parameter in drm_mm_for_each_node_in_range() > drm: Use u64_to_user_ptr() helper for blob ioctls > drm: Avoid NULL dereference for DRM_LEGACY debug message > drm: Fix shift operations for drm_fb_helper::drm_target_preferred() > drm: Introduce drm_framebuffer_assign() > > Dan Carpenter (1): > drm/hisilicon/hibmc: Checking for NULL instead of IS_ERR() > > Daniel Vetter (9): > drm: Nerf DRM_CONTROL nodes > MAINTAINERS: Add drm-misc > MAINTAINERS: Add Archit as drm bridge maintainer > MAINTAINERS: Move dma-buf to drm-misc git > drm: document standard connector properties > drm/atomic: Unconfuse the old_state mess in commmit_tail > MAINTAINERS: Add link to drm-misc documentation > drm/doc: Fix links in drm_property.c > Merge remote-tracking branch 'airlied/drm-next' into drm-misc-next > > Gustavo Padovan (2): > Revert "dma-buf/sync-file: Avoid enable fence signaling if > poll(.timeout=0)" > drm/fences: add DOC: for explicit fencing > > Jani Nikula (1): > drm: also move DSI panels to the front of the connector list > > John Stultz (1): > drm/bridge: adv7511: Add Audio support > > Kuninori Morimoto (1): > drm: bridge: add DesignWare HDMI I2S audio support > > Liviu Dudau (1): > drm/atomic: cleanup debugfs entries on un-registering the driver. > > Srinivas Kandagatla (1): > drm/bridge: adv7511: Enable the audio data and clock pads on adv7533 > > Ville Syrjälä (3): > drm: Nuke modifier[1-3] > drm/atomic: Constify drm_atomic_crtc_needs_modeset() > drm/edid: Consider alternate cea timings to be the same VIC > > .../bindings/display/bridge/dumb-vga-dac.txt | 2 + > Documentation/gpu/drm-kms-helpers.rst | 3 + > Documentation/gpu/drm-kms.rst | 12 ++ > MAINTAINERS| 23 ++- > drivers/dma-buf/sync_file.c| 3 +- > drivers/gpu/drm/bridge/Kconfig | 9 + > drivers/gpu/drm/bridge/Makefile| 1 + > drivers/gpu/drm/bridge/adv7511/Kconfig | 8 + > drivers/gpu/drm/bridge/adv7511/Makefile| 1 + > drivers/gpu/drm/bridge/adv7511/adv7511.h | 16 ++ > drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 213 > + > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 4 + > drivers/gpu/drm/bridge/adv7511/adv7533.c | 1 + > drivers/gpu/drm/bridge/dumb-vga-dac.c | 33 > drivers/gpu/drm/bridge/dw-hdmi-audio.h | 7 + > drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c | 141 ++ > drivers/gpu/drm/bridge/dw-hdmi.c | 22 ++- > drivers/gpu/drm/bridge/dw-hdmi.h
[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 --- Comment #1 from Tom B --- Update: After suspending the machine overnight and booting it this morning, the `battery` setting is still active and upon resume seems to have had an effect on temperature. I'm now seeing 42C on radeon-pci-0100 after 20 minutes on the desktop which is far more sane previously the temperature was always around 60C, although radeon_pm_info reports the same numbers The suspend/resume cycle seems to have forced the `battery` setting fixing both temperatures and the flicker issue. Could the flicker issue be due to overheating/overclocking? I've seen similar graphical artifacts/corruption in games when overclocking GPUs too high. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/171d6d56/attachment-0001.html>
[PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support
This patchset series adds HDMI video support to the Allwinner sun8i SoCs which include the display engine 2 (DE2). The driver contains the code for the A83T and H3 SoCs, and some H3 boards, but it could be used/extended for other SoCs (A64, H2, H5) and boards (Banana PIs, Orange PIs). v7: - more explanations about the DE2 in the DT documentation - separate patches for DT documentation (Rob Herring) - show all properties in DT examples (Rob Herring) - use drm_of_component_probe() - use the index of the DE 'ports' in the DT as the DE mixer number (no alias needed anymore) - change some 'lcd' to 'tcon' in the DT - add HDMI module parameter for DVI mode when screen overscan problems - fall back to some CEA modes in case of EDID read failure - fix some settings (interlace) and simplify code - fix bug in start of A83T HDMI - fix lack of CLK_PLL_DE definition in the DT include (Icenowy Zheng) v6: - remove audio support (other patchset to come) - use DRM modeset data for HDMI configuration (thanks to Jernej Škrabec) - more meaningfull register names - use a mutex for DE I/O protection - merge DE and plane into one file - don't activate the video hardware when video not started (Maxime Ripard) - remove 'type = "video" in DT graph ports (Rob Herring) - change the I/O accesses by #define instead of struct (Maxime Ripard, André Przywara) - remove pm functions (Maxime Ripard) - set the pll-de/de clocks in the DT (Maxime Ripard) - use platform_get_irq instead of irq_of_parse_and_map (Maxime Ripard) - rename sunxi to sun8i (Maxime Ripard) - fix coding style errors (Maxime Ripard) - subclass the drm structure in private data (Daniel Vetter) - move drm_dev_register at end of init (Daniel Vetter) v5: - add overlay plane - add audio support - add support for the A83T - add back the HDMI driver - many bug fixes v4: - drivers/clk/sunxi/Makefile was missing (Emil Velikov) v3: - add the hardware cursor - simplify and fix the DE2 init sequences - generation for all SUNXI SoCs (Andre Przywara) v2: - remove the HDMI driver - remarks from Chen-Yu Tsai and Russell King - DT documentation added Jean-Francois Moine (8): drm: sun8i: Add a basic DRM driver for Allwinner DE2 drm/sun8i: Add DT bindings documentation of Allwinner DE2 drm: sun8i: add HDMI video support to A83T and H3 drm/sunxi: Add DT bindings documentation of Allwinner HDMI clk: sunxi-ng: define the PLL DE clock ARM: dts: sun8i-h3: add HDMI video nodes ARM: dts: sun8i-h3: Add HDMI video to the Banana Pi M2+ ARM: dts: sun8i-h3: Add HDMI video to the Orange PI 2 .../devicetree/bindings/display/sunxi/hdmi.txt | 56 ++ .../bindings/display/sunxi/sun8i-de2.txt | 121 +++ arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 12 + arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 12 + arch/arm/boot/dts/sun8i-h3.dtsi| 65 ++ drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/sun8i/Kconfig | 26 + drivers/gpu/drm/sun8i/Makefile | 9 + drivers/gpu/drm/sun8i/de2_crtc.c | 449 +++ drivers/gpu/drm/sun8i/de2_crtc.h | 52 ++ drivers/gpu/drm/sun8i/de2_drv.c| 317 drivers/gpu/drm/sun8i/de2_drv.h| 48 ++ drivers/gpu/drm/sun8i/de2_hdmi.c | 440 +++ drivers/gpu/drm/sun8i/de2_hdmi.h | 51 ++ drivers/gpu/drm/sun8i/de2_hdmi_io.c| 842 + drivers/gpu/drm/sun8i/de2_plane.c | 734 ++ include/dt-bindings/clock/sun8i-h3-ccu.h | 1 + 18 files changed, 3238 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt create mode 100644 Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt create mode 100644 drivers/gpu/drm/sun8i/Kconfig create mode 100644 drivers/gpu/drm/sun8i/Makefile create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.c create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.h create mode 100644 drivers/gpu/drm/sun8i/de2_drv.c create mode 100644 drivers/gpu/drm/sun8i/de2_drv.h create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.c create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.h create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi_io.c create mode 100644 drivers/gpu/drm/sun8i/de2_plane.c -- 2.10.2
[PATCH v7 7/8] ARM: dts: sun8i-h3: Add HDMI video to the Banana Pi M2+
Signed-off-by: Jean-Francois Moine
---
arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
index c0c49dd..9f3e2f8 100644
--- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
@@ -93,6 +93,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
@@ -101,12 +105,20 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
status = "okay";
};
+&tcon0 {
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
--
2.10.2
[PATCH v7 6/8] ARM: dts: sun8i-h3: add HDMI video nodes
Signed-off-by: Jean-Francois Moine
---
Note 1:
The DE clock is not set in the driver. Instead, it is set at system
startup time by 'assigned-clocks', but there is a problem in sunxi-ng
which uses readl_relaxed_poll_timeout(), and, as noticed by
OndÅej Jirman, this function is not available at startup time.
The fix of this problem is not part of this patchset series.
Note 2:
The DE clock is set to a high enough rate (432MHz). It seems that
this is needed to handle 4K video.
But, as the proposed DE driver does not treat yet 4K video, the clock
could be set to a lower rate. For example, the default rate for the A83T
is 250MHz (no 4K video).
---
arch/arm/boot/dts/sun8i-h3.dtsi | 65 +
1 file changed, 65 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index fca66bf..1aa087d 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -140,6 +140,16 @@
#size-cells = <1>;
ranges;
+ de: de-controller at 0100 {
+ compatible = "allwinner,sun8i-h3-display-engine";
+ reg = <0x0100 0x40>;
+ clocks = <&ccu CLK_BUS_DE>, <&ccu CLK_DE>;
+ clock-names = "bus", "clock";
+ resets = <&ccu RST_BUS_DE>;
+ ports = <&tcon0_p>, <&tcon1_p>;
+ status = "disabled";
+ };
+
dma: dma-controller at 01c02000 {
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
@@ -149,6 +159,37 @@
#dma-cells = <1>;
};
+ tcon0: lcd-controller at 01c0c000 {
+ compatible = "allwinner,sun8i-a83t-tcon";
+ reg = <0x01c0c000 0x400>;
+ clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_TCON0>;
+ clock-names = "bus", "clock";
+ resets = <&ccu RST_BUS_TCON0>;
+ interrupts = ;
+ status = "disabled";
+ tcon0_p: port {
+ tcon0_hdmi: endpoint {
+ remote-endpoint = <&hdmi_tcon0>;
+ };
+ };
+ };
+
+ /* not used */
+ tcon1: lcd-controller at 01c0d000 {
+ compatible = "allwinner,sun8i-h3-tcon";
+ reg = <0x01c0d000 0x400>;
+ clocks = <&ccu CLK_BUS_TCON1>,
+<&ccu CLK_TCON0>; /* no clock */
+ clock-names = "bus", "clock";
+ interrupts = ;
+ status = "disabled";
+ tcon1_p: port {
+ endpoint {
+ /* empty */
+ };
+ };
+ };
+
mmc0: mmc at 01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
@@ -314,6 +355,11 @@
clock-names = "hosc", "losc";
#clock-cells = <1>;
#reset-cells = <1>;
+
+ assigned-clocks = <&ccu CLK_PLL_DE>,
+ <&ccu CLK_DE>;
+ assigned-clock-rates = <86400>,
+ <43200>;
};
pio: pinctrl at 01c20800 {
@@ -567,6 +613,25 @@
interrupts = ;
};
+ hdmi: hdmi at 01ee {
+ compatible = "allwinner,sun8i-h3-hdmi";
+ reg = <0x01ee 0x2>;
+ clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI>,
+<&ccu CLK_HDMI_DDC>;
+ clock-names = "bus", "clock", "ddc-clock";
+ resets = <&ccu RST_BUS_HDMI0>, <&ccu RST_BUS_HDMI1>;
+ reset-names = "hdmi0", "hdmi1";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 0 { /* video */
+ reg = <0>;
+ hdmi_tcon0: endpoint {
+ remote-endpoint = <&tcon0_hdmi>;
+ };
+ };
+ };
+
rtc: rtc at 01f0 {
compatible = "allwinner,sun6i-a31-rtc";
reg = <0x01f0 0x54>;
--
2.10.2
[PATCH v7 3/8] drm: sun8i: add HDMI video support to A83T and H3
Signed-off-by: Jean-Francois Moine
---
drivers/gpu/drm/sun8i/Kconfig | 7 +
drivers/gpu/drm/sun8i/Makefile | 2 +
drivers/gpu/drm/sun8i/de2_hdmi.c| 440 +++
drivers/gpu/drm/sun8i/de2_hdmi.h| 51 +++
drivers/gpu/drm/sun8i/de2_hdmi_io.c | 843
5 files changed, 1343 insertions(+)
create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.c
create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.h
create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi_io.c
diff --git a/drivers/gpu/drm/sun8i/Kconfig b/drivers/gpu/drm/sun8i/Kconfig
index 6940895..5c4607b 100644
--- a/drivers/gpu/drm/sun8i/Kconfig
+++ b/drivers/gpu/drm/sun8i/Kconfig
@@ -17,3 +17,10 @@ config DRM_SUN8I_DE2
Choose this option if your Allwinner chipset has the DE2 interface
as the A64, A83T and H3. If M is selected the module will be called
sun8i-de2-drm.
+
+config DRM_SUN8I_DE2_HDMI
+ tristate "Support for DE2 HDMI"
+ depends on DRM_SUN8I_DE2
+ help
+ Choose this option if you use want HDMI on DE2.
+ If M is selected the module will be called sun8i-de2-hdmi.
diff --git a/drivers/gpu/drm/sun8i/Makefile b/drivers/gpu/drm/sun8i/Makefile
index f107919..6ba97c2 100644
--- a/drivers/gpu/drm/sun8i/Makefile
+++ b/drivers/gpu/drm/sun8i/Makefile
@@ -3,5 +3,7 @@
#
sun8i-de2-drm-objs := de2_drv.o de2_crtc.o de2_plane.o
+sun8i-de2-hdmi-objs := de2_hdmi.o de2_hdmi_io.o
obj-$(CONFIG_DRM_SUN8I_DE2) += sun8i-de2-drm.o
+obj-$(CONFIG_DRM_SUN8I_DE2_HDMI) += sun8i-de2-hdmi.o
diff --git a/drivers/gpu/drm/sun8i/de2_hdmi.c b/drivers/gpu/drm/sun8i/de2_hdmi.c
new file mode 100644
index 000..9ff6132
--- /dev/null
+++ b/drivers/gpu/drm/sun8i/de2_hdmi.c
@@ -0,0 +1,440 @@
+/*
+ * Allwinner DRM driver - HDMI
+ *
+ * Copyright (C) 2016 Jean-Francois Moine
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "de2_hdmi.h"
+
+static const struct of_device_id de2_hdmi_dt_ids[] = {
+ { .compatible = "allwinner,sun8i-a83t-hdmi",
+ .data = (void *) SOC_A83T },
+ { .compatible = "allwinner,sun8i-h3-hdmi",
+ .data = (void *) SOC_H3 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, de2_hdmi_dt_ids);
+
+#define conn_to_priv(x) \
+ container_of(x, struct de2_hdmi_priv, connector)
+
+#define enc_to_priv(x) \
+ container_of(x, struct de2_hdmi_priv, encoder)
+
+/* --- encoder functions --- */
+
+static int de2_hdmi_set_clock(struct de2_hdmi_priv *priv,
+ int rate)
+{
+ struct clk *parent_clk;
+ u32 parent_rate;
+ int ret;
+
+ /* determine and set the best rate for the parent clock (pll-video) */
+ if ((27 * 2) % rate == 0)
+ parent_rate = 27000;
+ else if (297000 % rate == 0)
+ parent_rate = 29700;
+ else
+ return -EINVAL; /* unsupported clock */
+
+ parent_clk = clk_get_parent(priv->clk);
+
+ ret = clk_set_rate(parent_clk, parent_rate);
+ if (ret) {
+ dev_err(priv->dev, "set parent rate failed %d\n", ret);
+ return ret;
+ }
+ ret = clk_set_rate(priv->clk, rate * 1000);
+ if (ret)
+ dev_err(priv->dev, "set rate failed %d\n", ret);
+
+ return ret;
+}
+
+static void de2_hdmi_encoder_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct de2_hdmi_priv *priv = enc_to_priv(encoder);
+
+ priv->cea_mode = drm_match_cea_mode(mode);
+
+ DRM_DEBUG_DRIVER("cea_mode %d\n", priv->cea_mode);
+
+ if (de2_hdmi_set_clock(priv, mode->clock) < 0)
+ return;
+
+ mutex_lock(&priv->mutex);
+ hdmi_io_mode_set(priv, mode);
+ mutex_unlock(&priv->mutex);
+}
+
+static void de2_hdmi_encoder_enable(struct drm_encoder *encoder)
+{
+ struct de2_hdmi_priv *priv = enc_to_priv(encoder);
+
+ mutex_lock(&priv->mutex);
+ hdmi_io_video_on(priv);
+ mutex_unlock(&priv->mutex);
+}
+
+static void de2_hdmi_encoder_disable(struct drm_encoder *encoder)
+{
+ struct de2_hdmi_priv *priv = enc_to_priv(encoder);
+
+ mutex_lock(&priv->mutex);
+ hdmi_io_video_off(priv);
+ mutex_unlock(&priv->mutex);
+}
+
+static const struct drm_encoder_helper_funcs de2_hdmi_encoder_helper_funcs = {
+ .mode_set = de2_hdmi_encoder_mode_set,
+ .enable = de2_hdmi_encoder_enable,
+ .disable = de2_hdmi_encoder_disable,
+};
+
+sta
[PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
Signed-off-by: Jean-Francois Moine
---
.../devicetree/bindings/display/sunxi/hdmi.txt | 56 ++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
diff --git a/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
new file mode 100644
index 000..1e107cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
@@ -0,0 +1,56 @@
+Allwinner HDMI Transmitter
+==
+
+The Allwinner HDMI transmitters are included in the SoCs.
+They support audio and video.
+
+Required properties:
+ - compatible : should be one of
+ "allwinner,sun8i-a83t-hdmi"
+ "allwinner,sun8i-h3-hdmi"
+ - reg: base address and size of the I/O memory
+ - clocks : phandles to the HDMI clocks as described in
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
+ - clock-names : must be
+ "bus" : bus gate
+ "clock" : streaming clock
+ "ddc-clock" : DDC clock
+ - resets : One or two phandles to the HDMI resets
+ - reset-names : when 2 phandles, must be
+ "hdmi0" and "hdmi1"
+ - #address-cells : should be <1>
+ - #size-cells : should be <0>
+
+Required nodes:
+ - port: Audio and video input port nodes with endpoint definitions
+ as defined in Documentation/devicetree/bindings/graph.txt.
+ port at 0 is video and port at 1 is audio.
+
+Example:
+
+ hdmi: hdmi at 01ee {
+ compatible = "allwinner,sun8i-a83t-hdmi";
+ reg = <0x01ee 0x2>;
+ clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI>,
+<&ccu CLK_HDMI_DDC>;
+ clock-names = "bus", "clock", "ddc-clock";
+ resets = <&ccu RST_HDMI0>, <&ccu RST_HDMI1>;
+ reset-names = "hdmi0", "hdmi1";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_pins_a>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 0 { /* video */
+ reg = <0>;
+ hdmi_tcon1: endpoint {
+ remote-endpoint = <&tcon1_hdmi>;
+ };
+ };
+ port at 1 { /* audio */
+ reg = <1>;
+ hdmi_i2s2: endpoint {
+ remote-endpoint = <&i2s2_hdmi>;
+ };
+ };
+ };
--
2.10.2
[PATCH v7 5/8] clk: sunxi-ng: define the PLL DE clock
Signed-off-by: Jean-Francois Moine --- include/dt-bindings/clock/sun8i-h3-ccu.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/clock/sun8i-h3-ccu.h b/include/dt-bindings/clock/sun8i-h3-ccu.h index efb7ba2..7af57b7 100644 --- a/include/dt-bindings/clock/sun8i-h3-ccu.h +++ b/include/dt-bindings/clock/sun8i-h3-ccu.h @@ -44,6 +44,7 @@ #define _DT_BINDINGS_CLK_SUN8I_H3_H_ #define CLK_CPUX 14 +#define CLK_PLL_DE 13 #define CLK_BUS_CE 20 #define CLK_BUS_DMA21 -- 2.10.2
[PATCH v7 8/8] ARM: dts: sun8i-h3: Add HDMI video to the Orange PI 2
Signed-off-by: Jean-Francois Moine
---
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index 047e9e1..7712972 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -105,16 +105,28 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
status = "okay";
};
+&tcon0 {
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
--
2.10.2
[Bug 98901] amdgpu doesn't reinitialize after reboot in Xen PV DomU
https://bugs.freedesktop.org/show_bug.cgi?id=98901 Bug ID: 98901 Summary: amdgpu doesn't reinitialize after reboot in Xen PV DomU Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: msgctl at centzontotochtin.org Created attachment 128264 --> https://bugs.freedesktop.org/attachment.cgi?id=128264&action=edit Logs from Xen Dom0 and affected DomU I'm not sure whether this is a Xen or amdgpu bug. amdgpu consistently does not reinitialize after paravirtualized Xen DomU reboots. It's a PCI passthrough setup - the physical machine does not reboot and it can't reset PCI Express devices. This setup is working fine until I need to reboot the affected DomU. DomU: Debian testing (29-11-2016) Linux version 4.7.0-1-amd64 Dom0: Debian GNU/Linux 8.6 (jessie) Linux 3.16.0-4-amd64 Graphics adapter: Radeon RX480 I attached an archive with all the relevant logs I could gather. Please contact me for further information/testing. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/641f646a/attachment.html>
[PATCH v3 0/2] ARM: dts: da850: tilcdc related DT changes
his series contains the last DT changes required for LCDC support on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second limits the maximum pixel clock rate. v1 -> v2: - drop patch 3/3 (already merged) - use max-pixelclock instead of max-bandwidth for display mode limiting v2 -> v3: - make the commit message in patch [2/2] more detailed - move the max-pixelclock property to da850.dtsi as the limit affects all da850-based boards Bartosz Golaszewski (2): ARM: dts: da850-lcdk: add the dumb-vga-dac node ARM: dts: da850: specify the maximum pixel clock rate for tilcdc arch/arm/boot/dts/da850-lcdk.dts | 58 arch/arm/boot/dts/da850.dtsi | 18 + 2 files changed, 76 insertions(+) -- 2.9.3
[PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node
Add the dumb-vga-dac node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850-lcdk.dts | 58
arch/arm/boot/dts/da850.dtsi | 17
2 files changed, 75 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 711b9ad..d864f11 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -50,6 +50,53 @@
system-clock-frequency = <24576000>;
};
};
+
+ vga_bridge {
+ compatible = "dumb-vga-dac";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ vga_bridge_in: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&display_out_vga>;
+ };
+ };
+
+ port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ vga_bridge_out: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ ddc-i2c-bus = <&i2c0>;
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
};
&pmx_core {
@@ -235,3 +282,14 @@
&memctrl {
status = "okay";
};
+
+&display {
+ status = "okay";
+};
+
+&display_out {
+ display_out_vga: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vga_bridge_in>;
+ };
+};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 4070619..5f4ba2e 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -454,6 +454,23 @@
reg = <0x213000 0x1000>;
interrupts = <52>;
status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ display_in: port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ display_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
};
};
aemif: aemif at 6800 {
--
2.9.3
[PATCH v3 2/2] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
is 37.5 MHz[1]. We must filter out any mode for which the calculated
pixel clock rate would exceed this value.
Specify the max-pixelclock property for the display node for
da850-lcdk.
[1]
http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_LCD_Controller_(LCDC)_Throughput_and_Optimization_Techniques
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 5f4ba2e..00692d3 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -453,6 +453,7 @@
compatible = "ti,da850-tilcdc";
reg = <0x213000 0x1000>;
interrupts = <52>;
+ max-pixelclock = <37500>;
status = "disabled";
ports {
--
2.9.3
[PATCH v2 2/2] ARM: dts: da850-lcdk: specify the maximum pixel clock rate for tilcdc
2016-11-29 11:53 GMT+01:00 Sekhar Nori :
> On Monday 28 November 2016 05:45 PM, Bartosz Golaszewski wrote:
>> Due to memory throughput constraints any display mode for which the
>> pixel clock rate exceeds the recommended value of 37500 KHz must be
>> filtered out.
>
> I think there might be more reasons than memory throughput constraints
> for the reasoning behind 37.5Mhz cap on pixel clock. Why not just refer
> to the datasheet section that places this constraint so we know its a
> hardware restriction.
>
>>
>> Specify the max-pixelclock property for the display node for
>> da850-lcdk.
>>
>> Signed-off-by: Bartosz Golaszewski
>> ---
>> arch/arm/boot/dts/da850-lcdk.dts | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
>> b/arch/arm/boot/dts/da850-lcdk.dts
>> index d864f11..1283263 100644
>> --- a/arch/arm/boot/dts/da850-lcdk.dts
>> +++ b/arch/arm/boot/dts/da850-lcdk.dts
>> @@ -285,6 +285,7 @@
>>
>> &display {
>> status = "okay";
>> + max-pixelclock = <37500>;
>
> Should this not be in da850.dtsi since its an SoC imposed constraint? If
> a board needs narrower constraint, it can override it. But I guess most
> well designed boards will just hit the SoC constraint.
>
Both issues fixed in v3.
Thanks,
Bartosz Golaszewski
[PATCH v2 1/3] drm: Hold mode_config.lock to prevent hotplug whilst setting up crtcs
The fb_helper->connector_count is modified when a new connector is
constructed following a hotplug event (e.g. DP-MST). This causes trouble
for drm_setup_crtcs() and friends that assume that fb_helper is
constant:
[ 1250.872997] BUG: KASAN: slab-out-of-bounds in drm_setup_crtcs+0x320/0xf80 at
addr 88074cdd2608
[ 1250.873020] Write of size 40 by task kworker/u8:3/480
[ 1250.873039] CPU: 2 PID: 480 Comm: kworker/u8:3 Tainted: G U
4.9.0-rc6+ #285
[ 1250.873043] Hardware name: /NUC6i3SYB, BIOS
SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
[ 1250.873050] Workqueue: events_unbound async_run_entry_fn
[ 1250.873056] 88070f9d78f0 814b72aa 88074e40c5c0
88074cdd2608
[ 1250.873067] 88070f9d7918 8124ff3c 88070f9d79b0
88074cdd2600
[ 1250.873079] 88074e40c5c0 88070f9d79a0 812501e4
0005
[ 1250.873090] Call Trace:
[ 1250.873099] [] dump_stack+0x67/0x9d
[ 1250.873106] [] kasan_object_err+0x1c/0x70
[ 1250.873113] [] kasan_report_error+0x204/0x4f0
[ 1250.873120] [] ? drm_dev_printk+0x140/0x140
[ 1250.873127] [] kasan_report+0x53/0x60
[ 1250.873134] [] ? drm_setup_crtcs+0x320/0xf80
[ 1250.873142] [] check_memory_region+0x13e/0x1a0
[ 1250.873147] [] memset+0x23/0x40
[ 1250.873154] [] drm_setup_crtcs+0x320/0xf80
[ 1250.873161] [] ? wake_up_q+0x45/0x80
[ 1250.873169] [] ? mutex_lock_nested+0x5a0/0x5a0
[ 1250.873176] [] drm_fb_helper_initial_config+0x206/0x7a0
[ 1250.873183] [] ? drm_fb_helper_set_par+0x90/0x90
[ 1250.873303] [] ? intel_fbdev_fini+0x140/0x140 [i915]
[ 1250.873387] [] intel_fbdev_initial_config+0x22/0x40 [i915]
[ 1250.873391] [] async_run_entry_fn+0x7f/0x270
[ 1250.873394] [] process_one_work+0x3d0/0x960
[ 1250.873398] [] ? process_one_work+0x33d/0x960
[ 1250.873401] [] ? max_active_store+0xf0/0xf0
[ 1250.873406] [] ? do_raw_spin_lock+0x10d/0x1a0
[ 1250.873413] [] worker_thread+0x8d/0x840
[ 1250.873419] [] ? create_worker+0x2e0/0x2e0
[ 1250.873426] [] kthread+0x194/0x1c0
[ 1250.873432] [] ? kthread_park+0x60/0x60
[ 1250.873438] [] ? trace_hardirqs_on+0xd/0x10
[ 1250.873446] [] ? kthread_park+0x60/0x60
[ 1250.873453] [] ? kthread_park+0x60/0x60
[ 1250.873457] [] ret_from_fork+0x27/0x40
[ 1250.873460] Object at 88074cdd2608, in cache kmalloc-32 size: 32
However, when holding the mode_config.lock around the fb_helper, we have
to be careful of any callbacks that may reenter the fb_helper and so try
to reacquire the mode_config.lock (e.g. register_framebuffer). To avoid
the mutex recursion, we have to rearrange the sequence to move the
registration into the caller outside of the mode_config.lock.
v2: drop the 1; following the lockdep assertion inside the for(;;), I
anticipated an error that doesn't happen!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98826
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 73 ++---
1 file changed, 40 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1f26634f53d8..380a0ec01033 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -97,6 +97,10 @@ static LIST_HEAD(kernel_fb_helper_list);
* mmap page writes.
*/
+#define drm_fb_helper_for_each_connector(fbh, i__) \
+ for (({ lockdep_assert_held(&(fbh)->dev->mode_config.mutex); }), \
+i__ = 0; i__ < (fbh)->connector_count; i__++)
+
/**
* drm_fb_helper_single_add_all_connectors() - add all connectors to fbdev
*emulation helper
@@ -130,7 +134,7 @@ int drm_fb_helper_single_add_all_connectors(struct
drm_fb_helper *fb_helper)
mutex_unlock(&dev->mode_config.mutex);
return 0;
fail:
- for (i = 0; i < fb_helper->connector_count; i++) {
+ drm_fb_helper_for_each_connector(fb_helper, i) {
struct drm_fb_helper_connector *fb_helper_connector =
fb_helper->connector_info[i];
@@ -565,7 +569,7 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
dpms_mode)
continue;
/* Walk the connectors & encoders on this fb turning them
on/off */
- for (j = 0; j < fb_helper->connector_count; j++) {
+ drm_fb_helper_for_each_connector(fb_helper, j) {
connector = fb_helper->connector_info[j]->connector;
connector->funcs->dpms(connector, dpms_mode);
drm_object_property_set_value(&connector->base,
@@ -1469,7 +1473,6 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
int ret = 0;
int crtc_count = 0;
int i;
- struct fb_info *info;
struct drm_fb_helper_surface_size sizes;
int gamma_size = 0;
@@ -1485,7 +1488,7 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
[PATCH v2 3/3] drm: Protect fb_helper list manipulation with a mutex
Though we only walk the kernel_fb_helper_list inside a panic (or single
thread debugging), we still need to protect the list manipulation on
creating/removing a framebuffer device in order to prevent list
corruption.
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 90da28d2fcf3..e934b541feea 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -49,6 +49,7 @@ MODULE_PARM_DESC(fbdev_emulation,
"Enable legacy fbdev emulation [default=true]");
static LIST_HEAD(kernel_fb_helper_list);
+static DEFINE_MUTEX(kernel_fb_helper_lock);
/**
* DOC: fbdev helpers
@@ -855,12 +856,14 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation)
return;
+ mutex_lock(&kernel_fb_helper_lock);
if (!list_empty(&fb_helper->kernel_fb_list)) {
list_del(&fb_helper->kernel_fb_list);
if (list_empty(&kernel_fb_helper_list)) {
unregister_sysrq_key('v',
&sysrq_drm_fb_helper_restore_op);
}
}
+ mutex_unlock(&kernel_fb_helper_lock);
drm_fb_helper_crtc_free(fb_helper);
@@ -2258,10 +2261,12 @@ int drm_fb_helper_initial_config(struct drm_fb_helper
*fb_helper, int bpp_sel)
dev_info(dev->dev, "fb%d: %s frame buffer device\n",
info->node, info->fix.id);
+ mutex_lock(&kernel_fb_helper_lock);
if (list_empty(&kernel_fb_helper_list))
register_sysrq_key('v', &sysrq_drm_fb_helper_restore_op);
list_add(&fb_helper->kernel_fb_list, &kernel_fb_helper_list);
+ mutex_unlock(&kernel_fb_helper_lock);
return 0;
}
--
2.10.2
[PATCH v2 2/3] drm: Pull together probe + setup for drm_fb_helper
drm_fb_helper_probe_connector_modes() is always called before
drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a
small bit of code compaction.
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 37 +++--
1 file changed, 11 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 380a0ec01033..90da28d2fcf3 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2099,20 +2099,19 @@ static int drm_pick_crtcs(struct drm_fb_helper
*fb_helper,
return best_score;
}
-static void drm_setup_crtcs(struct drm_fb_helper *fb_helper)
+static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
+ u32 width, u32 height)
{
struct drm_device *dev = fb_helper->dev;
struct drm_fb_helper_crtc **crtcs;
struct drm_display_mode **modes;
struct drm_fb_offset *offsets;
bool *enabled;
- int width, height;
int i;
DRM_DEBUG_KMS("\n");
-
- width = dev->mode_config.max_width;
- height = dev->mode_config.max_height;
+ if (drm_fb_helper_probe_connector_modes(fb_helper, width, height) == 0)
+ DRM_DEBUG_KMS("No connectors reported connected with modes\n");
/* prevent concurrent modification of connector_count by hotplug */
lockdep_assert_held(&fb_helper->dev->mode_config.mutex);
@@ -2236,23 +2235,15 @@ int drm_fb_helper_initial_config(struct drm_fb_helper
*fb_helper, int bpp_sel)
{
struct drm_device *dev = fb_helper->dev;
struct fb_info *info;
- int count = 0;
int ret;
if (!drm_fbdev_emulation)
return 0;
mutex_lock(&dev->mode_config.mutex);
- count = drm_fb_helper_probe_connector_modes(fb_helper,
- dev->mode_config.max_width,
-
dev->mode_config.max_height);
- /*
-* we shouldn't end up with no modes here.
-*/
- if (count == 0)
- dev_info(fb_helper->dev->dev, "No connectors reported connected
with modes\n");
-
- drm_setup_crtcs(fb_helper);
+ drm_setup_crtcs(fb_helper,
+ dev->mode_config.max_width,
+ dev->mode_config.max_height);
ret = drm_fb_helper_single_fb_probe(fb_helper, bpp_sel);
mutex_unlock(&dev->mode_config.mutex);
if (ret)
@@ -2300,28 +2291,22 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper)
{
struct drm_device *dev = fb_helper->dev;
- u32 max_width, max_height;
if (!drm_fbdev_emulation)
return 0;
- mutex_lock(&fb_helper->dev->mode_config.mutex);
+ mutex_lock(&dev->mode_config.mutex);
if (!fb_helper->fb || !drm_fb_helper_is_bound(fb_helper)) {
fb_helper->delayed_hotplug = true;
- mutex_unlock(&fb_helper->dev->mode_config.mutex);
+ mutex_unlock(&dev->mode_config.mutex);
return 0;
}
DRM_DEBUG_KMS("\n");
- max_width = fb_helper->fb->width;
- max_height = fb_helper->fb->height;
+ drm_setup_crtcs(fb_helper, fb_helper->fb->width, fb_helper->fb->height);
- drm_fb_helper_probe_connector_modes(fb_helper, max_width, max_height);
- mutex_unlock(&fb_helper->dev->mode_config.mutex);
+ mutex_unlock(&dev->mode_config.mutex);
- drm_modeset_lock_all(dev);
- drm_setup_crtcs(fb_helper);
- drm_modeset_unlock_all(dev);
drm_fb_helper_set_par(fb_helper->fbdev);
return 0;
--
2.10.2
[Bug 95306] Random Blank(black) screens on "Carrizo"
https://bugs.freedesktop.org/show_bug.cgi?id=95306 --- Comment #35 from Tom --- Kernel 4.9rc7 seems very stable after it boots up. But overheats a lot and booting up often takes several attempts. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/8f438cc2/attachment.html>
[PATCH 2/2] drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting
Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio.
Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV")
Cc: Jani Nikula
Cc: Ville Syrjälä
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 579d2f5..47cd1b2 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -300,7 +300,8 @@ static void chv_exec_gpio(struct drm_i915_private *dev_priv,
mutex_lock(&dev_priv->sb_lock);
vlv_iosf_sb_write(dev_priv, port, cfg1, 0);
vlv_iosf_sb_write(dev_priv, port, cfg0,
- CHV_GPIO_GPIOCFG_GPO | CHV_GPIO_GPIOTXSTATE(value));
+ CHV_GPIO_GPIOEN | CHV_GPIO_GPIOCFG_GPO |
+ CHV_GPIO_GPIOTXSTATE(value));
mutex_unlock(&dev_priv->sb_lock);
}
--
2.9.3
[PATCH 1/2] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET
Looking at the ADF code from the Android kernel sources for a
cherrytrail tablet I noticed that it is calling the
MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
in panel prepare/unprepare hooks") the mainline i915 code was doing the
same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
MIPI_SEQ_DEASSERT_RESET.
Looking at the naming of the sequences that is the right thing to do,
but the problem is, that the old mainline code and the ADF code was
actually calling the right sequence (tested on a cube iwork8 air tablet),
and the swapping of the calling breaks things.
This breakage was likely not noticed in testing because on cherrytrail,
currently chv_exec_gpio ends up disabling the gpio pins rather then
setting them (this is fixed in the next patch in this patch-set).
This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
places in the enum defining them, so that their (new) names match their
actual use.
Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...")
Cc: Jani Nikula
Cc: Ville Syrjälä
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_bios.h | 4 ++--
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 8405b5a..642a5eb 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -49,11 +49,11 @@ struct edp_power_seq {
/* MIPI Sequence Block definitions */
enum mipi_seq {
MIPI_SEQ_END = 0,
- MIPI_SEQ_ASSERT_RESET,
+ MIPI_SEQ_DEASSERT_RESET,
MIPI_SEQ_INIT_OTP,
MIPI_SEQ_DISPLAY_ON,
MIPI_SEQ_DISPLAY_OFF,
- MIPI_SEQ_DEASSERT_RESET,
+ MIPI_SEQ_ASSERT_RESET,
MIPI_SEQ_BACKLIGHT_ON, /* sequence block v2+ */
MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
MIPI_SEQ_TEAR_ON, /* sequence block v2+ */
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 0d8ff00..579d2f5 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -376,11 +376,11 @@ static const fn_mipi_elem_exec exec_elem[] = {
*/
static const char * const seq_name[] = {
- [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
+ [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
[MIPI_SEQ_INIT_OTP] = "MIPI_SEQ_INIT_OTP",
[MIPI_SEQ_DISPLAY_ON] = "MIPI_SEQ_DISPLAY_ON",
[MIPI_SEQ_DISPLAY_OFF] = "MIPI_SEQ_DISPLAY_OFF",
- [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
+ [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
[MIPI_SEQ_BACKLIGHT_ON] = "MIPI_SEQ_BACKLIGHT_ON",
[MIPI_SEQ_BACKLIGHT_OFF] = "MIPI_SEQ_BACKLIGHT_OFF",
[MIPI_SEQ_TEAR_ON] = "MIPI_SEQ_TEAR_ON",
--
2.9.3
[PATCH 1/2] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET
On Tue, Nov 29, 2016 at 01:38:57PM +0100, Hans de Goede wrote:
> Looking at the ADF code from the Android kernel sources for a
> cherrytrail tablet I noticed that it is calling the
> MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
>
> Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
> in panel prepare/unprepare hooks") the mainline i915 code was doing the
> same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
> MIPI_SEQ_DEASSERT_RESET.
>
> Looking at the naming of the sequences that is the right thing to do,
> but the problem is, that the old mainline code and the ADF code was
> actually calling the right sequence (tested on a cube iwork8 air tablet),
> and the swapping of the calling breaks things.
>
> This breakage was likely not noticed in testing because on cherrytrail,
> currently chv_exec_gpio ends up disabling the gpio pins rather then
> setting them (this is fixed in the next patch in this patch-set).
>
> This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
> places in the enum defining them, so that their (new) names match their
> actual use.
>
> Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...")
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/intel_bios.h | 4 ++--
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index 8405b5a..642a5eb 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -49,11 +49,11 @@ struct edp_power_seq {
> /* MIPI Sequence Block definitions */
> enum mipi_seq {
> MIPI_SEQ_END = 0,
> - MIPI_SEQ_ASSERT_RESET,
> + MIPI_SEQ_DEASSERT_RESET,
> MIPI_SEQ_INIT_OTP,
> MIPI_SEQ_DISPLAY_ON,
> MIPI_SEQ_DISPLAY_OFF,
> - MIPI_SEQ_DEASSERT_RESET,
> + MIPI_SEQ_ASSERT_RESET,
That naming would be against the spec, so I don't think we want to do it
like this. Unless the spec is totally wrong, that is.
Can you provide the VBT for the affected machine so other people can
have a look at it?
> MIPI_SEQ_BACKLIGHT_ON, /* sequence block v2+ */
> MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
> MIPI_SEQ_TEAR_ON, /* sequence block v2+ */
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 0d8ff00..579d2f5 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -376,11 +376,11 @@ static const fn_mipi_elem_exec exec_elem[] = {
> */
>
> static const char * const seq_name[] = {
> - [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
> + [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
> [MIPI_SEQ_INIT_OTP] = "MIPI_SEQ_INIT_OTP",
> [MIPI_SEQ_DISPLAY_ON] = "MIPI_SEQ_DISPLAY_ON",
> [MIPI_SEQ_DISPLAY_OFF] = "MIPI_SEQ_DISPLAY_OFF",
> - [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
> + [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
> [MIPI_SEQ_BACKLIGHT_ON] = "MIPI_SEQ_BACKLIGHT_ON",
> [MIPI_SEQ_BACKLIGHT_OFF] = "MIPI_SEQ_BACKLIGHT_OFF",
> [MIPI_SEQ_TEAR_ON] = "MIPI_SEQ_TEAR_ON",
> --
> 2.9.3
--
Ville Syrjälä
Intel OTC
[PATCH 2/2] drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting
On Tue, Nov 29, 2016 at 01:38:58PM +0100, Hans de Goede wrote:
> Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio.
>
> Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV")
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 579d2f5..47cd1b2 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -300,7 +300,8 @@ static void chv_exec_gpio(struct drm_i915_private
> *dev_priv,
> mutex_lock(&dev_priv->sb_lock);
> vlv_iosf_sb_write(dev_priv, port, cfg1, 0);
> vlv_iosf_sb_write(dev_priv, port, cfg0,
> - CHV_GPIO_GPIOCFG_GPO | CHV_GPIO_GPIOTXSTATE(value));
> + CHV_GPIO_GPIOEN | CHV_GPIO_GPIOCFG_GPO |
> + CHV_GPIO_GPIOTXSTATE(value));
Indeed.
Reviewed-by: Ville Syrjälä
Cc: stable at vger.kernel.org
> mutex_unlock(&dev_priv->sb_lock);
> }
>
> --
> 2.9.3
--
Ville Syrjälä
Intel OTC
[PATCH 1/2] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET
Hi,
Thanks for the quick reply.
On 29-11-16 13:48, Ville Syrjälä wrote:
> On Tue, Nov 29, 2016 at 01:38:57PM +0100, Hans de Goede wrote:
>> Looking at the ADF code from the Android kernel sources for a
>> cherrytrail tablet I noticed that it is calling the
>> MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
>>
>> Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
>> in panel prepare/unprepare hooks") the mainline i915 code was doing the
>> same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
>> MIPI_SEQ_DEASSERT_RESET.
>>
>> Looking at the naming of the sequences that is the right thing to do,
>> but the problem is, that the old mainline code and the ADF code was
>> actually calling the right sequence (tested on a cube iwork8 air tablet),
>> and the swapping of the calling breaks things.
>>
>> This breakage was likely not noticed in testing because on cherrytrail,
>> currently chv_exec_gpio ends up disabling the gpio pins rather then
>> setting them (this is fixed in the next patch in this patch-set).
>>
>> This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
>> places in the enum defining them, so that their (new) names match their
>> actual use.
>>
>> Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...")
>> Cc: Jani Nikula
>> Cc: Ville Syrjälä
>> Signed-off-by: Hans de Goede
>> ---
>> drivers/gpu/drm/i915/intel_bios.h | 4 ++--
>> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_bios.h
>> b/drivers/gpu/drm/i915/intel_bios.h
>> index 8405b5a..642a5eb 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.h
>> +++ b/drivers/gpu/drm/i915/intel_bios.h
>> @@ -49,11 +49,11 @@ struct edp_power_seq {
>> /* MIPI Sequence Block definitions */
>> enum mipi_seq {
>> MIPI_SEQ_END = 0,
>> -MIPI_SEQ_ASSERT_RESET,
>> +MIPI_SEQ_DEASSERT_RESET,
>> MIPI_SEQ_INIT_OTP,
>> MIPI_SEQ_DISPLAY_ON,
>> MIPI_SEQ_DISPLAY_OFF,
>> -MIPI_SEQ_DEASSERT_RESET,
>> +MIPI_SEQ_ASSERT_RESET,
>
> That naming would be against the spec, so I don't think we want to do it
> like this. Unless the spec is totally wrong, that is.
Given that both the ADF code and the i915 driver until now have been using
assert on prepare and deassert on unprepare I'm inclined to believe that
the spec is wrong. Is the spec available somewhere public ?
Also if you look at the v1 sequences with the new names:
MIPI_SEQ_DEASSERT_RESET,
MIPI_SEQ_INIT_OTP,
MIPI_SEQ_DISPLAY_ON,
MIPI_SEQ_DISPLAY_OFF,
MIPI_SEQ_ASSERT_RESET,
Then they are exactly in the order as one would call them on
enable, followed by disable, which I believe is not a coincidence.
> Can you provide the VBT for the affected machine so other people can
> have a look at it?
Sure I can do that, what would be the easiest way (both for me to
produce and for you to consume) to do this ?
While developing this set, I've added printk calls to the code executing the
sequences, there are 2 gpios involved nr 60 (backlight enable AFAICT, also used
by the BACKLIGHT sequences) and 72 (reset / panel_enable ?).
When efifb is up both are 1 / high.
With the OLD naming, MIPI_SEQ_ASSERT_RESET does:
gpio 72 high
delay
gpio 72 low
delay
gpio 72 high
And DEASSERT does:
gpio 72 low
gpio 60 low
So with the old naming DEASSERT leaves the panel disabled / in reset and
the backlight disabled, which is exactly what we do not want...
I guess it would be good if someone could check if my patch helps
or not on other tablets which use these sequences.
Regards,
Hans
p.s.
I'm also trying to come up with some patches which properly
integrate pwm-lpss with the i915 driver instead of it
throwing a "Failed to own the pwm chip" error. But as soon
as I hook up things so that pwm_get() returns the pwm-lpss
pwm0 I hit:
https://bugs.freedesktop.org/show_bug.cgi?id=97330
I get the same pipe-a stuck (or not seeing vblank irqs?)
problems sometimes without the pwm-lpss driver in the loop
but then only sometimes and with pwm-lpss I get this
problem when loading the i915 driver most of the time
(but not all the time).
I've been debugging this a couple of evenings in a row
now (*) but no luck so far before I fixed the gpio and
assert/deassert swapping I had commented out the
chv_exec_gpio call otherwise the screen would go off
and never come back, with that call commented I was
seeing the same issue.
I was hoping that properly resetting the screen when
fbcon does its disable / re-enable dance would fix this,
but it does not :| Any hints would be greatly appreciated.
*) This series is one result of this, I also have some
designware i2c pmic mux fixes I need to post
>> MIPI_SEQ_BACKLIGHT_ON, /* sequence block v2+ */
>> MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
>> MIPI_SEQ_TEAR_ON, /* sequence block v
[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 --- Comment #2 from Alex Deucher --- Please attach your dmesg output and xorg log. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/87a35b78/attachment.html>
[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 --- Comment #3 from Alex Deucher --- Is this system a hybrid laptop with 2 GPUs (integrated and discrete)? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/5d23cd2d/attachment.html>
[Bug 98901] amdgpu doesn't reinitialize after reboot in Xen PV DomU
https://bugs.freedesktop.org/show_bug.cgi?id=98901 --- Comment #1 from Alex Deucher --- Can you try a more recent kernel? 4.8 or 4.9? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/77e45815/attachment-0001.html>
[drm-intel:drm-intel-next-queued 1/3] drivers/gpu/drm/i915/./i915_trace.h:409:24: error: 'struct i915_address_space' has no member named 'dev'
ign), \
^~
drivers/gpu/drm/i915/./i915_trace.h:436:1: note: in expansion of macro
'TRACE_EVENT'
TRACE_EVENT(i915_gem_evict_vm,
^~~
drivers/gpu/drm/i915/./i915_trace.h:445:6: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^~
drivers/gpu/drm/i915/./i915_trace.h: In function 'perf_trace_i915_ppgtt':
drivers/gpu/drm/i915/./i915_trace.h:714:21: error: 'struct
i915_address_space' has no member named 'dev'
__entry->dev = vm->dev->primary->index;
^
include/trace/perf.h:65:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
drivers/gpu/drm/i915/./i915_trace.h:712:2: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^~
vim +409 drivers/gpu/drm/i915/./i915_trace.h
1c5d22f7 Chris Wilson 2009-08-25 390
903cf20c Li Zefan 2010-03-11 391 DEFINE_EVENT(i915_gem_object,
i915_gem_object_destroy,
05394f39 Chris Wilson 2010-11-08 392 TP_PROTO(struct drm_i915_gem_object
*obj),
903cf20c Li Zefan 2010-03-11 393 TP_ARGS(obj)
1c5d22f7 Chris Wilson 2009-08-25 394 );
1c5d22f7 Chris Wilson 2009-08-25 395
db53a302 Chris Wilson 2011-02-03 @396 TRACE_EVENT(i915_gem_evict,
e522ac23 Chris Wilson 2016-08-04 397 TP_PROTO(struct i915_address_space
*vm, u32 size, u32 align, unsigned int flags),
e522ac23 Chris Wilson 2016-08-04 398 TP_ARGS(vm, size, align, flags),
1c5d22f7 Chris Wilson 2009-08-25 399
db53a302 Chris Wilson 2011-02-03 400 TP_STRUCT__entry(
db53a302 Chris Wilson 2011-02-03 401__field(u32, dev)
e522ac23 Chris Wilson 2016-08-04 402__field(struct
i915_address_space *, vm)
db53a302 Chris Wilson 2011-02-03 403__field(u32, size)
db53a302 Chris Wilson 2011-02-03 404__field(u32, align)
e522ac23 Chris Wilson 2016-08-04 405__field(unsigned
int, flags)
db53a302 Chris Wilson 2011-02-03 406 ),
1c5d22f7 Chris Wilson 2009-08-25 407
db53a302 Chris Wilson 2011-02-03 @408 TP_fast_assign(
e522ac23 Chris Wilson 2016-08-04 @409 __entry->dev =
vm->dev->primary->index;
e522ac23 Chris Wilson 2016-08-04 410 __entry->vm = vm;
db53a302 Chris Wilson 2011-02-03 411 __entry->size = size;
db53a302 Chris Wilson 2011-02-03 412 __entry->align =
align;
:: The code at line 409 was first introduced by commit
:: e522ac2324f384e1fafd1a4ae6ebf38095dc6695 drm/i915: Remove surplus
drm_device parameter to i915_gem_evict_something()
:: TO: Chris Wilson
:: CC: Chris Wilson
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 25157 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/366f926a/attachment-0001.gz>
[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 --- Comment #4 from Tom B --- Created attachment 128266 --> https://bugs.freedesktop.org/attachment.cgi?id=128266&action=edit dmesg output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/e93f2b51/attachment.html>
[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 --- Comment #5 from Tom B --- Created attachment 128267 --> https://bugs.freedesktop.org/attachment.cgi?id=128267&action=edit Xorg log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/68d788a3/attachment.html>
[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 --- Comment #6 from Tom B --- dmesg and xorg attached. Yes, this has dual GPUs, an onboard intel on the i7 4870HQ and a Radeon M370X. lspci | grep VGA output: 00:02.0 VGA compatible controller: Intel Corporation Crystal Well Integrated Graphics Controller (rev 08) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Venus XT [Radeon HD 8870M / R9 M270X/M370X] (rev 83) glxinfo | grep OpenGL output: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD CAPE VERDE (DRM 2.46.0 / 4.8.10-1-ARCH, LLVM 3.9.0) OpenGL core profile version string: 4.3 (Core Profile) Mesa 13.0.1 OpenGL core profile shading language version string: 4.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 13.0.1 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.1 Mesa 13.0.1 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 OpenGL ES profile extensions: The Radeon card is in use. I can switch to the intel card using the gpu-switch utility ( https://aur.archlinux.org/packages/gpu-switch/ ) but the external ports HDMI and DP are connected to the radeon card, and I need to use external monitors frequently. When the intel gpu is used, there is no flicker issue. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/778681be/attachment.html>
[PATCH 1/2] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET
On Tue, Nov 29, 2016 at 02:06:20PM +0100, Hans de Goede wrote:
> Hi,
>
> Thanks for the quick reply.
>
> On 29-11-16 13:48, Ville Syrjälä wrote:
> > On Tue, Nov 29, 2016 at 01:38:57PM +0100, Hans de Goede wrote:
> >> Looking at the ADF code from the Android kernel sources for a
> >> cherrytrail tablet I noticed that it is calling the
> >> MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
> >>
> >> Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
> >> in panel prepare/unprepare hooks") the mainline i915 code was doing the
> >> same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
> >> MIPI_SEQ_DEASSERT_RESET.
> >>
> >> Looking at the naming of the sequences that is the right thing to do,
> >> but the problem is, that the old mainline code and the ADF code was
> >> actually calling the right sequence (tested on a cube iwork8 air tablet),
> >> and the swapping of the calling breaks things.
> >>
> >> This breakage was likely not noticed in testing because on cherrytrail,
> >> currently chv_exec_gpio ends up disabling the gpio pins rather then
> >> setting them (this is fixed in the next patch in this patch-set).
> >>
> >> This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
> >> places in the enum defining them, so that their (new) names match their
> >> actual use.
> >>
> >> Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...")
> >> Cc: Jani Nikula
> >> Cc: Ville Syrjälä
> >> Signed-off-by: Hans de Goede
> >> ---
> >> drivers/gpu/drm/i915/intel_bios.h | 4 ++--
> >> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
> >> 2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> >> b/drivers/gpu/drm/i915/intel_bios.h
> >> index 8405b5a..642a5eb 100644
> >> --- a/drivers/gpu/drm/i915/intel_bios.h
> >> +++ b/drivers/gpu/drm/i915/intel_bios.h
> >> @@ -49,11 +49,11 @@ struct edp_power_seq {
> >> /* MIPI Sequence Block definitions */
> >> enum mipi_seq {
> >>MIPI_SEQ_END = 0,
> >> - MIPI_SEQ_ASSERT_RESET,
> >> + MIPI_SEQ_DEASSERT_RESET,
> >>MIPI_SEQ_INIT_OTP,
> >>MIPI_SEQ_DISPLAY_ON,
> >>MIPI_SEQ_DISPLAY_OFF,
> >> - MIPI_SEQ_DEASSERT_RESET,
> >> + MIPI_SEQ_ASSERT_RESET,
> >
> > That naming would be against the spec, so I don't think we want to do it
> > like this. Unless the spec is totally wrong, that is.
>
> Given that both the ADF code and the i915 driver until now have been using
> assert on prepare and deassert on unprepare I'm inclined to believe that
> the spec is wrong. Is the spec available somewhere public ?
I don't think so. And sadly even if it would it wouldn't really help
since about the only thing it says is:
00 â Reserved
01 - MIPIAssertResetPin
02 â MIPISendInitialDcsCmds (Use this sequence type for sending
initialization commands in LP mode)
03 - MIPIDisplayOn (Use this sequence type for sending initialization commands
in HS mode)
04 â MIPIDisplayOff (Use this sequence type for sending DisplayOff commands
in LP mode)
05 â MIPIDeassertResetPin
06 â MIPIBacklightOn
07 - MIPIBacklightOff
08 â MIPITearOn
09 - MIPITearOff
10 - MIPIPanelPowerOn
11 - MIPIPanelPowerOff
Others â Reserved
So pretty much useless if you actually want to write a working driver.
>
> Also if you look at the v1 sequences with the new names:
>
> MIPI_SEQ_DEASSERT_RESET,
> MIPI_SEQ_INIT_OTP,
> MIPI_SEQ_DISPLAY_ON,
> MIPI_SEQ_DISPLAY_OFF,
> MIPI_SEQ_ASSERT_RESET,
>
> Then they are exactly in the order as one would call them on
> enable, followed by disable, which I believe is not a coincidence.
>
> > Can you provide the VBT for the affected machine so other people can
> > have a look at it?
>
> Sure I can do that, what would be the easiest way (both for me to
> produce and for you to consume) to do this ?
/sys/kernel/debug/dri/0/i915_opregion
For the best chance of preserving the dump for posterity I would
suggest filing a new bug and attaching it there.
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
>
> While developing this set, I've added printk calls to the code executing the
> sequences, there are 2 gpios involved nr 60 (backlight enable AFAICT, also
> used
> by the BACKLIGHT sequences) and 72 (reset / panel_enable ?).
> When efifb is up both are 1 / high.
>
> With the OLD naming, MIPI_SEQ_ASSERT_RESET does:
>
> gpio 72 high
> delay
> gpio 72 low
> delay
> gpio 72 high
Hmm. OK so it just toggles the reset pin it seems.
>
> And DEASSERT does:
>
> gpio 72 low
> gpio 60 low
And this leaves the reset pin asserted, assuming it's active low,
which your patch would seem to confirm.
>
> So with the old naming DEASSERT leaves the panel disabled / in reset and
> the backlight disabled, which is exactly what we do not want...
Right. Hmm. If we do flip them over like you suggest I think we'll at
least need a big comment to inform people why we seem to
[PATCH] drm/doc: Fix indenting in drm_modeset_lock.c comment
On Tue, Nov 29, 2016 at 10:24:40AM +0100, Daniel Vetter wrote: > This isn't part of the code snippet anymore ... > > Signed-off-by: Daniel Vetter Merged with Rob's irc-ack. -Daniel > --- > drivers/gpu/drm/drm_modeset_lock.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/drm_modeset_lock.c > b/drivers/gpu/drm/drm_modeset_lock.c > index 9059fe3145a1..3551ae31f143 100644 > --- a/drivers/gpu/drm/drm_modeset_lock.c > +++ b/drivers/gpu/drm/drm_modeset_lock.c > @@ -52,12 +52,12 @@ > * drm_modeset_drop_locks(&ctx); > * drm_modeset_acquire_fini(&ctx); > * > - * On top of of these per-object locks using &ww_mutex there's also an > overall > - * dev->mode_config.lock, for protecting everything else. Mostly this means > - * probe state of connectors, and preventing hotplug add/removal of > connectors. > + * On top of of these per-object locks using &ww_mutex there's also an > overall > + * dev->mode_config.lock, for protecting everything else. Mostly this means > + * probe state of connectors, and preventing hotplug add/removal of > connectors. > * > - * Finally there's a bunch of dedicated locks to protect drm core internal > - * lists and lookup data structures. > + * Finally there's a bunch of dedicated locks to protect drm core internal > + * lists and lookup data structures. > */ > > static DEFINE_WW_CLASS(crtc_ww_class); > -- > 2.10.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm: Fix locking cargo-cult in encoder/plane init/cleanup
On Tue, Nov 29, 2016 at 10:39:03AM +, Frank Binns wrote:
> On 29/11/16 09:45, Daniel Vetter wrote:
> > Encoders&planes can't be hotplugged, we dont need looking for this
>
> s/looking/locking/
>
> With that changed:
> Reviewed-by: Frank Binns
Fixed&applied, thanks for your review.
-Daniel
>
> > since it's all single-threaded driver setup/teardown code. CRTCs
> > already don't grab locks.
> >
> > While at it I noticed that plane's are missing the
> > drm_modeset_lock_fini() call, so add it.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_encoder.c | 9 +
> > drivers/gpu/drm/drm_plane.c | 4 ++--
> > 2 files changed, 3 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> > index 5c067719164d..992879f15f23 100644
> > --- a/drivers/gpu/drm/drm_encoder.c
> > +++ b/drivers/gpu/drm/drm_encoder.c
> > @@ -110,11 +110,9 @@ int drm_encoder_init(struct drm_device *dev,
> > {
> > int ret;
> > - drm_modeset_lock_all(dev);
> > -
> > ret = drm_mode_object_get(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER);
> > if (ret)
> > - goto out_unlock;
> > + return ret;
> > encoder->dev = dev;
> > encoder->encoder_type = encoder_type;
> > @@ -142,9 +140,6 @@ int drm_encoder_init(struct drm_device *dev,
> > if (ret)
> > drm_mode_object_unregister(dev, &encoder->base);
> > -out_unlock:
> > - drm_modeset_unlock_all(dev);
> > -
> > return ret;
> > }
> > EXPORT_SYMBOL(drm_encoder_init);
> > @@ -164,12 +159,10 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
> > * the indices on the drm_encoder after us in the encoder_list.
> > */
> > - drm_modeset_lock_all(dev);
> > drm_mode_object_unregister(dev, &encoder->base);
> > kfree(encoder->name);
> > list_del(&encoder->head);
> > dev->mode_config.num_encoder--;
> > - drm_modeset_unlock_all(dev);
> > memset(encoder, 0, sizeof(*encoder));
> > }
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 419ac313c36f..9147aab182c4 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -221,7 +221,8 @@ void drm_plane_cleanup(struct drm_plane *plane)
> > {
> > struct drm_device *dev = plane->dev;
> > - drm_modeset_lock_all(dev);
> > + drm_modeset_lock_fini(&plane->mutex);
> > +
> > kfree(plane->format_types);
> > drm_mode_object_unregister(dev, &plane->base);
> > @@ -236,7 +237,6 @@ void drm_plane_cleanup(struct drm_plane *plane)
> > dev->mode_config.num_total_plane--;
> > if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> > dev->mode_config.num_overlay_plane--;
> > - drm_modeset_unlock_all(dev);
> > WARN_ON(plane->state && !plane->funcs->atomic_destroy_state);
> > if (plane->state && plane->funcs->atomic_destroy_state)
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[ANNOUNCE] libdrm 2.4.74
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Widawsky (1): intel: Add Geminilake PCI IDs Christian Gmeiner (4): etnaviv: add API to get drm fd from etna_device etnaviv: add API to create etna_device from private dup() fd etnaviv: change get_abs_timeout(..) to use ns. etnaviv: add etna_pipe_wait_ns(..) Emil Velikov (2): automake: make the build less chatty xf86drm: introduce drmGetDeviceNameFromFd2 Eric Anholt (1): vc4: Add new GETPARAMs that have been merged to drm-next. Grazvydas Ignotas (2): tests: kms: fix shadowed declaration warning libdrm: random typo fixes Michel Dänzer (1): intel: Add drm_intel_gem_context_get_id to intel-symbols-check Rob Clark (1): freedreno: 64bit support Robert Bragg (2): intel: Add a getter for the intel_context ctx_id Bump version for release git tag: libdrm-2.4.74 https://dri.freedesktop.org/libdrm/libdrm-2.4.74.tar.bz2 MD5: 31964aa15bdea1a40c5941d4ce0962ee libdrm-2.4.74.tar.bz2 SHA1: 0d9c02d5d2c6c2fac862cb687bf45bc20d129017 libdrm-2.4.74.tar.bz2 SHA256: d80dd5a76c401f4c8756dcccd999c63d7e0a3bad258d96a829055cfd86ef840b libdrm-2.4.74.tar.bz2 PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.74.tar.bz2.sig https://dri.freedesktop.org/libdrm/libdrm-2.4.74.tar.gz MD5: b661a54514109caad3de3b520680b98e libdrm-2.4.74.tar.gz SHA1: 7b5a80fbdd432e87934ef3b1256a58ed7b034574 libdrm-2.4.74.tar.gz SHA256: 3c8fdf5a89826797a8060e6f3455ca22db9ae49576cfcda1c78e3e2ce59af0f1 libdrm-2.4.74.tar.gz PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.74.tar.gz.sig -BEGIN PGP SIGNATURE- iEYEARECAAYFAlg9iT0ACgkQjNHfVSl1KXvN2QCfSj1H53aYHdMVMUN2B64FVF5E n0QAn0Fn3jDlrl6lpdbTJO3Mclg9WFUZ =+4Tx -END PGP SIGNATURE-
[PATCH 0/4] drm: Add support for the Amlogic Video Processing Unit
On Tue, Nov 29, 2016 at 11:47:45AM +0100, Neil Armstrong wrote: > This a repost of the previous RFC at [1] with fixes, the following patches > will > be sent via a PULL Request once the Amlogic maintainer acks and takes the DT > patches to avoid merges conflicts. > > The Amlogic Meson SoCs embeds a Video Processing Unit able to output at least > a Composite/CVBS Video with embedded VDAC and an HDMI Link with Embedded HDMI > Transceiver. > > Thus, the current driver does not support HDMI yet. > > The Video Processig Unit is composed of multiple modules like the Video > Input Unit and the Video Post Processing that can be associated to a > CRTC with Planes management. > The last Unit is the Venc that embeds at least 3 Encoders, ENCI for Interlace > Video used by CVBS or HDMI, ENCP for Progressive Video used by the HDMI > Transceiver and ENCL for LCD Display. > > The LCD Display is not planned to be supported on the Meson GX Family. > > This driver is a DRM/KMS driver using the following DRM components : > - GEM-CMA > - PRIME-CMA > - Atomic Modesetting > - FBDev-CMA > > For the following SoCs : > - GXBB Family (S905) > - GXL Family (S905X, S905D) > - GXM Family (S912) > > The current driver only supports the CVBS PAL/NTSC output modes, but the > CRTC/Planes management should support bigger modes. > But Advanced Colorspace Conversion, Scaling and HDMI Modes will be added in > a second time. > > The Device Tree bindings makes use of the endpoints video interface > definitions > to connect to the optional CVBS and in the future the HDMI Connector nodes. > > The driver has been tested with Xorg modesetting driver and Weston DRM > backend. > > Changes since RFC at [1] : > - Add maintainers entry > - Move all Plane and CRTC code from backend to corresponding DRM code > - Keep only init and common code in backend source files > - Move the CVBS encoder out of the CVBS DT node, only keep the connector > - Various cleanups using DRM helpers > - Cleanup of copyright headers > - Fixup of bindings documentation > > [1] http://lkml.kernel.org/r/1480089791-12517-1-git-send-email-narmstrong at > baylibre.com > > Neil Armstrong (4): > drm: Add support for Amlogic Meson Graphic Controller > ARM64: dts: meson-gx: Add Graphic Controller nodes > dt-bindings: display: add Amlogic Meson DRM Bindings > MAINTAINERS: add entry for Amlogic DRM drivers I think this is all reasonable, once you have an ack from DT maintainers pls send the pull request to Dave. Acked-by: Daniel Vetter > > .../bindings/display/meson/meson-drm.txt | 134 ++ > MAINTAINERS|9 + > arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 46 + > .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts|4 + > arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi |4 + > arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|8 + > .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts |4 + > arch/arm64/boot/dts/amlogic/meson-gxl.dtsi |8 + > .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts |4 + > arch/arm64/boot/dts/amlogic/meson-gxm.dtsi |8 + > drivers/gpu/drm/Kconfig|2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/meson/Kconfig |9 + > drivers/gpu/drm/meson/Makefile |5 + > drivers/gpu/drm/meson/meson_canvas.c | 68 + > drivers/gpu/drm/meson/meson_canvas.h | 42 + > drivers/gpu/drm/meson/meson_crtc.c | 208 +++ > drivers/gpu/drm/meson/meson_crtc.h | 32 + > drivers/gpu/drm/meson/meson_cvbs.c | 177 +++ > drivers/gpu/drm/meson/meson_drv.c | 385 ++ > drivers/gpu/drm/meson/meson_drv.h | 61 + > drivers/gpu/drm/meson/meson_plane.c| 230 > drivers/gpu/drm/meson/meson_plane.h| 30 + > drivers/gpu/drm/meson/meson_registers.h| 1395 > > drivers/gpu/drm/meson/meson_vclk.c | 167 +++ > drivers/gpu/drm/meson/meson_vclk.h | 34 + > drivers/gpu/drm/meson/meson_venc.c | 254 > drivers/gpu/drm/meson/meson_venc.h | 72 + > drivers/gpu/drm/meson/meson_venc_cvbs.c| 187 +++ > drivers/gpu/drm/meson/meson_venc_cvbs.h| 41 + > drivers/gpu/drm/meson/meson_viu.c | 331 + > drivers/gpu/drm/meson/meson_viu.h | 64 + > drivers/gpu/drm/meson/meson_vpp.c | 162 +++ > drivers/gpu/drm/meson/meson_vpp.h | 35 + > 34 files changed, 4221 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/meson/meson-drm.txt > create mode 100644 drivers/gpu/drm/meson/Kconfig > create mode 100644 drivers/gpu/drm/meson/Makefile > create mode 100644 drivers/gpu/drm
[GIT PULL] exynos-drm-fixes
2016-11-25 8:59 GMT+09:00 Dave Airlie : >>No critial patch but it make sure to unmap the region >>if HDMI probing failed, and it includes two trivial fixups. >> > > I've cherry-picked the hdmi fix, but I think the other two patches > should go in -next > at this stage, Thanks, Inki Dae > > Thanks, > Dave. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 1/8] drm: sun8i: Add a basic DRM driver for Allwinner DE2
On Mon, Nov 28, 2016 at 03:23:54PM +0100, Jean-Francois Moine wrote: > Allwinner's recent SoCs, as A64, A83T and H3, contain a new display > engine, DE2. > This patch adds a DRM video driver for this device. > > Signed-off-by: Jean-Francois Moine Scrolled around a bit, seemed all reasonable. Acked-by: Daniel Vetter Not sure a new driver for each chip is reasonable, experience says that long-term you want to share quite a pile of code between different hw platforms from the same vendor. But that's entirely up to you. -Daniel > --- > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/sun8i/Kconfig | 19 + > drivers/gpu/drm/sun8i/Makefile| 7 + > drivers/gpu/drm/sun8i/de2_crtc.c | 449 +++ > drivers/gpu/drm/sun8i/de2_crtc.h | 50 +++ > drivers/gpu/drm/sun8i/de2_drv.c | 317 > drivers/gpu/drm/sun8i/de2_drv.h | 48 +++ > drivers/gpu/drm/sun8i/de2_plane.c | 734 > ++ > 9 files changed, 1627 insertions(+) > create mode 100644 drivers/gpu/drm/sun8i/Kconfig > create mode 100644 drivers/gpu/drm/sun8i/Makefile > create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.c > create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.h > create mode 100644 drivers/gpu/drm/sun8i/de2_drv.c > create mode 100644 drivers/gpu/drm/sun8i/de2_drv.h > create mode 100644 drivers/gpu/drm/sun8i/de2_plane.c > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 95fc041..bb1bfbc 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -202,6 +202,8 @@ source "drivers/gpu/drm/shmobile/Kconfig" > > source "drivers/gpu/drm/sun4i/Kconfig" > > +source "drivers/gpu/drm/sun8i/Kconfig" > + > source "drivers/gpu/drm/omapdrm/Kconfig" > > source "drivers/gpu/drm/tilcdc/Kconfig" > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 883f3e7..3e1eaa0 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -72,6 +72,7 @@ obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/ > obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/ > obj-y+= omapdrm/ > obj-$(CONFIG_DRM_SUN4I) += sun4i/ > +obj-$(CONFIG_DRM_SUN8I) += sun8i/ > obj-y+= tilcdc/ > obj-$(CONFIG_DRM_QXL) += qxl/ > obj-$(CONFIG_DRM_BOCHS) += bochs/ > diff --git a/drivers/gpu/drm/sun8i/Kconfig b/drivers/gpu/drm/sun8i/Kconfig > new file mode 100644 > index 000..6940895 > --- /dev/null > +++ b/drivers/gpu/drm/sun8i/Kconfig > @@ -0,0 +1,19 @@ > +# > +# Allwinner DE2 Video configuration > +# > + > +config DRM_SUN8I > + bool > + > +config DRM_SUN8I_DE2 > + tristate "Support for Allwinner Video with DE2 interface" > + depends on DRM && OF > + depends on ARCH_SUNXI || COMPILE_TEST > + select DRM_GEM_CMA_HELPER > + select DRM_KMS_CMA_HELPER > + select DRM_KMS_HELPER > + select DRM_SUN8I > + help > + Choose this option if your Allwinner chipset has the DE2 interface > + as the A64, A83T and H3. If M is selected the module will be called > + sun8i-de2-drm. > diff --git a/drivers/gpu/drm/sun8i/Makefile b/drivers/gpu/drm/sun8i/Makefile > new file mode 100644 > index 000..f107919 > --- /dev/null > +++ b/drivers/gpu/drm/sun8i/Makefile > @@ -0,0 +1,7 @@ > +# > +# Makefile for Allwinner's sun8i DRM device driver > +# > + > +sun8i-de2-drm-objs := de2_drv.o de2_crtc.o de2_plane.o > + > +obj-$(CONFIG_DRM_SUN8I_DE2) += sun8i-de2-drm.o > diff --git a/drivers/gpu/drm/sun8i/de2_crtc.c > b/drivers/gpu/drm/sun8i/de2_crtc.c > new file mode 100644 > index 000..4e94ccc > --- /dev/null > +++ b/drivers/gpu/drm/sun8i/de2_crtc.c > @@ -0,0 +1,449 @@ > +/* > + * Allwinner DRM driver - DE2 CRTC > + * > + * Copyright (C) 2016 Jean-Francois Moine > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) any later version. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include "de2_drv.h" > +#include "de2_crtc.h" > + > +/* I/O map */ > + > +#define TCON_GCTL_REG0x00 > +#define TCON_GCTL_TCON_ENABLE BIT(31) > +#define TCON_GINT0_REG 0x04 > +#define TCON_GINT0_TCON1_Vb_Int_En BIT(30) > +#define TCON_GINT0_TCON1_Vb_Int_Flag BIT(14) > +#define TCON_GINT0_TCON1_Vb_Line_Int_Flag BIT(12) > +#define TCON0_CTL_REG0x40 > +#define TCON0_CTL_TCON_ENABLE BIT(31) > +#define TCON1_CTL_REG0x90 > +#define TCON1_CTL_TCON_ENABLE BIT(31) > +#define TCON1_CTL_INTERLACE_ENABLE BIT(20) > +#define TCON1_CTL_Start_Delay_SHIFT 4 > +#define TCON1_CTL_Start_Delay_MASK GENMASK(8, 4) > +#define TCON1_BASIC0_REG 0x94/
[PATCH] dim: Add status command
Useful with our branch proliferation to make sure nothing is stuck (we
now also have drm-misc-next/-next-fixes/-fixes).
v2: Gracefully handle if some remotes arent' there.
Acked-by: seanpaul at chromium.org
Signed-off-by: Daniel Vetter
---
dim | 22 ++
dim.rst | 5 +
2 files changed, 27 insertions(+)
diff --git a/dim b/dim
index 3dd2d1dec796..b21d1321af09 100755
--- a/dim
+++ b/dim
@@ -1285,6 +1285,28 @@ function dim_update_branches
update_rerere_cache
}
+function dim_status
+{
+ local repo remote drm_remote patches
+
+ cd $DIM_PREFIX/$DIM_DRM_INTEL
+
+ drm_remote=$(url_to_remote $drm_upstream_git)
+
+ for branch in $dim_branches ; do
+ repo=`branch_to_repo $branch`
+ if ! remote=`repo_to_remote $repo` ; then
+ continue
+ fi
+
+ patches=$(git log --oneline $remote/$branch ^origin/master
^$drm_remote/drm-next ^$drm_remote/drm-fixes | wc -l)
+
+ if [[ $patches -ne 0 ]] ; then
+ echo $repo/$branch: $patches unmerged patches
+ fi
+ done
+}
+
function setup_aux_checkout # name url directory
{
local name url dir remote
diff --git a/dim.rst b/dim.rst
index 9a045a43e7b7..0c52ab43e400 100644
--- a/dim.rst
+++ b/dim.rst
@@ -80,6 +80,11 @@ always maintained from the same machine, even if different
branches are
maintained on different machines (by different maintainers), there's no need to
run this command.
+status
+--
+
+Lists all branches with unmerged patches, and how many patches are unmerged.
+
rebuild-tip
---
Rebuild and push the integration tree.
--
2.10.2
[RESEND PATCH] drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency
Commit aeefb36832e5 ("drm/exynos: gsc: add device tree support and remove
usage of static mappings") made the DRM_EXYNOS_GSC Kconfig symbol to only
be selectable if the exynos-gsc V4L2 driver isn't enabled, since both use
the same HW IP block.
But added the dependency as depends on !VIDEO_SAMSUNG_EXYNOS_GSC which is
not correct since Kconfig expressions are not boolean but tristate. So it
will only evaluate to 'n' if VIDEO_SAMSUNG_EXYNOS_GSC=y but will evaluate
to 'm' if VIDEO_SAMSUNG_EXYNOS_GSC=m.
This means that both the V4L2 and DRM drivers can be enabled if the former
is enabled as a module, which isn't what we want since otherwise 2 drivers
could attempt to use the hardware at the same time.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/exynos/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 465d344f3391..d706ca4e2f02 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -114,7 +114,7 @@ config DRM_EXYNOS_ROTATOR
config DRM_EXYNOS_GSC
bool "GScaler"
- depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && !VIDEO_SAMSUNG_EXYNOS_GSC
+ depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
help
Choose this option if you want to use Exynos GSC for DRM.
--
2.7.4
[PATCH] drm: parse hf-vsdb
HDMI 2.0 / CEA-861-F specs define a new CEA extension data block,
called hdmi-forum vendor specific data block (HF-VSDB). This block
contains information about sink's support for HDMI 2.0 compliant
features. These features are:
- Deep color YUV 420 support and BPC
- 3D flags for
- OSD Displarity
- Dual view signaling
- independent view signaling
- SCDC support
- Max TMDS char rate
- Scrambling support
This patch adds a parser function for this block, and add flags to
indicate support for new features, in drm_display_info structure.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 73 +
include/drm/drm_connector.h | 48 +
include/drm/drm_edid.h | 5
include/linux/hdmi.h| 1 +
4 files changed, 127 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 336be31..b18bfe0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3223,6 +3223,27 @@ static int add_3d_struct_modes(struct drm_connector
*connector, u16 structure,
return 0;
}
+static bool cea_db_is_hf_vsdb(const u8 *db)
+{
+ u8 len;
+ int hfvsdb_id;
+
+ if (cea_db_tag(db) != VENDOR_BLOCK)
+ return false;
+
+ len = cea_db_payload_len(db);
+ if (len < 7 || len > 31)
+ return false;
+
+ /* version should be 1 */
+ if (db[4] != 1)
+ return false;
+
+ hfvsdb_id = db[1] | (db[2] << 8) | (db[3] << 16);
+
+ return hfvsdb_id == HDMI_IEEE_OUI_HFVSDB;
+}
+
static bool cea_db_is_hdmi_vsdb(const u8 *db)
{
int hdmi_id;
@@ -3767,6 +3788,56 @@ bool drm_rgb_quant_range_selectable(struct edid *edid)
}
EXPORT_SYMBOL(drm_rgb_quant_range_selectable);
+static void drm_parse_yuv420_deep_color_info(struct drm_connector *connector,
+ const u8 *db)
+{
+ struct drm_display_info *info = &connector->display_info;
+
+ if (db[7] & DRM_EDID_YUV420_DC_48)
+ info->edid_yuv420_dc_modes |= DRM_EDID_YUV420_DC_48;
+ if (db[7] & DRM_EDID_YUV420_DC_36)
+ info->edid_yuv420_dc_modes |= DRM_EDID_YUV420_DC_36;
+ if (db[7] & DRM_EDID_YUV420_DC_30)
+ info->edid_yuv420_dc_modes |= DRM_EDID_YUV420_DC_30;
+
+ if (!info->edid_yuv420_dc_modes) {
+ DRM_DEBUG("%s: No YUV 420 deep color support in sink.\n",
+ connector->name);
+ return;
+ }
+}
+
+static void
+drm_parse_hf_vsdb(struct drm_connector *connector, const u8 *db)
+{
+ struct drm_display_info *info = &connector->display_info;
+
+ if (db[5]) {
+ /*
+* If the sink supplies max tmds char rate in db,
+* the actual max tmds rate = db[5] * 5Mhz.
+*/
+ info->max_tmds_clock = db[5] * 5000;
+ DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+ info->max_tmds_clock);
+ }
+
+ if (db[6] & DRM_HFVSDB_SCDC_SUPPORT)
+ info->scdc_supported = true;
+ if (db[6] & DRM_HFVSDB_SCDC_RR_CAP)
+ info->scdc_rr_cap = true;
+ if (db[6] & DRM_HFVSDB_SCRAMBLING)
+ info->scrambling = true;
+ if (db[6] & DRM_HFVSDB_INDEPENDENT_VIEW)
+ info->independent_view_3d = true;
+ if (db[6] & DRM_HFVSDB_DUAL_VIEW)
+ info->dual_view_3d = true;
+ if (db[6] & DRM_HFVSDB_3D_OSD)
+ info->osd_disparity_3d = true;
+
+ drm_parse_yuv420_deep_color_info(connector, db);
+}
+
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
const u8 *hdmi)
{
@@ -3881,6 +3952,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
if (cea_db_is_hdmi_vsdb(db))
drm_parse_hdmi_vsdb_video(connector, db);
+ if (cea_db_is_hf_vsdb(db))
+ drm_parse_hf_vsdb(connector, db);
}
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 34f9741..d011dd5 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -167,6 +167,46 @@ struct drm_display_info {
*/
u32 bus_flags;
+#define DRM_HFVSDB_SCDC_SUPPORT(1<<7)
+#define DRM_HFVSDB_SCDC_RR_CAP (1<<6)
+#define DRM_HFVSDB_SCRAMBLING (1<<3)
+#define DRM_HFVSDB_INDEPENDENT_VIEW(1<<2)
+#define DRM_HFVSDB_DUAL_VIEW (1<<1)
+#define DRM_HFVSDB_3D_OSD (1<<0)
+
+ /**
+* @scdc_supported: Sink supports SCDC functionality.
+*/
+ bool scdc_supported;
+
+ /**
+* @scdc_rr_cap: Sink has SCDC read request capability.
+*/
+ bool scdc_rr_cap;
+
+ /**
+* @scrambling: Sync supports scrambling for <=340 Mcsc TMDS
+
[PATCH RFC] drm: Add a new connector atomic property for link status
On Mon, Nov 28, 2016 at 7:59 PM, Manasi Navare
wrote:
> On Wed, Nov 23, 2016 at 09:09:28AM +0100, Daniel Vetter wrote:
>> On Tue, Nov 22, 2016 at 09:27:35PM -0500, Sean Paul wrote:
>> > On Tue, Nov 22, 2016 at 8:30 PM, Manasi Navare
>> > wrote:
>> > > This is RFC patch for adding a connector link-status property
>> > > and making it atomic by adding it to the drm_connector_state.
>> > > This is to make sure its wired properly in
>> > > drm_atomic_connector_set_property
>> > > and drm_atomic_connector_get_property functions.
>> > >
>> >
>> > Thanks for sending this. We ran into some re-training awkwardness
>> > recently, and I
>> > was hoping for such a patch.
>> >
>> > > Cc: Jani Nikula
>> > > Cc: Daniel Vetter
>> > > Cc: Ville Syrjala
>> > > Cc: Chris Wilson
>> > > Signed-off-by: Manasi Navare
>> > > ---
>> > > drivers/gpu/drm/drm_atomic.c| 5
>> > > drivers/gpu/drm/drm_connector.c | 65
>> > > +++--
>> > > include/drm/drm_connector.h | 12 +++-
>> > > include/drm/drm_mode_config.h | 5
>> > > include/uapi/drm/drm_mode.h | 4 +++
>> > > 5 files changed, 88 insertions(+), 3 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> > > index 89737e4..644d19f 100644
>> > > --- a/drivers/gpu/drm/drm_atomic.c
>> > > +++ b/drivers/gpu/drm/drm_atomic.c
>> > > @@ -1087,6 +1087,9 @@ int drm_atomic_connector_set_property(struct
>> > > drm_connector *connector,
>> > > * now?) atomic writes to DPMS property:
>> > > */
>> > > return -EINVAL;
>> > > + } else if (property == config->link_status_property) {
>> > > + state->link_status = val;
>>
>> I think we should have a check here to make sure userspace never tries to
>> set this from "GOOD" to "BAD". "BAD" to "BAD" we need to allow, since with
>> atomic userspace is supposed to be able to just restore everything to what
>> it was.
>>
>> I don't think trying to set it to "BAD" should cause an error though, just
>> silently keep the link status at "GOOG". So:
>>
>> /* Never downgrade from GOOD to BAD on userspace's request here,
>>* only hw issues can do that. */
>> if (state->link_status == GOOD)
>> return 0;
>> state->link_status = val;
>> return 0;
>>
>> > > + return 0;
>> > > } else if (connector->funcs->atomic_set_property) {
>> > > return connector->funcs->atomic_set_property(connector,
>> > > state, property, val);
>> > > @@ -1135,6 +1138,8 @@ static void
>> > > drm_atomic_connector_print_state(struct drm_printer *p,
>> > > *val = (state->crtc) ? state->crtc->base.id : 0;
>> > > } else if (property == config->dpms_property) {
>> > > *val = connector->dpms;
>> > > + } else if (property == config->link_status_property) {
>> > > + *val = state->link_status;
>> > > } else if (connector->funcs->atomic_get_property) {
>> > > return connector->funcs->atomic_get_property(connector,
>> > > state, property, val);
>> > > diff --git a/drivers/gpu/drm/drm_connector.c
>> > > b/drivers/gpu/drm/drm_connector.c
>> > > index 5a45262..4576c9f 100644
>> > > --- a/drivers/gpu/drm/drm_connector.c
>> > > +++ b/drivers/gpu/drm/drm_connector.c
>> > > @@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
>> > > drm_object_attach_property(&connector->base,
>> > > config->dpms_property, 0);
>> > >
>> > > + drm_object_attach_property(&connector->base,
>> > > + config->link_status_property,
>> > > + 0);
>> > > +
>> > > if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
>> > > drm_object_attach_property(&connector->base,
>> > > config->prop_crtc_id, 0);
>> > > }
>> > > @@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum
>> > > subpixel_order order)
>> > > };
>> > > DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
>> > >
>> > > +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
>> > > + { DRM_MODE_LINK_STATUS_GOOD, "Good" },
>> > > + { DRM_MODE_LINK_STATUS_BAD, "Bad" },
>> > > +};
>> > > +DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
>> > > +
>> > > /**
>> > > * drm_display_info_set_bus_formats - set the supported bus formats
>> > > * @info: display info to store bus formats in
>> > > @@ -616,7 +626,7 @@ int drm_display_info_set_bus_formats(struct
>> > > drm_display_info *info,
>> > > * path property the MST manager created. Userspace cannot change
>> > > this
>> > > * property.
>> > > * TILE:
>> > > - * Connector tile group property to indicate how a set of DRM
>> > > connector
>> > > + * Connector tile
[PATCH v2 01/13] devicetree/bindings: display: Document common panel properties
On Tue, Nov 29, 2016 at 2:27 AM, Laurent Pinchart wrote: > Hi Rob, > > On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart wrote: >> On Monday 21 Nov 2016 10:48:15 Rob Herring wrote: >> > On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote: >> >> Document properties common to several display panels in a central >> >> location that can be referenced by the panel device tree bindings. >> > >> > Looks good. Just one comment... >> > >> > [...] >> > >> >> +Connectivity >> >> + >> >> + >> >> +- ports: Panels receive video data through one or multiple connections. >> >> While >> >> + the nature of those connections is specific to the panel type, the >> >> + connectivity is expressed in a standard fashion using ports as >> >> specified in >> >> + the device graph bindings defined in >> >> + Documentation/devicetree/bindings/graph.txt. >> > >> > We allow panels to either use graph binding or be a child of the display >> > controller. >> >> I knew that some display controllers use a phandle to the panel (see the >> fsl,panel and nvidia,panel properties), but I didn't know we had panels as >> children of display controller nodes. I don't think we should allow that for >> anything but DSI panels, as the DT hierarchy is based on control buses. Are >> you sure we have other panels instantiated through that mechanism ? Some panels have no control bus, so were do we place them? I would say the hierarchy is based on buses with a preference for the control bus when there are multiple buses. I'm not a fan of just sticking things are the top level. > Ping ? > > Please note that this file documents properties common to multiple panel DT > bindings, but in no way makes it mandatory to use the OF graph bindings for > panels. The decision is left to individual bindings. It is mandatory in the sense that we don't want more cases of "fsl,panel". Rob
[pull] radeon and amdgpu drm-fixes-4.9
Hi Dave, Regression fixes for PX and a powerplay fix. The following changes since commit 9704668e4b7105ede483f38da7f29d71b5bc0165: Merge branch 'mediatek-drm-fixes-2016-11-24' of https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes (2016-11-25 14:21:26 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.9 for you to fetch changes up to bcfdd5d5105087e6f33dfeb08a1ca6b2c0287b61: drm/radeon: fix check for port PM availability (2016-11-29 09:24:13 -0500) Alex Deucher (1): drm/radeon: fix check for port PM availability Peter Wu (1): drm/amdgpu: fix check for port PM availability Rex Zhu (1): drm/amd/powerplay: initialize the soft_regs offset in struct smu7_hwmgr drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 11 +-- drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c | 5 - drivers/gpu/drm/radeon/radeon_atpx_handler.c | 11 +-- 3 files changed, 22 insertions(+), 5 deletions(-)
