[PULL] drm-intel-fixes
On 2 January 2016 at 23:56, Jani Nikula wrote: > > Hi Dave, Linus - Hi Linus, can you pull this directly, baby has arrived, but I'm not back at work yet. Dave. > > Two display fixes still for v4.4. > > The new year's resolution is to start using signed tags per Linus' > request. This one is still unsigned; I want to fix this up in our > maintainer scripts instead of doing it one-off. > > > BR, > Jani. > > The following changes since commit a98728e0bb978fbe9246c93ea89198de612c22e6: > > drm/i915: Correct max delay for HDMI hotplug live status checking > (2015-12-22 13:01:24 +0200) > > are available in the git repository at: > > git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-01-02 > > for you to fetch changes up to 3d8acd1f667b45c531401c8f0c2033072e32a05d: > > drm/i915: increase the tries for HDMI hotplug live status checking > (2015-12-30 13:58:37 +0200) > > > Gary Wang (1): > drm/i915: increase the tries for HDMI hotplug live status checking > > Ville Syrjälä (1): > drm/i915: Unbreak check_digital_port_conflicts() > > drivers/gpu/drm/i915/intel_display.c | 12 > drivers/gpu/drm/i915/intel_hdmi.c| 2 +- > 2 files changed, 9 insertions(+), 5 deletions(-) > > -- > Jani Nikula, Intel Open Source Technology Center
[PATCH RESEND 3/3] drm: adv7511: it's HPD, not HDP
From: Wolfram Sang
Fix this typo, consequently used over both files :)
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/i2c/adv7511.c | 22 +++---
drivers/gpu/drm/i2c/adv7511.h | 12 ++--
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index 50a861b12346c4..c03c1ea53fd042 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -378,16 +378,16 @@ static void adv7511_power_on(struct adv7511 *adv7511)
}
/*
-* Per spec it is allowed to pulse the HDP signal to indicate that the
+* Per spec it is allowed to pulse the HPD signal to indicate that the
* EDID information has changed. Some monitors do this when they wakeup
-* from standby or are enabled. When the HDP goes low the adv7511 is
+* from standby or are enabled. When the HPD goes low the adv7511 is
* reset and the outputs are disabled which might cause the monitor to
-* go to standby again. To avoid this we ignore the HDP pin for the
+* go to standby again. To avoid this we ignore the HPD pin for the
* first few seconds after enabling the output.
*/
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
- ADV7511_REG_POWER2_HDP_SRC_MASK,
- ADV7511_REG_POWER2_HDP_SRC_NONE);
+ ADV7511_REG_POWER2_HPD_SRC_MASK,
+ ADV7511_REG_POWER2_HPD_SRC_NONE);
/*
* Most of the registers are reset during power down or when HPD is low.
@@ -421,9 +421,9 @@ static bool adv7511_hpd(struct adv7511 *adv7511)
if (ret < 0)
return false;
- if (irq0 & ADV7511_INT0_HDP) {
+ if (irq0 & ADV7511_INT0_HPD) {
regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
-ADV7511_INT0_HDP);
+ADV7511_INT0_HPD);
return true;
}
@@ -446,7 +446,7 @@ static int adv7511_irq_process(struct adv7511 *adv7511)
regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0);
regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
- if (irq0 & ADV7511_INT0_HDP && adv7511->encoder)
+ if (irq0 & ADV7511_INT0_HPD && adv7511->encoder)
drm_helper_hpd_irq_event(adv7511->encoder->dev);
if (irq0 & ADV7511_INT0_EDID_READY || irq1 & ADV7511_INT1_DDC_ERROR) {
@@ -648,10 +648,10 @@ adv7511_encoder_detect(struct drm_encoder *encoder,
if (adv7511->status == connector_status_connected)
status = connector_status_disconnected;
} else {
- /* Renable HDP sensing */
+ /* Renable HPD sensing */
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
- ADV7511_REG_POWER2_HDP_SRC_MASK,
- ADV7511_REG_POWER2_HDP_SRC_BOTH);
+ ADV7511_REG_POWER2_HPD_SRC_MASK,
+ ADV7511_REG_POWER2_HPD_SRC_BOTH);
}
adv7511->status = status;
diff --git a/drivers/gpu/drm/i2c/adv7511.h b/drivers/gpu/drm/i2c/adv7511.h
index 6599ed538426d6..38515b30cedfc8 100644
--- a/drivers/gpu/drm/i2c/adv7511.h
+++ b/drivers/gpu/drm/i2c/adv7511.h
@@ -90,7 +90,7 @@
#define ADV7511_CSC_ENABLE BIT(7)
#define ADV7511_CSC_UPDATE_MODEBIT(5)
-#define ADV7511_INT0_HDP BIT(7)
+#define ADV7511_INT0_HPD BIT(7)
#define ADV7511_INT0_VSYNC BIT(5)
#define ADV7511_INT0_AUDIO_FIFO_FULL BIT(4)
#define ADV7511_INT0_EDID_READYBIT(2)
@@ -157,11 +157,11 @@
#define ADV7511_PACKET_ENABLE_SPARE2 BIT(1)
#define ADV7511_PACKET_ENABLE_SPARE1 BIT(0)
-#define ADV7511_REG_POWER2_HDP_SRC_MASK0xc0
-#define ADV7511_REG_POWER2_HDP_SRC_BOTH0x00
-#define ADV7511_REG_POWER2_HDP_SRC_HDP 0x40
-#define ADV7511_REG_POWER2_HDP_SRC_CEC 0x80
-#define ADV7511_REG_POWER2_HDP_SRC_NONE0xc0
+#define ADV7511_REG_POWER2_HPD_SRC_MASK0xc0
+#define ADV7511_REG_POWER2_HPD_SRC_BOTH0x00
+#define ADV7511_REG_POWER2_HPD_SRC_HPD 0x40
+#define ADV7511_REG_POWER2_HPD_SRC_CEC 0x80
+#define ADV7511_REG_POWER2_HPD_SRC_NONE0xc0
#define ADV7511_REG_POWER2_TDMS_ENABLE BIT(4)
#define ADV7511_REG_POWER2_GATE_INPUT_CLK BIT(0)
--
2.1.4
[PATCH RESEND 1/3] drm: adv7511: really enable interrupts for EDID detection
From: Wolfram Sang
The interrupts for EDID_READY or DDC_ERROR were never enabled in this
driver, so reading EDID always timed out when chip was powered down and
interrupts were used. Fix this and remove clearing the interrupt flags,
they are cleared in POWER_DOWN mode anyhow (according to docs and my
tests).
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/i2c/adv7511.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index 00416f23b5cb5f..85e994796d96a4 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -362,12 +362,19 @@ static void adv7511_power_on(struct adv7511 *adv7511)
{
adv7511->current_edid_segment = -1;
- regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
-ADV7511_INT0_EDID_READY);
- regmap_write(adv7511->regmap, ADV7511_REG_INT(1),
-ADV7511_INT1_DDC_ERROR);
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
ADV7511_POWER_POWER_DOWN, 0);
+ if (adv7511->i2c_main->irq) {
+ /*
+* Documentation says the INT_ENABLE registers are reset in
+* POWER_DOWN mode. My tests with a 7511w show something else
+* but let's stick to the documentation.
+*/
+ regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
+ADV7511_INT0_EDID_READY);
+ regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
+ADV7511_INT1_DDC_ERROR);
+ }
/*
* Per spec it is allowed to pulse the HDP signal to indicate that the
@@ -567,12 +574,14 @@ static int adv7511_get_modes(struct drm_encoder *encoder,
/* Reading the EDID only works if the device is powered */
if (!adv7511->powered) {
- regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
-ADV7511_INT0_EDID_READY);
- regmap_write(adv7511->regmap, ADV7511_REG_INT(1),
-ADV7511_INT1_DDC_ERROR);
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
ADV7511_POWER_POWER_DOWN, 0);
+ if (adv7511->i2c_main->irq) {
+ regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
+ADV7511_INT0_EDID_READY);
+ regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
+ADV7511_INT1_DDC_ERROR);
+ }
adv7511->current_edid_segment = -1;
}
--
2.1.4
[PATCH RESEND 2/3] drm: adv7511: mark ADV7511_REG_EDID_READ_CTRL volatile
From: Wolfram Sang This register includes a counter which is decremented by the chip on I2C failures. Also, it is reset when powering down. Signed-off-by: Wolfram Sang --- drivers/gpu/drm/i2c/adv7511.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c index 85e994796d96a4..50a861b12346c4 100644 --- a/drivers/gpu/drm/i2c/adv7511.c +++ b/drivers/gpu/drm/i2c/adv7511.c @@ -136,6 +136,7 @@ static bool adv7511_register_volatile(struct device *dev, unsigned int reg) case ADV7511_REG_BKSV(3): case ADV7511_REG_BKSV(4): case ADV7511_REG_DDC_STATUS: + case ADV7511_REG_EDID_READ_CTRL: case ADV7511_REG_BSTATUS(0): case ADV7511_REG_BSTATUS(1): case ADV7511_REG_CHIP_ID_HIGH: -- 2.1.4
[PATCH v4 REPOST 00/14] ASoC: hdac_hdmi: Add DP & notification support
This patch series adds DP audio and hotplug notification support. On Skylake two DP ports are available and to enable DP on both ports all pins need to be enabled. There is a special vendor widget which need to be programmed to enable all pins and converters. This series adds hotplug notification, read/set constraint based on ELD, enable all pin/cvts, DP1.2, programs the audio infoframe for DP. There is a one to one mapping between converter and stream, so the dais are created based on the no of streams supported on hdmi codec. Even though cvts can be mapped dynamically to the streams, currently it is statically mapped as simultaneous playback on both DP and HDMI is not supported as of now. Pin muxes and controls are created dynamically to map converter to pin widget. So at run time specific pin is mapped to the dai based on the control selected (based on the display type DP/HDMI connected). Finally the DP audio infoframe programming is added to support the DP feature. Also with hotplug notification support, ELD is read and capabilities are set for rate, formats and channels. drm_eld sound/core framework is updated to limit the formats based on ELD. There are few fixes one fixing the static checker warning and other one not to fail if no connection list is found for a pin widget. Pls note, the 10th patch is adding a small macro for getting connection type in drm header, we have CCed drm folks on that and this one. Pls ack so that we can have this series merged thru sound trees changes in v4: - Added NULL check - Dropped the Jack reporting patch for now. Cc: Jani Nikula Cc: David Airlie Cc: dri-devel at lists.freedesktop.org Cc: Daniel Vetter Jeeja KP (2): ASoC: hdac_hdmi: Add codec suspend/resume handler ASoC: hdac_hdmi: Fix to enable device configuration in hw_params Ramesh Babu (1): ASoC: hdac_hdmi: Fix to keep display active while enumerating codec Subhransu S. Prusty (11): ASoC: hdac_hdmi: Fix to check num nodes correctly ASoC: hdac_hdmi: Fix to warn instead of err for no connected nids ASoC: hdac_hdmi: Use list to add pins and converters ASoC: hdac_hdmi: Add hotplug notification and read eld ASoC: hdac_hdmi: Apply constraints based on ELD ASoC: hdac_hdmi: Enable DP1.2 and all converters/pins ASoC: hdac_hdmi: create dais based on number of streams ASoC: hdac_hdmi: Create widget/route based on nodes enumerated ASoC: hdac_hdmi: Assign pin for stream based on dapm connection drm/edid: Add API to help find connection type ASoC: hdac_hdmi: Add infoframe support for dp audio include/drm/drm_edid.h | 12 + sound/soc/codecs/Kconfig |1 + sound/soc/codecs/hdac_hdmi.c | 1116 +++--- 3 files changed, 951 insertions(+), 178 deletions(-) -- 1.9.1
[PATCH v4 REPOST 10/14] drm/edid: Add API to help find connection type
To fill the audio infoframe it is required to identify the
connection type as DP or HDMI. This patch adds an API which
parses ELD and returns the display type of connected.
Signed-off-by: Subhransu S. Prusty
Signed-off-by: Vinod Koul
Reviewed-by: Jani Nikula
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: Daniel Vetter
---
include/drm/drm_edid.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 2af9769..8c537a0 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -403,6 +403,18 @@ static inline int drm_eld_size(const uint8_t *eld)
return DRM_ELD_HEADER_BLOCK_SIZE + eld[DRM_ELD_BASELINE_ELD_LEN] * 4;
}
+/**
+ * drm_eld_get_conn_type - Get device type hdmi/dp connected
+ * @eld: pointer to an eld memory structure
+ *
+ * The caller need to use %DRM_ELD_CONN_TYPE_HDMI or %DRM_ELD_CONN_TYPE_DP to
+ * identify the display type connected.
+ */
+static inline u8 drm_eld_get_conn_type(const uint8_t *eld)
+{
+ return eld[DRM_ELD_SAD_COUNT_CONN_TYPE] & DRM_ELD_CONN_TYPE_MASK;
+}
+
struct edid *drm_do_get_edid(struct drm_connector *connector,
int (*get_edid_block)(void *data, u8 *buf, unsigned int block,
size_t len),
--
1.9.1
[PATCH RESEND 1/3] drm: adv7511: really enable interrupts for EDID detection
On 01/04/2016 08:03 AM, Wolfram Sang wrote:
> From: Wolfram Sang
>
> The interrupts for EDID_READY or DDC_ERROR were never enabled in this
> driver, so reading EDID always timed out when chip was powered down and
> interrupts were used. Fix this and remove clearing the interrupt flags,
> they are cleared in POWER_DOWN mode anyhow (according to docs and my
> tests).
I tried this on adv7533 and it works fine. The other patches look good
too.
Tested-by: Archit Taneja
Thanks,
Archit
>
> Signed-off-by: Wolfram Sang
> ---
> drivers/gpu/drm/i2c/adv7511.c | 25 +
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
> index 00416f23b5cb5f..85e994796d96a4 100644
> --- a/drivers/gpu/drm/i2c/adv7511.c
> +++ b/drivers/gpu/drm/i2c/adv7511.c
> @@ -362,12 +362,19 @@ static void adv7511_power_on(struct adv7511 *adv7511)
> {
> adv7511->current_edid_segment = -1;
>
> - regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
> - ADV7511_INT0_EDID_READY);
> - regmap_write(adv7511->regmap, ADV7511_REG_INT(1),
> - ADV7511_INT1_DDC_ERROR);
> regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
> ADV7511_POWER_POWER_DOWN, 0);
> + if (adv7511->i2c_main->irq) {
> + /*
> + * Documentation says the INT_ENABLE registers are reset in
> + * POWER_DOWN mode. My tests with a 7511w show something else
> + * but let's stick to the documentation.
> + */
> + regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
> + ADV7511_INT0_EDID_READY);
> + regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
> + ADV7511_INT1_DDC_ERROR);
> + }
>
> /*
>* Per spec it is allowed to pulse the HDP signal to indicate that the
> @@ -567,12 +574,14 @@ static int adv7511_get_modes(struct drm_encoder
> *encoder,
>
> /* Reading the EDID only works if the device is powered */
> if (!adv7511->powered) {
> - regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
> - ADV7511_INT0_EDID_READY);
> - regmap_write(adv7511->regmap, ADV7511_REG_INT(1),
> - ADV7511_INT1_DDC_ERROR);
> regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
> ADV7511_POWER_POWER_DOWN, 0);
> + if (adv7511->i2c_main->irq) {
> + regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
> + ADV7511_INT0_EDID_READY);
> + regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
> + ADV7511_INT1_DDC_ERROR);
> + }
> adv7511->current_edid_segment = -1;
> }
>
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, hosted by The Linux Foundation
[PATCH] drm/docs: more leftovers from the big vtable documentation pile
On Mon, Dec 28, 2015 at 11:22:52AM +0100, Thierry Reding wrote:
> On Wed, Dec 16, 2015 at 06:18:25PM +0100, Daniel Vetter wrote:
> > Another pile of vfuncs from the old gpu.tmpl xml documentation that
> > I've forgotten to delete. I spotted a few more things to
> > clarify/extend in the new kerneldoc while going through this once
> > more.
> >
> > Cc: Laurent Pinchart
> > Cc: Thierry Reding
> > Signed-off-by: Daniel Vetter
> > ---
> > Documentation/DocBook/gpu.tmpl | 188
> > ---
> > include/drm/drm_modeset_helper_vtables.h | 28 -
> > 2 files changed, 25 insertions(+), 191 deletions(-)
> >
> > diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> > index a3764291c826..c0fa21c797fe 100644
> > --- a/Documentation/DocBook/gpu.tmpl
> > +++ b/Documentation/DocBook/gpu.tmpl
> > @@ -1579,194 +1579,6 @@ void intel_crt_init(struct drm_device *dev)
> >entities.
> >
> >
> > - Legacy CRTC Helper Operations
> > -
> > -
> > - bool (*mode_fixup)(struct drm_crtc *crtc,
> > - const struct drm_display_mode *mode,
> > - struct drm_display_mode *adjusted_mode);
> > -
> > -Let CRTCs adjust the requested mode or reject it completely.
> > This
> > -operation returns true if the mode is accepted (possibly after
> > being
> > -adjusted) or false if it is rejected.
> > -
> > -
> > -The mode_fixup operation should
> > reject the
> > -mode if it can't reasonably use it. The definition of
> > "reasonable"
> > -is currently fuzzy in this context. One possible behaviour
> > would be
> > -to set the adjusted mode to the panel timings when a fixed-mode
> > -panel is used with hardware capable of scaling. Another
> > behaviour
> > -would be to accept any input mode and adjust it to the closest
> > mode
> > -supported by the hardware (FIXME: This needs to be clarified).
> > -
> > -
>
> I just noticed that this deviates somewhat from what is now in the new
> documentation in include/drm/drm_modeset_helper_vtables.h. The new
> documentation suggests that ->mode_fixup() should not modify
> adjusted_mode but instead reject the mode if the conversion from mode to
> adjusted_mode can't be supported. The new definition sounds much saner
> to me, because if we allowed the CRTC's ->mode_fixup() to modify the
> adjusted_mode, we'd need to make sure that the encoder (and bridge)
> still accept it. And we'd need to potentially reiterate until everybody
> agrees.
Yeah, I simply addressed the FIXME while typing the new docs and made this
a strong recommendation (that's why I picked "should" instead of "must").
There's some drivers (at least i915's TV-out) where the input mode is
massively mangled, but no one will ever fix this.
> > diff --git a/include/drm/drm_modeset_helper_vtables.h
> > b/include/drm/drm_modeset_helper_vtables.h
> > index 29e0dc50031d..b995d5ec50a0 100644
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -131,6 +131,12 @@ struct drm_crtc_helper_funcs {
> > * Atomic drivers which need to inspect and adjust more state should
> > * instead use the @atomic_check callback.
> > *
> > +* Also beware that the core nor helpers filters mode before passing the
>
> "... neither the core nor the helpers filter modes before passing them ..."?
>
> > +* to the driver. More specifically modes rejected by the ->mode_valid
> > +* callback from #drm_connector_helper_funcs can still be requested by
> > +* userspace and therefore also need to be rejected in either this hook,
> > +* or the one in #drm_encoder_helper_funcs.
>
> Hmm... that's odd. Why would one want to allow a mode that the connector
> can't support? Also looking at drm_helper_probe_single_connector_modes()
> this isn't quite true. That helper is used by all connectors except
> vmwgfx. It also calls drm_mode_prune_invalid(), which will remove all
> modes from the connector's mode list that don't have status == MODE_OK.
> As far as I can see after they've been removed from the connector's mode
> list they will no longer be exposed to userspace.
Maybe I need to hammer this in more, but it's a common misconception that
userspace can only ask for modes in the connector list. Generally that's
what's happening, but there's not restrictions on userspace to ask for a
mode which is _not_ in the connector's mode list.
If you don't believe that, look at xrandr --addmode and try yourself.
That's why drivers MUST filter modes in both mode_valid and mode_fixup.
Any suggestions for how to make this even more clear?
Aside, I tried looking into untangling this a bit with a helper to
implement mode_valid in terms of mode_fixup (by just passing a dummy
adjusted_mode in). B
[PATCH] drm/docs: more leftovers from the big vtable documentation pile
Another pile of vfuncs from the old gpu.tmpl xml documentation that I've forgotten to delete. I spotted a few more things to clarify/extend in the new kerneldoc while going through this once more. v2: Spelling fixes (Thierry). Cc: Laurent Pinchart Cc: Thierry Reding Signed-off-by: Daniel Vetter --- Documentation/DocBook/gpu.tmpl | 188 --- include/drm/drm_modeset_helper_vtables.h | 28 - 2 files changed, 25 insertions(+), 191 deletions(-) diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index a3764291c826..c0fa21c797fe 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -1579,194 +1579,6 @@ void intel_crt_init(struct drm_device *dev) entities. - Legacy CRTC Helper Operations - - - bool (*mode_fixup)(struct drm_crtc *crtc, - const struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode); - -Let CRTCs adjust the requested mode or reject it completely. This -operation returns true if the mode is accepted (possibly after being -adjusted) or false if it is rejected. - - -The mode_fixup operation should reject the -mode if it can't reasonably use it. The definition of "reasonable" -is currently fuzzy in this context. One possible behaviour would be -to set the adjusted mode to the panel timings when a fixed-mode -panel is used with hardware capable of scaling. Another behaviour -would be to accept any input mode and adjust it to the closest mode -supported by the hardware (FIXME: This needs to be clarified). - - - - int (*mode_set_base)(struct drm_crtc *crtc, int x, int y, - struct drm_framebuffer *old_fb) - -Move the CRTC on the current frame buffer (stored in -crtc->fb) to position (x,y). Any of the frame -buffer, x position or y position may have been modified. - - -This helper operation is optional. If not provided, the -drm_crtc_helper_set_config function will fall -back to the mode_set helper operation. - - -FIXME: Why are x and y passed as arguments, as they can be accessed -through crtc->x and -crtc->y? - - - - void (*prepare)(struct drm_crtc *crtc); - -Prepare the CRTC for mode setting. This operation is called after -validating the requested mode. Drivers use it to perform -device-specific operations required before setting the new mode. - - - - int (*mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode, -struct drm_display_mode *adjusted_mode, int x, int y, -struct drm_framebuffer *old_fb); - -Set a new mode, position and frame buffer. Depending on the device -requirements, the mode can be stored internally by the driver and -applied in the commit operation, or -programmed to the hardware immediately. - - -The mode_set operation returns 0 on success - or a negative error code if an error occurs. - - - - void (*commit)(struct drm_crtc *crtc); - -Commit a mode. This operation is called after setting the new mode. -Upon return the device must use the new mode and be fully -operational. - - - - - - Encoder Helper Operations - - - bool (*mode_fixup)(struct drm_encoder *encoder, - const struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode); - -Let encoders adjust the requested mode or reject it completely. This -operation returns true if the mode is accepted (possibly after being -adjusted) or false if it is rejected. See the -mode_fixup CRTC helper -operation for an explanation of the allowed adjustments. - - - - void (*prepare)(struct drm_encoder *encoder); - -Prepare the encoder for mode setting. This operation is called after -validating the requested mode. Drivers use it to perform -device-specific operations required before setting the new mode. - - - - void (*mode_set)(struct drm_encoder *encoder, - struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode); - -Set a new mode. Depending on the device requirements, the mode
[PATCH 2/9] drm/gma500: use to_pci_dev()
On Sun, Dec 27, 2015 at 06:45:58PM +0800, Geliang Tang wrote:
> Use to_pci_dev() instead of open-coding it.
>
> Signed-off-by: Geliang Tang
Applied to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/gma500/power.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
> index b6b135f..bea8578 100644
> --- a/drivers/gpu/drm/gma500/power.c
> +++ b/drivers/gpu/drm/gma500/power.c
> @@ -187,7 +187,7 @@ static bool gma_resume_pci(struct pci_dev *pdev)
> */
> int gma_power_suspend(struct device *_dev)
> {
> - struct pci_dev *pdev = container_of(_dev, struct pci_dev, dev);
> + struct pci_dev *pdev = to_pci_dev(_dev);
> struct drm_device *dev = pci_get_drvdata(pdev);
> struct drm_psb_private *dev_priv = dev->dev_private;
>
> @@ -214,7 +214,7 @@ int gma_power_suspend(struct device *_dev)
> */
> int gma_power_resume(struct device *_dev)
> {
> - struct pci_dev *pdev = container_of(_dev, struct pci_dev, dev);
> + struct pci_dev *pdev = to_pci_dev(_dev);
> struct drm_device *dev = pci_get_drvdata(pdev);
>
> mutex_lock(&power_mutex);
> --
> 2.5.0
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
On Wed, Dec 30, 2015 at 12:32:00PM +0200, Tomi Valkeinen wrote: > > > On 30/12/15 11:31, Sebastian Frias wrote: > > Hi, > > > > On 12/30/2015 09:06 AM, Tomi Valkeinen wrote: > >> > >> Also note that I don't want new fbdev drivers into the mainline kernel. > >> You should implement a DRM based driver instead. > >> > > > > Thanks, is there a porting guide to go from fbdev to DRM? > > I don't think you should "port" the driver from fbdev to DRM, as the > frameworks are just so different. You should implement the driver from > scratch. Of course, the bits of code that actually touch the hardware > can possibly be copied directly. > > Kernel docs contain documentation about DRM, but I don't know if there's > really a "how to write a DRM driver" style documentation. There's an > active mailing list and irc channel, though. Laurent Pinchart has a presentation which gives a good overview over drm for display drivers: https://www.youtube.com/watch?v=5uHMpjz68HE DRM docs are at http://dri.freedesktop.org/docs/drm/ (this version is using asciidoc for more pretties, but you can also build it locally with make htmldocs and then look at it in Documentation/DocBook/drm/index.html). > > Does DRM provides a "fbdev" backward compatible API? Would that be > > feasible? > > DRM provides an fbdev "emulation". I think it's mainly aimed at > providing fb console, but many fbdev applications should work fine on > top of it. Modeset side should be full featured out of the box (i.e. you can change modes), drivers have the option to overallocate (to allow the fake page flipping using set_par) and adding 2d accel is possible. > > I did not find much about that. > > > > Currently our stack is something like: > > > >Qt -> eglfs -> Mali -> fbdev -> mem -> output > > (HW) (HW) > > > > We don't control the eglfs/Mali (GPU) part. > > From what I could see, Mali uses DRM with X11 which we do not need > > (note: I'm not a Mali expert and just took a quick look at the code so I > > may be wrong), which could be a problem. > > I'm not familiar with Mali, so I have no idea. > > > If "implement a DRM driver" is a lot of work, it would end up as a > > business decision and probably would not happen. > > True. It's, of course, up to you. If the fbdev driver works fine for you > and provides all the features, and you're happy with it, and there's no > requirement to get the driver to the mainline Linux, there's not much > point in going for a DRM driver. > > > Would you say there are good solid arguments to shake our current stack > > (other than for dusting it off)? > > Fbdev is the legacy framework, hopefully deprecated at some point, and > DRM is the current display framework. So DRM has much more features, is > actively developed, has a community that may help you with your issues, etc. > > From purely technical point of view, it depends on the hardware in > question. If the HW supports hardware overlays and multiple outputs, DRM > supports those fully, whereas fbdev does not. > > I'm not that familiar with the 3D side, but I think that can be > implemented properly with DRM, whereas on fbdev supporting 3D is always > more or less a hack. > > > By the way, does DRM improves 2D acceleration support over fbdev? > > I don't know enough about 2D acceleration to answer that. We've tried in-kernel accel of 2d fbdev ops in i915 and realized it's too much work and pretty pointless. But it's definitely possible to do that, on top of the provided fbdev emulation (e.g. gma500 has some scrolling accel tricks). Otherwise same as 3D really, using the split kernel/userspace driver approach. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/dp/mst: constify drm_dp_mst_topology_cbs structures
On Wed, Dec 30, 2015 at 10:20:30PM +0100, Julia Lawall wrote:
> The drm_dp_mst_topology_cbs structures are never modified, so declare them
> as const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Applied to drm-misc, thanks.
-Daniel
>
> ---
> drivers/gpu/drm/i915/intel_dp_mst.c|2 +-
> drivers/gpu/drm/radeon/radeon_dp_mst.c |2 +-
> include/drm/drm_dp_mst_helper.h|2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 74b5888..b37b859 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -421,7 +421,7 @@ struct drm_dp_payload {
> struct drm_dp_mst_topology_mgr {
>
> struct device *dev;
> - struct drm_dp_mst_topology_cbs *cbs;
> + const struct drm_dp_mst_topology_cbs *cbs;
> int max_dpcd_transaction_bytes;
> struct drm_dp_aux *aux; /* auxch for this topology mgr to use */
> int max_payloads;
> diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
> b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> index 94323f5..8a02225 100644
> --- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
> +++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> @@ -329,7 +329,7 @@ static void radeon_dp_mst_hotplug(struct
> drm_dp_mst_topology_mgr *mgr)
> drm_kms_helper_hotplug_event(dev);
> }
>
> -struct drm_dp_mst_topology_cbs mst_cbs = {
> +const struct drm_dp_mst_topology_cbs mst_cbs = {
> .add_connector = radeon_dp_add_mst_connector,
> .register_connector = radeon_dp_register_mst_connector,
> .destroy_connector = radeon_dp_destroy_mst_connector,
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index e2f515d..fa0dabf 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -534,7 +534,7 @@ static void intel_dp_mst_hotplug(struct
> drm_dp_mst_topology_mgr *mgr)
> drm_kms_helper_hotplug_event(dev);
> }
>
> -static struct drm_dp_mst_topology_cbs mst_cbs = {
> +static const struct drm_dp_mst_topology_cbs mst_cbs = {
> .add_connector = intel_dp_add_mst_connector,
> .register_connector = intel_dp_register_mst_connector,
> .destroy_connector = intel_dp_destroy_mst_connector,
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] vga_switcheroo: Prettify documentation
On Sat, Jan 02, 2016 at 06:47:17PM +0100, Lukas Wunner wrote: > Fix indentation of vga_switcheroo sections in gpu.tmpl. > > Change section type of API documentation from "chapter" to "sect1" > so that the individual functions no longer clutter up the ToC. > Group together under a new "API" chapter. > > Fix wording "heretoforth" -> "henceforth". > > Signed-off-by: Lukas Wunner Applied to drm-misc, thanks. -Daniel > --- > Documentation/DocBook/gpu.tmpl | 40 > > drivers/gpu/vga/vga_switcheroo.c | 2 +- > 2 files changed, 21 insertions(+), 21 deletions(-) > > diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl > index f96a5d4..8e15980 100644 > --- a/Documentation/DocBook/gpu.tmpl > +++ b/Documentation/DocBook/gpu.tmpl > @@ -3631,37 +3631,37 @@ int num_ioctls; > > > Modes of Use > - > -Manual switching and manual power control > + > + Manual switching and manual power control > !Pdrivers/gpu/vga/vga_switcheroo.c Manual switching and manual power control > - > - > -Driver power control > + > + > + Driver power control > !Pdrivers/gpu/vga/vga_switcheroo.c Driver power control > - > + > > > - > -Public functions > + > +API > + > + Public functions > !Edrivers/gpu/vga/vga_switcheroo.c > - > - > - > -Public structures > + > + > + Public structures > !Finclude/linux/vga_switcheroo.h vga_switcheroo_handler > !Finclude/linux/vga_switcheroo.h vga_switcheroo_client_ops > - > - > - > -Public constants > + > + > + Public constants > !Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id > !Finclude/linux/vga_switcheroo.h vga_switcheroo_state > - > - > - > -Private structures > + > + > + Private structures > !Fdrivers/gpu/vga/vga_switcheroo.c vgasr_priv > !Fdrivers/gpu/vga/vga_switcheroo.c vga_switcheroo_client > + > > > !Cdrivers/gpu/vga/vga_switcheroo.c > diff --git a/drivers/gpu/vga/vga_switcheroo.c > b/drivers/gpu/vga/vga_switcheroo.c > index 41edd5a..d64d905 100644 > --- a/drivers/gpu/vga/vga_switcheroo.c > +++ b/drivers/gpu/vga/vga_switcheroo.c > @@ -63,7 +63,7 @@ > * for the inactive GPU.) Also, muxes are often used to cut power to the > * discrete GPU while it is not used. > * > - * DRM drivers register GPUs with vga_switcheroo, these are heretoforth > called > + * DRM drivers register GPUs with vga_switcheroo, these are henceforth called > * clients. The mux is called the handler. Muxless machines also register a > * handler to control the power state of the discrete GPU, its ->switchto > * callback is a no-op for obvious reasons. The discrete GPU is often > equipped > -- > 1.8.5.2 (Apple Git-48) > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 93144] [radeonsi] Alien: Isolation bug
https://bugs.freedesktop.org/show_bug.cgi?id=93144 --- Comment #16 from Tapani Pälli --- (In reply to Luzipher from comment #14) > @Stepan Bakshaev, Comment #13: Well, it's a known issue. There is a video of > the same effects on youtube ( https://www.youtube.com/watch?v=n35hwmN3VmQ ) > that was made shortly after the release. Also the developers said multiple > times it'd need OpenGL 4.3 and especially compute shaders - check Comment #8 > or the posts by Feral employees on the steam forum (for example post 32 from > [FERAL] Edwin here: > http://steamcommunity.com/app/214490/discussions/0/490123938446209677/#p3 ). > I don't think it's a bug if the game wants 4.3 and we only got 4.1, and I > trust the devs if they say it needs compute shaders. Of course it's a bit > strange that it looked better on i965 before they had compute shaders, > according to Tapani Pälli in Comment #12. Yep, I was just guessing there since we did not have compute in extension string at that time .. *but* we did have most of implementation so it is possible that game engine just queried the functions and started using it. When I have time I'll test this again since now we have both compute and tessellation support in place for i965. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/a2c4028b/attachment-0001.html>
[PATCH] drm: powerplay: use div64_s64 instead of do_div
On Fri, Jan 01, 2016 at 02:07:41PM +0100, Arnd Bergmann wrote:
> The newly added code for Fiji creates a correct compiler warning
> about invalid use of the do_div macro:
>
> In file included from powerplay/hwmgr/ppatomctrl.c:31:0:
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppevvmath.h: In function
> 'fDivide':
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppevvmath.h:382:89: warning:
> comparison of distinct pointer types lacks a cast
> do_div(longlongX, longlongY); /*Q(32,32) divided by Q(16,16) = Q(16,16)
> Back to original format */
>
> do_div() divides an unsigned 64-bit number by an unsigned 32-bit number.
> The code instead wants to divide two signed 64-bit numbers, which is done
> using the div64_s64 function.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 770911a3cfbb ("drm/amd/powerplay: add/update headers for Fiji SMU and
> DPM")
> ---
> Found on ARM allmodconfig on yesterday's linux-next
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/545a939c/attachment.sig>
[PATCH 4/3] drm: arm-hdlcd: add explictit DRM dependency
On Fri, Jan 01, 2016 at 11:04:07PM +0100, Arnd Bergmann wrote: > CONFIG_DRM_HDLCD is a tristate option that depends on the boolean > CONFIG_DRM_ARM, which in turn depends on the tristate CONFIG_DRM. > The effect of this is that a configuration with CONFIG_DRM=m > and CONFIG_DRM_HDLCD=y can be chosen, but won't link because the > DRM core symbols are not reachable from builtin code: > > drivers/built-in.o: In function `hdlcd_drm_unbind': > drivers/gpu/drm/arm/hdlcd_drv.c:445: undefined reference to > `drm_fbdev_cma_fini' > drivers/gpu/drm/arm/hdlcd_drv.c:448: undefined reference to > `drm_kms_helper_poll_fini' > drivers/gpu/drm/arm/hdlcd_drv.c:450: undefined reference to > `drm_vblank_cleanup' > drivers/gpu/drm/arm/hdlcd_drv.c:452: undefined reference to > `drm_irq_uninstall' > drivers/gpu/drm/arm/hdlcd_drv.c:460: undefined reference to > `drm_mode_config_cleanup' > drivers/gpu/drm/arm/hdlcd_drv.c:461: undefined reference to > `drm_dev_unregister' > drivers/gpu/drm/arm/hdlcd_drv.c:462: undefined reference to `drm_dev_unref' > ... > > This adds another dependency on CONFIG_DRM to enforce that DRM_HDLCD > cannot be builtin if DRM is not. Ugh... wouldn't it be much simpler to get rid of DRM_ARM? It seems like a completely superfluous option to me. I don't think we've ever had the equivalent of "vendor" Kconfig options in DRM, and I don't see why we'd need to start now. If ARM was going to add another driver it can simply have a separate Kconfig entry. There should be no need to select the vendor option first. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/2937e3ba/attachment.sig>
[PATCH 3/3] drm: arm-hdlcd: fix build warnings for !CONFIG_PM
On Fri, Jan 01, 2016 at 03:39:17PM +0100, Arnd Bergmann wrote: > The hdlcd_pm_suspend and hdlcd_pm_resume are intentionally unused > when CONFIG_PM is not set in this driver, and we get a compiler warning > for this: > > drivers/gpu/drm/arm/hdlcd_drv.c:521:12: warning: 'hdlcd_pm_suspend' defined > but not used [-Wunused-function] > drivers/gpu/drm/arm/hdlcd_drv.c:536:12: warning: 'hdlcd_pm_resume' defined > but not used [-Wunused-function] > > This adds a __maybe_unused annotation for the two functions, to let > the compiler know this is the intended behavior. This is better than > an #ifdef as it improves the compile time coverage of the code and it > looks nicer. > > Signed-off-by: Arnd Bergmann Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/9e2bae63/attachment.sig>
[PATCH 2/3] drm: arm-hdlcd: remove COMMON_CLK_SCPI select
On Fri, Jan 01, 2016 at 03:38:53PM +0100, Arnd Bergmann wrote: > The hdlcd driver has no build-time dependency on the SCPI clock > and the bogus 'select' causes a warning when SCPI is disabled: > > warning: (DRM_HDLCD) selects COMMON_CLK_SCPI which has unmet direct > dependencies (COMMON_CLK && (ARM_SCPI_PROTOCOL || COMPILE_TEST)) > > This removes the select statement. > > Signed-off-by: Arnd Bergmann > --- > Found two more bugs in the same driver, so this is now a patch series Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/109467e9/attachment.sig>
[PATCH] drm: arm-hdlcd: remove DMA_CMA select
On Fri, Jan 01, 2016 at 03:09:10PM +0100, Arnd Bergmann wrote:
> The newly added DRM_HDLCD driver tries to select DMA_CMA, but that is
> not necessarily possible, as not all configurations contain
> HAVE_DMA_CONTIGUOUS:
>
> warning: (DRM_HDLCD) selects DMA_CMA which has unmet direct dependencies
> (HAVE_DMA_CONTIGUOUS && CMA)
> drivers/built-in.o: In function `dma_alloc_from_contiguous':
> :(.text+0x1dee00): undefined reference to `cma_alloc'
> drivers/built-in.o: In function `dma_release_from_contiguous':
> :(.text+0x1dee24): undefined reference to `cma_release'
>
> This removes the 'select' statement. It is not needed because CMA is meant
> to transparently change the behavior of dma_alloc_coherent to make it succeed
> for larger allocations, but there is no actual build-time dependency, and
> the driver can still work without CMA in many cases.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 1561e558334d ("drm: Add support for ARM's HDLCD controller.")
> ---
> Found on ARM randconfig builds with yesterday's linux-next
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/e10f1e0d/attachment.sig>
[PATCH] tests/kms-steal-crtc: Include sys/select.h
On Wed, Dec 30, 2015 at 07:51:55AM +, Khem Raj wrote: > Fixes errors e.g. > > error: implicit declaration of function 'select' > > and missing definitions of FD_* defines > > Signed-off-by: Khem Raj > --- > tests/kms/kms-steal-crtc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/kms/kms-steal-crtc.c b/tests/kms/kms-steal-crtc.c > index 2f7f327..24d70ab 100644 > --- a/tests/kms/kms-steal-crtc.c > +++ b/tests/kms/kms-steal-crtc.c > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include This must be pulled in some other way on my system, but this looks correct: Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/e3f36a8e/attachment.sig>
[PATCH 4/3] drm: arm-hdlcd: add explictit DRM dependency
On Monday 04 January 2016 09:24:16 Thierry Reding wrote: > > Ugh... wouldn't it be much simpler to get rid of DRM_ARM? It seems like > a completely superfluous option to me. I don't think we've ever had the > equivalent of "vendor" Kconfig options in DRM, and I don't see why we'd > need to start now. If ARM was going to add another driver it can simply > have a separate Kconfig entry. There should be no need to select the > vendor option first. Fine with me too. I vaguely remembered having seen some discussion about this, so I decided to do a minimal fix, but I agree that would be more in line with the other drivers. Arnd
[PATCH] tests/kms-steal-crtc: Include sys/select.h
On 4 January 2016 at 08:38, Thierry Reding wrote: > On Wed, Dec 30, 2015 at 07:51:55AM +, Khem Raj wrote: >> Fixes errors e.g. >> >> error: implicit declaration of function 'select' >> >> and missing definitions of FD_* defines >> >> Signed-off-by: Khem Raj >> --- >> tests/kms/kms-steal-crtc.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/tests/kms/kms-steal-crtc.c b/tests/kms/kms-steal-crtc.c >> index 2f7f327..24d70ab 100644 >> --- a/tests/kms/kms-steal-crtc.c >> +++ b/tests/kms/kms-steal-crtc.c >> @@ -31,6 +31,7 @@ >> #include >> #include >> #include >> +#include > > This must be pulled in some other way on my system, but this looks > correct: > The above header is required/used in compliance with POSIX 2001/2008. Earlier standards use the below three. #include #include #include I'm not sure how much we should care about platforms non-compliant to POSIX 2001... although adding the header check seems pretty trivial. Add the new one in the list at configure.ac:AC_CHECK_HEADERS and wrap the include in a ifdef guard. >From a quick grep there are a few other users of select() tests/kms/kms-steal-crtc.c tests/kms/kms-universal-planes.c tests/modetest/modetest.c tests/vbltest/vbltest.c Raj, can you update the patch to handle the lot (one patch should be ok imho) ? Thanks Emil
[PATCH 1/3] drm: Balance error path for GEM handle allocation
The current error path for failure when establishing a handle for a GEM
object is unbalance, e.g. we call object_close() without calling first
object_open(). Use the typical onion structure to only undo what has
been set up prior to the error.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_gem.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 2e10bba4468b..a08176debc0e 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -343,27 +343,32 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
spin_unlock(&file_priv->table_lock);
idr_preload_end();
mutex_unlock(&dev->object_name_lock);
- if (ret < 0) {
- drm_gem_object_handle_unreference_unlocked(obj);
- return ret;
- }
+ if (ret < 0)
+ goto err_unref;
+
*handlep = ret;
ret = drm_vma_node_allow(&obj->vma_node, file_priv->filp);
- if (ret) {
- drm_gem_handle_delete(file_priv, *handlep);
- return ret;
- }
+ if (ret)
+ goto err_remove;
if (dev->driver->gem_open_object) {
ret = dev->driver->gem_open_object(obj, file_priv);
- if (ret) {
- drm_gem_handle_delete(file_priv, *handlep);
- return ret;
- }
+ if (ret)
+ goto err_revoke;
}
return 0;
+
+err_revoke:
+ drm_vma_node_revoke(&obj->vma_node, file_priv->filp);
+err_remove:
+ spin_lock(&file_priv->table_lock);
+ idr_remove(&file_priv->object_idr, *handlep);
+ spin_unlock(&file_priv->table_lock);
+err_unref:
+ drm_gem_object_handle_unreference_unlocked(obj);
+ return ret;
}
/**
--
2.6.4
[PATCH 2/3] drm: Only bump object-reference count when adding first handle
We only need a single reference count for all handles (i.e. non-zero
obj->handle_count) and so can trim a few atomic operations by only
taking the reference on the first handle and dropping it after the last.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_gem.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index a08176debc0e..ad955d7c99fd 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -220,6 +220,9 @@ static void drm_gem_object_exported_dma_buf_free(struct
drm_gem_object *obj)
static void
drm_gem_object_handle_unreference_unlocked(struct drm_gem_object *obj)
{
+ struct drm_device *dev = obj->dev;
+ bool final = false;
+
if (WARN_ON(obj->handle_count == 0))
return;
@@ -229,14 +232,16 @@ drm_gem_object_handle_unreference_unlocked(struct
drm_gem_object *obj)
* checked for a name
*/
- mutex_lock(&obj->dev->object_name_lock);
+ mutex_lock(&dev->object_name_lock);
if (--obj->handle_count == 0) {
drm_gem_object_handle_free(obj);
drm_gem_object_exported_dma_buf_free(obj);
+ final = true;
}
- mutex_unlock(&obj->dev->object_name_lock);
+ mutex_unlock(&dev->object_name_lock);
- drm_gem_object_unreference_unlocked(obj);
+ if (final)
+ drm_gem_object_unreference_unlocked(obj);
}
/**
@@ -329,6 +334,8 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
int ret;
WARN_ON(!mutex_is_locked(&dev->object_name_lock));
+ if (obj->handle_count++ == 0)
+ drm_gem_object_reference(obj);
/*
* Get the user-visible handle using idr. Preload and perform
@@ -338,10 +345,10 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
spin_lock(&file_priv->table_lock);
ret = idr_alloc(&file_priv->object_idr, obj, 1, 0, GFP_NOWAIT);
- drm_gem_object_reference(obj);
- obj->handle_count++;
+
spin_unlock(&file_priv->table_lock);
idr_preload_end();
+
mutex_unlock(&dev->object_name_lock);
if (ret < 0)
goto err_unref;
--
2.6.4
[PATCH 3/3] drm: Use a normal idr allocation for the obj->name
Unlike the handle, the name table uses a sleeping mutex rather than a
spinlock. The allocation is in a normal context, and we can use the
simpler sleeping gfp_t, rather than have to take from the atomic
reserves.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_gem.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index ad955d7c99fd..1b0c2c127072 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -642,7 +642,6 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
return -ENOENT;
mutex_lock(&dev->object_name_lock);
- idr_preload(GFP_KERNEL);
/* prevent races with concurrent gem_close. */
if (obj->handle_count == 0) {
ret = -ENOENT;
@@ -650,7 +649,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
}
if (!obj->name) {
- ret = idr_alloc(&dev->object_name_idr, obj, 1, 0, GFP_NOWAIT);
+ ret = idr_alloc(&dev->object_name_idr, obj, 1, 0, GFP_KERNEL);
if (ret < 0)
goto err;
@@ -661,7 +660,6 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
ret = 0;
err:
- idr_preload_end();
mutex_unlock(&dev->object_name_lock);
drm_gem_object_unreference_unlocked(obj);
return ret;
--
2.6.4
[PATCH 1/3] drm: Balance error path for GEM handle allocation
On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote:
> The current error path for failure when establishing a handle for a GEM
> object is unbalance, e.g. we call object_close() without calling first
> object_open(). Use the typical onion structure to only undo what has
> been set up prior to the error.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/drm_gem.c | 29 +
> 1 file changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 2e10bba4468b..a08176debc0e 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -343,27 +343,32 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
> spin_unlock(&file_priv->table_lock);
> idr_preload_end();
> mutex_unlock(&dev->object_name_lock);
> - if (ret < 0) {
> - drm_gem_object_handle_unreference_unlocked(obj);
> - return ret;
> - }
> + if (ret < 0)
> + goto err_unref;
> +
> *handlep = ret;
>
> ret = drm_vma_node_allow(&obj->vma_node, file_priv->filp);
> - if (ret) {
> - drm_gem_handle_delete(file_priv, *handlep);
> - return ret;
> - }
> + if (ret)
> + goto err_remove;
>
> if (dev->driver->gem_open_object) {
> ret = dev->driver->gem_open_object(obj, file_priv);
> - if (ret) {
> - drm_gem_handle_delete(file_priv, *handlep);
> - return ret;
> - }
> + if (ret)
> + goto err_revoke;
> }
>
> return 0;
> +
> +err_revoke:
> + drm_vma_node_revoke(&obj->vma_node, file_priv->filp);
> +err_remove:
> + spin_lock(&file_priv->table_lock);
> + idr_remove(&file_priv->object_idr, *handlep);
For bonus points, we could *handlep = 0; here.
> + spin_unlock(&file_priv->table_lock);
> +err_unref:
> + drm_gem_object_handle_unreference_unlocked(obj);
> + return ret;
> }
--
Chris Wilson, Intel Open Source Technology Centre
[Bug 93374] [radeonsi] Tonga (Radeon R9 380) hangs on running hello world OpenCL program
https://bugs.freedesktop.org/show_bug.cgi?id=93374 --- Comment #4 from EoD --- After upgrading to current llvm 3.8-git (2921ff9ffcfd09db1c), the program ran fine: $ ./clpeak Platform: Clover Device: AMD TONGA (DRM 3.1.0, LLVM 3.8.0) Driver version : 11.2.0-devel (Linux x64) Compute units : 32 Clock frequency : 0 MHz Global memory bandwidth (GBPS) float : 100.53 float2 : 112.67 float4 : 105.17 float8 : 104.72 float16 : 69.72 Single-precision compute (GFLOPS) float : 4006.34 float2 : 4039.47 float4 : 4030.48 float8 : 4007.96 float16 : 3973.85 Double-precision compute (GFLOPS) double : 265.21 double2 : 265.09 double4 : 264.79 double8 : 264.05 double16 : 263.11 Integer compute (GIOPS) int : 841.70 int2 : 841.59 int4 : 841.39 int8 : 841.17 int16 : 840.63 Transfer bandwidth (GBPS) enqueueWriteBuffer : 2.57 enqueueReadBuffer : 1.92 enqueueMapBuffer(for read) : 1813.75 memcpy from mapped ptr : 1.92 enqueueUnmap(after write) : 1545.40 memcpy to mapped ptr : 1.92 Kernel launch latency : 267.44 us -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/1c7a8248/attachment.html>
[Bug 93575] Unigine Heaven shows unexpected light stripes
https://bugs.freedesktop.org/show_bug.cgi?id=93575 Bug ID: 93575 Summary: Unigine Heaven shows unexpected light stripes Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: marvin24 at gmx.de QA Contact: dri-devel at lists.freedesktop.org Created attachment 120790 --> https://bugs.freedesktop.org/attachment.cgi?id=120790&action=edit screencast showing the unexpected light source This is on an RS880 (HD4200). DRM/DDX/MESA from git. LLVMPIPE works fine. See attached vid. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/92f74686/attachment.html>
[Bug 93575] Unigine Heaven shows unexpected light stripes
https://bugs.freedesktop.org/show_bug.cgi?id=93575 --- Comment #1 from Marc Dietrich --- This is on an RS880 (HD4200). DRM/DDX/MESA from git. LLVMPIPE works fine. See attached vid. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/0f8380ad/attachment-0001.html>
[PATCH] drm/radeon: Update radeon_get_vblank_counter_kms()
On Thu, Dec 17, 2015 at 03:35:50PM +0900, Michel Dänzer wrote:
> On 16.12.2015 23:31, Thierry Reding wrote:
> >
> > - if (crtc < 0 || crtc >= rdev->num_crtc) {
> > - DRM_ERROR("Invalid crtc %d\n", crtc);
> > + if (pipe < 0 || pipe >= rdev->num_crtc) {
> > + DRM_ERROR("Invalid crtc %u\n", pipe);
>
> Does it still make sense to test for < 0? Doesn't that generate a
> compiler warning?
I didn't see a compiler warning in my build tests, but you're right,
it's not necessary to check for that because it can't be true. I'll
respin with that fixed up.
> Also, I don't really get the point of the crtc => pipe rename here...
This is primarily for consistency. That way we can reserve "pipe" for
the unsigned integers that denote the DRM index of the CRTC, and keep
"crtc" for cases where we deal with struct drm_crtc objects.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/e9866ab8/attachment.sig>
[RFC PATCH v1 0/2] Add RK3229 vop support
Add RK3229 vop support Yakir Yang (2): drm/rockchip: vop: add rk3229 vop support dt-bindings: add document for rk3229-vop .../bindings/display/rockchip/rockchip-vop.txt | 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 7 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.h| 2 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c| 120 + drivers/gpu/drm/rockchip/rockchip_vop_reg.h| 90 5 files changed, 218 insertions(+), 2 deletions(-) -- 1.9.1
[RFC PATCH v1 1/2] drm/rockchip: vop: add rk3229 vop support
RK3228 registers layout is simalar to RK3288 layout, only the
interruput registers is different to RK3288.
RK3228 support two overlay plane and one hwc plane, max output
resolution is 4K. it support IOMMU, and its IOMMU same as rk3288's.
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 120
drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 90 +
4 files changed, 217 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index d83bf87..3c83097 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -63,9 +63,12 @@
#define VOP_INTR_SET_TYPE(vop, name, type, v) \
do { \
int i, reg = 0; \
- for (i = 0; i < vop->data->intr->nintrs; i++) { \
- if (vop->data->intr->intrs[i] & type) \
+ const struct vop_intr *intr = vop->data->intr; \
+ for (i = 0; i < intr->nintrs; i++) { \
+ if (intr->intrs[i] & type) { \
reg |= (v) << i; \
+ reg |= intr->write_mask ? (1 << (i + 16)) : 0; \
+ } \
} \
VOP_INTR_SET(vop, name, reg); \
} while (0)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 071ff0b..1e839e8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -60,6 +60,7 @@ struct vop_ctrl {
};
struct vop_intr {
+ bool write_mask;
const int *intrs;
uint32_t nintrs;
struct vop_reg enable;
@@ -136,6 +137,7 @@ struct vop_data {
};
/* interrupt define */
+#define DUMMY_INTR (0 << 0)
#define DSP_HOLD_VALID_INTR(1 << 0)
#define FS_INTR(1 << 1)
#define LINE_FLAG_INTR (1 << 2)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 3166b46..bbcd128 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -174,6 +174,7 @@ static const int rk3288_vop_intrs[] = {
};
static const struct vop_intr rk3288_vop_intr = {
+ .write_mask = false,
.intrs = rk3288_vop_intrs,
.nintrs = ARRAY_SIZE(rk3288_vop_intrs),
.status = VOP_REG(RK3288_INTR_CTRL0, 0xf, 0),
@@ -190,6 +191,122 @@ static const struct vop_data rk3288_vop = {
.win_size = ARRAY_SIZE(rk3288_vop_win_data),
};
+static const struct vop_scl_extension rk3229_win_full_scl_ext = {
+ .cbcr_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 31),
+ .cbcr_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 30),
+ .cbcr_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 28),
+ .cbcr_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 26),
+ .cbcr_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 24),
+ .yrgb_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 23),
+ .yrgb_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 22),
+ .yrgb_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 20),
+ .yrgb_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 18),
+ .yrgb_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 16),
+ .line_load_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 15),
+ .cbcr_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0x7, 12),
+ .yrgb_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0xf, 8),
+ .vsd_cbcr_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 7),
+ .vsd_cbcr_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 6),
+ .vsd_yrgb_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 5),
+ .vsd_yrgb_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 4),
+ .bic_coe_sel = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 2),
+ .cbcr_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 1),
+ .yrgb_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 0),
+ .lb_mode = VOP_REG(RK3229_WIN0_CTRL0, 0x7, 5),
+};
+
+static const struct vop_scl_regs rk3229_win_full_scl = {
+ .ext = &rk3229_win_full_scl_ext,
+ .scale_yrgb_x = VOP_REG(RK3229_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
+ .scale_yrgb_y = VOP_REG(RK3229_WIN0_SCL_FACTOR_YRGB, 0x, 16),
+ .scale_cbcr_x = VOP_REG(RK3229_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
+ .scale_cbcr_y = VOP_REG(RK3229_WIN0_SCL_FACTOR_CBR, 0x, 16),
+};
+
+static const struct vop_win_phy rk3229_win01_data = {
+ .scl = &rk3229_win_full_scl,
+ .data_formats = formats_win_full,
+ .nformats = ARRAY_SIZE(formats_win_full),
+ .enable = VOP_REG(RK3229_WIN0_CTRL0, 0x1, 0),
+ .format = VOP_REG(RK3229_WIN0_CTRL0, 0x7, 1),
+ .rb_swap = VOP_REG(RK3229_WIN0_CTRL0, 0x1, 12),
+ .act_info = VOP_REG(RK3229_WIN0_ACT_INFO, 0x1fff1f
[RFC PATCH v1 2/2] dt-bindings: add document for rk3229-vop
Signed-off-by: Yakir Yang --- Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt index 5489b59..75ebc20 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt @@ -7,6 +7,7 @@ buffer to an external LCD interface. Required properties: - compatible: value should be one of the following "rockchip,rk3288-vop"; + "rockchip,rk3229-vop"; "rockchip,rk3036-vop"; - interrupts: should contain a list of all VOP IP block interrupts in the -- 1.9.1
[RFC PATCH v1 1/2] drm/rockchip: vop: add rk3229 vop support
RK3229 registers layout is simalar to RK3288 layout, only the
interruput registers is different to RK3288.
RK3229 support two overlay plane and one hwc plane, max output
resolution is 4K. it support IOMMU, and its IOMMU same as rk3288's.
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 120
drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 90 +
4 files changed, 217 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index d83bf87..3c83097 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -63,9 +63,12 @@
#define VOP_INTR_SET_TYPE(vop, name, type, v) \
do { \
int i, reg = 0; \
- for (i = 0; i < vop->data->intr->nintrs; i++) { \
- if (vop->data->intr->intrs[i] & type) \
+ const struct vop_intr *intr = vop->data->intr; \
+ for (i = 0; i < intr->nintrs; i++) { \
+ if (intr->intrs[i] & type) { \
reg |= (v) << i; \
+ reg |= intr->write_mask ? (1 << (i + 16)) : 0; \
+ } \
} \
VOP_INTR_SET(vop, name, reg); \
} while (0)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 071ff0b..1e839e8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -60,6 +60,7 @@ struct vop_ctrl {
};
struct vop_intr {
+ bool write_mask;
const int *intrs;
uint32_t nintrs;
struct vop_reg enable;
@@ -136,6 +137,7 @@ struct vop_data {
};
/* interrupt define */
+#define DUMMY_INTR (0 << 0)
#define DSP_HOLD_VALID_INTR(1 << 0)
#define FS_INTR(1 << 1)
#define LINE_FLAG_INTR (1 << 2)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 3166b46..bbcd128 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -174,6 +174,7 @@ static const int rk3288_vop_intrs[] = {
};
static const struct vop_intr rk3288_vop_intr = {
+ .write_mask = false,
.intrs = rk3288_vop_intrs,
.nintrs = ARRAY_SIZE(rk3288_vop_intrs),
.status = VOP_REG(RK3288_INTR_CTRL0, 0xf, 0),
@@ -190,6 +191,122 @@ static const struct vop_data rk3288_vop = {
.win_size = ARRAY_SIZE(rk3288_vop_win_data),
};
+static const struct vop_scl_extension rk3229_win_full_scl_ext = {
+ .cbcr_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 31),
+ .cbcr_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 30),
+ .cbcr_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 28),
+ .cbcr_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 26),
+ .cbcr_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 24),
+ .yrgb_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 23),
+ .yrgb_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 22),
+ .yrgb_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 20),
+ .yrgb_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 18),
+ .yrgb_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 16),
+ .line_load_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 15),
+ .cbcr_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0x7, 12),
+ .yrgb_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0xf, 8),
+ .vsd_cbcr_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 7),
+ .vsd_cbcr_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 6),
+ .vsd_yrgb_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 5),
+ .vsd_yrgb_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 4),
+ .bic_coe_sel = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 2),
+ .cbcr_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 1),
+ .yrgb_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 0),
+ .lb_mode = VOP_REG(RK3229_WIN0_CTRL0, 0x7, 5),
+};
+
+static const struct vop_scl_regs rk3229_win_full_scl = {
+ .ext = &rk3229_win_full_scl_ext,
+ .scale_yrgb_x = VOP_REG(RK3229_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
+ .scale_yrgb_y = VOP_REG(RK3229_WIN0_SCL_FACTOR_YRGB, 0x, 16),
+ .scale_cbcr_x = VOP_REG(RK3229_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
+ .scale_cbcr_y = VOP_REG(RK3229_WIN0_SCL_FACTOR_CBR, 0x, 16),
+};
+
+static const struct vop_win_phy rk3229_win01_data = {
+ .scl = &rk3229_win_full_scl,
+ .data_formats = formats_win_full,
+ .nformats = ARRAY_SIZE(formats_win_full),
+ .enable = VOP_REG(RK3229_WIN0_CTRL0, 0x1, 0),
+ .format = VOP_REG(RK3229_WIN0_CTRL0, 0x7, 1),
+ .rb_swap = VOP_REG(RK3229_WIN0_CTRL0, 0x1, 12),
+ .act_info = VOP_REG(RK3229_WIN0_ACT_INFO, 0x1fff1f
[RFC PATCH v1 1/2] drm/rockchip: vop: add rk3229 vop support
Sorry, there shouldn't have the "3228" prefix,
%s/3228/3229
I have send the new patch out, please ignore this one.
Thanks,
- Yakir
On 01/04/2016 07:50 PM, Yakir Yang wrote:
> RK3228 registers layout is simalar to RK3288 layout, only the
> interruput registers is different to RK3288.
>
> RK3228 support two overlay plane and one hwc plane, max output
> resolution is 4K. it support IOMMU, and its IOMMU same as rk3288's.
>
> Signed-off-by: Yakir Yang
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +-
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 120
>
> drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 90 +
> 4 files changed, 217 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index d83bf87..3c83097 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -63,9 +63,12 @@
> #define VOP_INTR_SET_TYPE(vop, name, type, v) \
> do { \
> int i, reg = 0; \
> - for (i = 0; i < vop->data->intr->nintrs; i++) { \
> - if (vop->data->intr->intrs[i] & type) \
> + const struct vop_intr *intr = vop->data->intr; \
> + for (i = 0; i < intr->nintrs; i++) { \
> + if (intr->intrs[i] & type) { \
> reg |= (v) << i; \
> + reg |= intr->write_mask ? (1 << (i + 16)) : 0; \
> + } \
> } \
> VOP_INTR_SET(vop, name, reg); \
> } while (0)
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> index 071ff0b..1e839e8 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> @@ -60,6 +60,7 @@ struct vop_ctrl {
> };
>
> struct vop_intr {
> + bool write_mask;
> const int *intrs;
> uint32_t nintrs;
> struct vop_reg enable;
> @@ -136,6 +137,7 @@ struct vop_data {
> };
>
> /* interrupt define */
> +#define DUMMY_INTR (0 << 0)
> #define DSP_HOLD_VALID_INTR (1 << 0)
> #define FS_INTR (1 << 1)
> #define LINE_FLAG_INTR (1 << 2)
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> index 3166b46..bbcd128 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> @@ -174,6 +174,7 @@ static const int rk3288_vop_intrs[] = {
> };
>
> static const struct vop_intr rk3288_vop_intr = {
> + .write_mask = false,
> .intrs = rk3288_vop_intrs,
> .nintrs = ARRAY_SIZE(rk3288_vop_intrs),
> .status = VOP_REG(RK3288_INTR_CTRL0, 0xf, 0),
> @@ -190,6 +191,122 @@ static const struct vop_data rk3288_vop = {
> .win_size = ARRAY_SIZE(rk3288_vop_win_data),
> };
>
> +static const struct vop_scl_extension rk3229_win_full_scl_ext = {
> + .cbcr_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 31),
> + .cbcr_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 30),
> + .cbcr_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 28),
> + .cbcr_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 26),
> + .cbcr_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 24),
> + .yrgb_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 23),
> + .yrgb_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 22),
> + .yrgb_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 20),
> + .yrgb_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 18),
> + .yrgb_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 16),
> + .line_load_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 15),
> + .cbcr_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0x7, 12),
> + .yrgb_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0xf, 8),
> + .vsd_cbcr_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 7),
> + .vsd_cbcr_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 6),
> + .vsd_yrgb_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 5),
> + .vsd_yrgb_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 4),
> + .bic_coe_sel = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 2),
> + .cbcr_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 1),
> + .yrgb_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 0),
> + .lb_mode = VOP_REG(RK3229_WIN0_CTRL0, 0x7, 5),
> +};
> +
> +static const struct vop_scl_regs rk3229_win_full_scl = {
> + .ext = &rk3229_win_full_scl_ext,
> + .scale_yrgb_x = VOP_REG(RK3229_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
> + .scale_yrgb_y = VOP_REG(RK3229_WIN0_SCL_FACTOR_YRGB, 0x, 16),
> + .scale_cbcr_x = VOP_REG(RK3229_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
> + .scale_cbcr_y = VOP_REG(RK3229_WIN0_SCL_FACTOR_CBR, 0x, 16),
> +};
> +
> +static const struct vop_win_phy rk3229_win01_data = {
> + .scl = &rk3229_win_full_scl
[PATCH] drm/exynos: fix kernel panic issue at drm releasing
Hi Daniel,
2015ë
12ì 24ì¼ 22:32ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> On 24 December 2015 at 09:10, Inki Dae wrote:
>> +void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc)
>> +{
>> + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&crtc->dev->event_lock, flags);
>> + exynos_crtc->event = NULL;
>> + spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
>> +}
>
> This will leak the event and event space; you should call
> event->base.destroy() here. With that fixed:
Right. we don't use exynos specific page flip function anymore which managed
the event as a list so that the event objects can be freed by postclose
callback.
Anyway, would it be better for event->base.destory() to be called between spin
lock/unlock?
Thanks,
Inki Dae
> Reviewed-by: Daniel Stone
>
> Cheers,
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
[PATCH v2 2/6] drm/atomic: Add __drm_atomic_helper_connector_reset, v2.
This is useful for drivers that subclass connector_state, like tegra.
Changes since v1:
- Docbook updates.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 30 ++
include/drm/drm_atomic_helper.h | 2 ++
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 63f925b75357..27dd68f946e6 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2607,6 +2607,28 @@ void drm_atomic_helper_plane_destroy_state(struct
drm_plane *plane,
EXPORT_SYMBOL(drm_atomic_helper_plane_destroy_state);
/**
+ * __drm_atomic_helper_connector_reset - reset state on connector
+ * @connector: drm connector
+ * @conn_state: connector state to assign
+ *
+ * Initializes the newly allocated @conn_state and assigns it to
+ * #connector ->state, usually required when initializing the drivers
+ * or when called from the ->reset hook.
+ *
+ * This is useful for drivers that subclass the connector state.
+ */
+void
+__drm_atomic_helper_connector_reset(struct drm_connector *connector,
+ struct drm_connector_state *conn_state)
+{
+ if (conn_state)
+ conn_state->connector = connector;
+
+ connector->state = conn_state;
+}
+EXPORT_SYMBOL(__drm_atomic_helper_connector_reset);
+
+/**
* drm_atomic_helper_connector_reset - default ->reset hook for connectors
* @connector: drm connector
*
@@ -2616,11 +2638,11 @@ EXPORT_SYMBOL(drm_atomic_helper_plane_destroy_state);
*/
void drm_atomic_helper_connector_reset(struct drm_connector *connector)
{
- kfree(connector->state);
- connector->state = kzalloc(sizeof(*connector->state), GFP_KERNEL);
+ struct drm_connector_state *conn_state =
+ kzalloc(sizeof(*conn_state), GFP_KERNEL);
- if (connector->state)
- connector->state->connector = connector;
+ kfree(connector->state);
+ __drm_atomic_helper_connector_reset(connector, conn_state);
}
EXPORT_SYMBOL(drm_atomic_helper_connector_reset);
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index a286cce98720..89d008dc08e2 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -126,6 +126,8 @@ void __drm_atomic_helper_plane_destroy_state(struct
drm_plane *plane,
void drm_atomic_helper_plane_destroy_state(struct drm_plane *plane,
struct drm_plane_state *state);
+void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
+struct drm_connector_state
*conn_state);
void drm_atomic_helper_connector_reset(struct drm_connector *connector);
void
__drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector,
--
2.1.0
[PATCH v2 3/6] drm/tegra: Use __drm_atomic_helper_reset_connector for subclassing connector state, v2.
Changes since v1:
- Do not reset if state allocation fails.
Signed-off-by: Maarten Lankhorst
Acked-by: Thierry Reding #irc
---
drivers/gpu/drm/tegra/dsi.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index 50d46ae3786b..44e102799195 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -745,14 +745,13 @@ static void tegra_dsi_soft_reset(struct tegra_dsi *dsi)
static void tegra_dsi_connector_reset(struct drm_connector *connector)
{
- struct tegra_dsi_state *state;
-
- kfree(connector->state);
- connector->state = NULL;
+ struct tegra_dsi_state *state =
+ kzalloc(sizeof(*state), GFP_KERNEL);
- state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (state)
- connector->state = &state->base;
+ if (state) {
+ kfree(connector->state);
+ __drm_atomic_helper_connector_reset(connector, &state->base);
+ }
}
static struct drm_connector_state *
--
2.1.0
[PATCH v2 1/6] drm/i915: Set connector_state->connector using the helper.
The atomic helper sets connector_state->connector, which the i915
code didn't. This will become a problem when we start using it.
Signed-off-by: Maarten Lankhorst
Acked-by: Thierry Reding
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7dd7200d3ba9..1e42309ec40a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6477,13 +6477,11 @@ static void intel_connector_check_state(struct
intel_connector *connector)
int intel_connector_init(struct intel_connector *connector)
{
- struct drm_connector_state *connector_state;
+ drm_atomic_helper_connector_reset(&connector->base);
- connector_state = kzalloc(sizeof *connector_state, GFP_KERNEL);
- if (!connector_state)
+ if (!connector->base.state)
return -ENOMEM;
- connector->base.state = connector_state;
return 0;
}
--
2.1.0
[PATCH v2 5/6] drm/i915: Update connector_mask during readout.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1e42309ec40a..b76778d76035 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15421,6 +15421,7 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc)
WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, NULL) <
0);
crtc->base.state->active = crtc->active;
crtc->base.enabled = crtc->active;
+ crtc->base.state->connector_mask = 0;
/* Because we only establish the connector -> encoder ->
* crtc links if something is active, this means the
@@ -15456,20 +15457,24 @@ static void intel_sanitize_encoder(struct
intel_encoder *encoder)
{
struct intel_connector *connector;
struct drm_device *dev = encoder->base.dev;
+ struct drm_crtc *crtc = encoder->base.crtc;
bool active = false;
/* We need to check both for a crtc link (meaning that the
* encoder is active and trying to read from a pipe) and the
* pipe itself being active. */
- bool has_active_crtc = encoder->base.crtc &&
- to_intel_crtc(encoder->base.crtc)->active;
+ bool has_active_crtc = crtc && crtc->state->active;
for_each_intel_connector(dev, connector) {
if (connector->base.encoder != &encoder->base)
continue;
active = true;
- break;
+ if (!has_active_crtc)
+ break;
+
+ crtc->state->connector_mask |=
+ 1 << drm_connector_index(&connector->base);
}
if (active && !has_active_crtc) {
--
2.1.0
[PATCH v2 4/6] drm/atomic: add connector mask to drm_crtc_state.
It can be useful to iterate over connectors without grabbing
connection_mutex. It can also be used to see how many connectors
are on a crtc without iterating over the list.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 11 +++
include/drm/drm_crtc.h | 3 +++
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 6a21e5c378c1..14b321580517 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1063,10 +1063,21 @@ drm_atomic_set_crtc_for_connector(struct
drm_connector_state *conn_state,
{
struct drm_crtc_state *crtc_state;
+ if (conn_state->crtc && conn_state->crtc != crtc) {
+ crtc_state =
drm_atomic_get_existing_crtc_state(conn_state->state,
+
conn_state->crtc);
+
+ crtc_state->connector_mask &=
+ ~(1 << drm_connector_index(conn_state->connector));
+ }
+
if (crtc) {
crtc_state = drm_atomic_get_crtc_state(conn_state->state, crtc);
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
+
+ crtc_state->connector_mask |=
+ 1 << drm_connector_index(conn_state->connector);
}
conn_state->crtc = crtc;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c2f98ba2bb98..dd0db4ceab26 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -301,6 +301,7 @@ struct drm_plane_helper_funcs;
* @active_changed: crtc_state->active has been toggled.
* @connectors_changed: connectors to this crtc have been updated
* @plane_mask: bitmask of (1 << drm_plane_index(plane)) of attached planes
+ * @connector_mask: bitmask of (1 << drm_connector_index(connector)) of
attached connectors
* @last_vblank_count: for helpers and drivers to capture the vblank of the
* update to ensure framebuffer cleanup isn't done too early
* @adjusted_mode: for use by helpers and drivers to compute adjusted mode
timings
@@ -334,6 +335,8 @@ struct drm_crtc_state {
*/
u32 plane_mask;
+ u32 connector_mask;
+
/* last_vblank_count: for vblank waits before cleanup */
u32 last_vblank_count;
--
2.1.0
[PATCH v2 6/6] drm/atomic: Remove drm_atomic_connectors_for_crtc.
Now that connector_mask is reliable there's no need for this
function any more.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c| 30 --
drivers/gpu/drm/drm_atomic_helper.c | 10 --
drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
include/drm/drm_atomic.h| 4
4 files changed, 5 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 14b321580517..d3ed12447fbb 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1183,36 +1183,6 @@ drm_atomic_add_affected_planes(struct drm_atomic_state
*state,
EXPORT_SYMBOL(drm_atomic_add_affected_planes);
/**
- * drm_atomic_connectors_for_crtc - count number of connected outputs
- * @state: atomic state
- * @crtc: DRM crtc
- *
- * This function counts all connectors which will be connected to @crtc
- * according to @state. Useful to recompute the enable state for @crtc.
- */
-int
-drm_atomic_connectors_for_crtc(struct drm_atomic_state *state,
- struct drm_crtc *crtc)
-{
- struct drm_connector *connector;
- struct drm_connector_state *conn_state;
-
- int i, num_connected_connectors = 0;
-
- for_each_connector_in_state(state, connector, conn_state, i) {
- if (conn_state->crtc == crtc)
- num_connected_connectors++;
- }
-
- DRM_DEBUG_ATOMIC("State %p has %i connectors for [CRTC:%d:%s]\n",
-state, num_connected_connectors,
-crtc->base.id, crtc->name);
-
- return num_connected_connectors;
-}
-EXPORT_SYMBOL(drm_atomic_connectors_for_crtc);
-
-/**
* drm_atomic_legacy_backoff - locking backoff for legacy ioctls
* @state: atomic state
*
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 27dd68f946e6..13b771cb0d35 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -464,7 +464,8 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
* crtc only changed its mode but has the same set of connectors.
*/
for_each_crtc_in_state(state, crtc, crtc_state, i) {
- int num_connectors;
+ bool has_connectors =
+ !!crtc_state->connector_mask;
/*
* We must set ->active_changed after walking connectors for
@@ -493,10 +494,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (ret != 0)
return ret;
- num_connectors = drm_atomic_connectors_for_crtc(state,
- crtc);
-
- if (crtc_state->enable != !!num_connectors) {
+ if (crtc_state->enable != has_connectors) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] enabled/connectors
mismatch\n",
crtc->base.id, crtc->name);
@@ -1755,7 +1753,7 @@ static int update_output_state(struct drm_atomic_state
*state,
if (crtc == set->crtc)
continue;
- if (!drm_atomic_connectors_for_crtc(state, crtc)) {
+ if (!crtc_state->connector_mask) {
ret = drm_atomic_set_mode_prop_for_crtc(crtc_state,
NULL);
if (ret < 0)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 2168a99d59aa..aa7ed24a41c7 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -327,7 +327,7 @@ static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
/* The pixelvalve can only feed one encoder (and encoders are
* 1:1 with connectors.)
*/
- if (drm_atomic_connectors_for_crtc(state->state, crtc) > 1)
+ if (hweight32(state->connector_mask) > 1)
return -EINVAL;
drm_atomic_crtc_state_for_each_plane(plane, state) {
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index d8576ac55693..d3eaa5df187a 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -130,10 +130,6 @@ int __must_check
drm_atomic_add_affected_planes(struct drm_atomic_state *state,
struct drm_crtc *crtc);
-int
-drm_atomic_connectors_for_crtc(struct drm_atomic_state *state,
- struct drm_crtc *crtc);
-
void drm_atomic_legacy_backoff(struct drm_atomic_state *state);
void
--
2.1.0
[RFC PATCH v1 1/2] drm/rockchip: vop: add rk3229 vop support
Hi Yakir,
Am Montag, 4. Januar 2016, 19:53:58 schrieb Yakir Yang:
> RK3229 registers layout is simalar to RK3288 layout, only the
> interruput registers is different to RK3288.
>
> RK3229 support two overlay plane and one hwc plane, max output
> resolution is 4K. it support IOMMU, and its IOMMU same as rk3288's.
>
> Signed-off-by: Yakir Yang
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +-
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 120
> drivers/gpu/drm/rockchip/rockchip_vop_reg.h
> | 90 + 4 files changed, 217 insertions(+), 2
> deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index d83bf87..3c83097
> 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -63,9 +63,12 @@
> #define VOP_INTR_SET_TYPE(vop, name, type, v) \
> do { \
> int i, reg = 0; \
> - for (i = 0; i < vop->data->intr->nintrs; i++) { \
> - if (vop->data->intr->intrs[i] & type) \
> + const struct vop_intr *intr = vop->data->intr; \
> + for (i = 0; i < intr->nintrs; i++) { \
> + if (intr->intrs[i] & type) { \
> reg |= (v) << i; \
> + reg |= intr->write_mask ? (1 << (i + 16)) : 0; \
> + } \
> } \
> VOP_INTR_SET(vop, name, reg); \
> } while (0)
I do believe this part, as well as setting the default .write_mask = false
for the existing parts should get its own patch + a bit more explanation
on what this does and why it's needed.
8<
drm/rockchip: Add support for interrupt registers using write-masks
Some new display-controllers are need to set write-masks to enable writes
to interrupt registers. Allow this to be set on a per-vop basis.
8<
or something like that, and then patches 2+3 being the rk3229 support +
binding.
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h index 071ff0b..1e839e8
> 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> @@ -60,6 +60,7 @@ struct vop_ctrl {
> };
>
> struct vop_intr {
> + bool write_mask;
> const int *intrs;
> uint32_t nintrs;
> struct vop_reg enable;
> @@ -136,6 +137,7 @@ struct vop_data {
> };
>
> /* interrupt define */
> +#define DUMMY_INTR (0 << 0)
> #define DSP_HOLD_VALID_INTR (1 << 0)
> #define FS_INTR (1 << 1)
> #define LINE_FLAG_INTR (1 << 2)
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c index 3166b46..bbcd128
> 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> @@ -174,6 +174,7 @@ static const int rk3288_vop_intrs[] = {
> };
>
> static const struct vop_intr rk3288_vop_intr = {
> + .write_mask = false,
> .intrs = rk3288_vop_intrs,
> .nintrs = ARRAY_SIZE(rk3288_vop_intrs),
> .status = VOP_REG(RK3288_INTR_CTRL0, 0xf, 0),
> @@ -190,6 +191,122 @@ static const struct vop_data rk3288_vop = {
> .win_size = ARRAY_SIZE(rk3288_vop_win_data),
> };
>
> +static const struct vop_scl_extension rk3229_win_full_scl_ext = {
> + .cbcr_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 31),
> + .cbcr_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 30),
> + .cbcr_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 28),
> + .cbcr_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 26),
> + .cbcr_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 24),
> + .yrgb_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 23),
> + .yrgb_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 22),
> + .yrgb_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 20),
> + .yrgb_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 18),
> + .yrgb_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 16),
> + .line_load_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 15),
> + .cbcr_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0x7, 12),
> + .yrgb_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0xf, 8),
> + .vsd_cbcr_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 7),
> + .vsd_cbcr_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 6),
> + .vsd_yrgb_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 5),
> + .vsd_yrgb_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 4),
> + .bic_coe_sel = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 2),
> + .cbcr_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 1),
> + .yrgb_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 0),
> + .lb_mode = VOP_REG(RK3229_WIN0_CTRL0, 0x7, 5),
> +};
> +
> +static const struct vop_scl_regs rk3229_win_full_scl = {
> + .ext = &rk3229_win_full_scl_ext,
> + .scale_yrgb_x = VOP
[PATCH v3 1/7] drm/exynos: rename zpos to index
Hi Marek, 2015ë 12ì 28ì¼ 21:34ì Marek Szyprowski ì´(ê°) ì´ ê¸: > Hello, > > On 2015-12-24 09:15, Inki Dae wrote: >> Seems this patch could be more cleaned up. >> >> Each ctx object of each crtc driver has its own plane config object which >> includes already zpos value. >> So I think we wouldn't need to keep zpos of the plane config and index of >> the plane object. >> How about removing index from exynos plane structure and using zpos of >> exynos plane config structure instead? >> >> Below patch can be applied on top of your patch, > > If you want I can move 'index' entry to config object, but the initial zpos > value > should also be there. Please note that index is not always equal to the > initial zpos > and having initial zpos configurable is also needed. There were already > concerns if > mixer's dedicated video plane should be below or above the primary gfx plane > in the > default configuration. Merged all patches. Thanks, Inki Dae > >> (...) > > Best regards
[PATCH] drm: powerplay: use div64_s64 instead of do_div
On 01.01.2016 14:07, Arnd Bergmann wrote:
> The newly added code for Fiji creates a correct compiler warning
> about invalid use of the do_div macro:
>
> In file included from powerplay/hwmgr/ppatomctrl.c:31:0:
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppevvmath.h: In function
> 'fDivide':
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppevvmath.h:382:89: warning:
> comparison of distinct pointer types lacks a cast
> do_div(longlongX, longlongY); /*Q(32,32) divided by Q(16,16) = Q(16,16)
> Back to original format */
>
> do_div() divides an unsigned 64-bit number by an unsigned 32-bit number.
> The code instead wants to divide two signed 64-bit numbers, which is done
> using the div64_s64 function.
>
> Signed-off-by: Arnd Bergmann
Reviewed-by: Christian König
> Fixes: 770911a3cfbb ("drm/amd/powerplay: add/update headers for Fiji SMU and
> DPM")
> ---
> Found on ARM allmodconfig on yesterday's linux-next
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
> b/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
> index 42f2423cddea..411cb0fcdf98 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
> @@ -379,7 +379,7 @@ fInt fDivide (fInt X, fInt Y)
>
> longlongX = longlongX << 16; /*Q(16,16) -> Q(32,32) */
>
> -do_div(longlongX, longlongY); /*Q(32,32) divided by Q(16,16) = Q(16,16)
> Back to original format */
> +div64_s64(longlongX, longlongY); /*Q(32,32) divided by Q(16,16) =
> Q(16,16) Back to original format */
>
> fQuotient.full = (int)longlongX;
> return fQuotient;
>
[patch] drm/etnaviv: unlock on error in etnaviv_gem_get_iova()
We have to drop a lock before returning -ENOMEM here.
Fixes: a8c21a5451d8 ('drm/etnaviv: add initial etnaviv DRM driver')
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 8d6f859..9f77c3b 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -305,8 +305,10 @@ int etnaviv_gem_get_iova(struct etnaviv_gpu *gpu,
mapping = etnaviv_gem_get_vram_mapping(etnaviv_obj, NULL);
if (!mapping) {
mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
- if (!mapping)
- return -ENOMEM;
+ if (!mapping) {
+ ret = -ENOMEM;
+ goto out;
+ }
INIT_LIST_HEAD(&mapping->scan_node);
mapping->object = etnaviv_obj;
[patch] drm/etnaviv: unlock on error in etnaviv_gem_get_iova()
> We have to drop a lock before returning -ENOMEM here.
>
> Fixes: a8c21a5451d8 ('drm/etnaviv: add initial etnaviv DRM driver')
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index 8d6f859..9f77c3b 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -305,8 +305,10 @@ int etnaviv_gem_get_iova(struct etnaviv_gpu *gpu,
> mapping = etnaviv_gem_get_vram_mapping(etnaviv_obj, NULL);
> if (!mapping) {
> mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
> - if (!mapping)
> - return -ENOMEM;
> + if (!mapping) {
> + ret = -ENOMEM;
> + goto out;
> + }
>
> INIT_LIST_HEAD(&mapping->scan_node);
> mapping->object = etnaviv_obj;
How do you think about to reuse the jump label "unlock" there
like it is used in other source files?
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/etnaviv/etnaviv_gem.c?id=a8c21a5451d831e67b7a6fb910f9ca8bc7b43554#n263
Regards,
Markus
[patch] drm/etnaviv: unlock on error in etnaviv_gem_get_iova()
On Mon, Jan 04, 2016 at 04:10:24PM +0300, Dan Carpenter wrote:
> We have to drop a lock before returning -ENOMEM here.
>
> Fixes: a8c21a5451d8 ('drm/etnaviv: add initial etnaviv DRM driver')
> Signed-off-by: Dan Carpenter
diffstat missing?
In any case, the patch is correct, thanks.
Acked-by: Russell King
Lucas,
I guess you'll be picking this patch up, or shall we ask David to take
it directly?
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
[PATCH v2] i915: correctly handling failed allocation
On Wed, 30 Dec 2015, Insu Yun wrote: > Since devm_kzalloc can be failed, it needs to be checked > if not, NULL dereference could be happened. > > Signed-off-by: Insu Yun Pushed to drm-intel-next-queued, thanks for the patch. BR, Jani. > --- > drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c > b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c > index a5e99ac..aa1f7bc 100644 > --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c > +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c > @@ -666,6 +666,8 @@ struct drm_panel *vbt_panel_init(struct intel_dsi > *intel_dsi, u16 panel_id) > > /* This is cheating a bit with the cleanup. */ > vbt_panel = devm_kzalloc(dev->dev, sizeof(*vbt_panel), GFP_KERNEL); > + if (!vbt_panel) > + return NULL; > > vbt_panel->intel_dsi = intel_dsi; > drm_panel_init(&vbt_panel->panel); -- Jani Nikula, Intel Open Source Technology Center
[RFC PATCH v1 2/2] dt-bindings: add document for rk3229-vop
On Mon, Jan 04, 2016 at 07:50:30PM +0800, Yakir Yang wrote: > > Signed-off-by: Yakir Yang > --- > Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring
[patch] drm/etnaviv: unlock on error in etnaviv_gem_get_iova()
Am Montag, den 04.01.2016, 13:54 + schrieb Russell King - ARM
Linux:
> On Mon, Jan 04, 2016 at 04:10:24PM +0300, Dan Carpenter wrote:
> > We have to drop a lock before returning -ENOMEM here.
> >
> > Fixes: a8c21a5451d8 ('drm/etnaviv: add initial etnaviv DRM driver')
> > Signed-off-by: Dan Carpenter
>
> diffstat missing?
>
> In any case, the patch is correct, thanks.
>
> Acked-by: Russell King
>
> Lucas,
>
> I guess you'll be picking this patch up, or shall we ask David to
> take
> it directly?
>
I'm still on vacation until Wednesday, but after this I'll start to
sort through the outstanding etnaviv requests that need attention. I'll
pick up this patch along with some other things that I need to send out
for review and will issue a pull to Dave then.
Regards,
Lucas
[patch] drm/etnaviv: unlock on error in etnaviv_gem_get_iova()
On Mon, Jan 04, 2016 at 03:13:22PM +0100, Lucas Stach wrote:
> Am Montag, den 04.01.2016, 13:54 + schrieb Russell King - ARM
> Linux:
> > On Mon, Jan 04, 2016 at 04:10:24PM +0300, Dan Carpenter wrote:
> > > We have to drop a lock before returning -ENOMEM here.
> > >
> > > Fixes: a8c21a5451d8 ('drm/etnaviv: add initial etnaviv DRM driver')
> > > Signed-off-by: Dan Carpenter
> >
> > diffstat missing?
> >
> > In any case, the patch is correct, thanks.
> >
> > Acked-by: Russell King
> >
> > Lucas,
> >
> > I guess you'll be picking this patch up, or shall we ask David to
> > take
> > it directly?
> >
> I'm still on vacation until Wednesday, but after this I'll start to
> sort through the outstanding etnaviv requests that need attention. I'll
> pick up this patch along with some other things that I need to send out
> for review and will issue a pull to Dave then.
I'm not aware of any other changes which are outstanding for etnaviv.
If we're supposed to be working together, would you mind sharing them
with the other etnaviv authors?
Note that the merge window is probably opening next Sunday, and that's
really tight to get development into maintainers trees, especially as
the final -next prior to the merge window will involve pulling trees
around midnight (GMT) on Thursday.
I also have a pile of patches, but they're development stuff, which I'm
holding off until we get etnaviv merged into mainline - I'd suggest
treating everything that same way at this point, and only ask David to
merge changes which are fixes - exactly like this one.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
[PATCH RESEND 3/3] drm: adv7511: it's HPD, not HDP
On 01/04/2016 03:33 AM, Wolfram Sang wrote: > From: Wolfram Sang > > Fix this typo, consequently used over both files :) > > Signed-off-by: Wolfram Sang Acked-by: Lars-Peter Clausen Thanks.
[PATCH RESEND 2/3] drm: adv7511: mark ADV7511_REG_EDID_READ_CTRL volatile
Hi Wolfram, Thank you for the patch. On Monday 04 January 2016 03:33:46 Wolfram Sang wrote: > From: Wolfram Sang > > This register includes a counter which is decremented by the chip on I2C > failures. Also, it is reset when powering down. > > Signed-off-by: Wolfram Sang Reviewed-by: Laurent Pinchart A small note though, even though the patch is correct, it will be of limited use as the EDID_READ_CTRL register is never accessed by the driver. > --- > drivers/gpu/drm/i2c/adv7511.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c > index 85e994796d96a4..50a861b12346c4 100644 > --- a/drivers/gpu/drm/i2c/adv7511.c > +++ b/drivers/gpu/drm/i2c/adv7511.c > @@ -136,6 +136,7 @@ static bool adv7511_register_volatile(struct device > *dev, unsigned int reg) case ADV7511_REG_BKSV(3): > case ADV7511_REG_BKSV(4): > case ADV7511_REG_DDC_STATUS: > + case ADV7511_REG_EDID_READ_CTRL: > case ADV7511_REG_BSTATUS(0): > case ADV7511_REG_BSTATUS(1): > case ADV7511_REG_CHIP_ID_HIGH: -- Regards, Laurent Pinchart
[PATCH RESEND 3/3] drm: adv7511: it's HPD, not HDP
Hi Wolfram,
Thank you for the patch.
On Monday 04 January 2016 03:33:47 Wolfram Sang wrote:
> From: Wolfram Sang
>
> Fix this typo, consequently used over both files :)
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/i2c/adv7511.c | 22 +++---
> drivers/gpu/drm/i2c/adv7511.h | 12 ++--
> 2 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
> index 50a861b12346c4..c03c1ea53fd042 100644
> --- a/drivers/gpu/drm/i2c/adv7511.c
> +++ b/drivers/gpu/drm/i2c/adv7511.c
> @@ -378,16 +378,16 @@ static void adv7511_power_on(struct adv7511 *adv7511)
> }
>
> /*
> - * Per spec it is allowed to pulse the HDP signal to indicate that the
> + * Per spec it is allowed to pulse the HPD signal to indicate that the
>* EDID information has changed. Some monitors do this when they wakeup
> - * from standby or are enabled. When the HDP goes low the adv7511 is
> + * from standby or are enabled. When the HPD goes low the adv7511 is
>* reset and the outputs are disabled which might cause the monitor to
> - * go to standby again. To avoid this we ignore the HDP pin for the
> + * go to standby again. To avoid this we ignore the HPD pin for the
>* first few seconds after enabling the output.
>*/
> regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
> -ADV7511_REG_POWER2_HDP_SRC_MASK,
> -ADV7511_REG_POWER2_HDP_SRC_NONE);
> +ADV7511_REG_POWER2_HPD_SRC_MASK,
> +ADV7511_REG_POWER2_HPD_SRC_NONE);
>
> /*
>* Most of the registers are reset during power down or when HPD is low.
> @@ -421,9 +421,9 @@ static bool adv7511_hpd(struct adv7511 *adv7511)
> if (ret < 0)
> return false;
>
> - if (irq0 & ADV7511_INT0_HDP) {
> + if (irq0 & ADV7511_INT0_HPD) {
> regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
> - ADV7511_INT0_HDP);
> + ADV7511_INT0_HPD);
> return true;
> }
>
> @@ -446,7 +446,7 @@ static int adv7511_irq_process(struct adv7511 *adv7511)
> regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0);
> regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
>
> - if (irq0 & ADV7511_INT0_HDP && adv7511->encoder)
> + if (irq0 & ADV7511_INT0_HPD && adv7511->encoder)
> drm_helper_hpd_irq_event(adv7511->encoder->dev);
>
> if (irq0 & ADV7511_INT0_EDID_READY || irq1 & ADV7511_INT1_DDC_ERROR) {
> @@ -648,10 +648,10 @@ adv7511_encoder_detect(struct drm_encoder *encoder,
> if (adv7511->status == connector_status_connected)
> status = connector_status_disconnected;
> } else {
> - /* Renable HDP sensing */
> + /* Renable HPD sensing */
> regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
> -ADV7511_REG_POWER2_HDP_SRC_MASK,
> -ADV7511_REG_POWER2_HDP_SRC_BOTH);
> +ADV7511_REG_POWER2_HPD_SRC_MASK,
> +ADV7511_REG_POWER2_HPD_SRC_BOTH);
> }
>
> adv7511->status = status;
> diff --git a/drivers/gpu/drm/i2c/adv7511.h b/drivers/gpu/drm/i2c/adv7511.h
> index 6599ed538426d6..38515b30cedfc8 100644
> --- a/drivers/gpu/drm/i2c/adv7511.h
> +++ b/drivers/gpu/drm/i2c/adv7511.h
> @@ -90,7 +90,7 @@
> #define ADV7511_CSC_ENABLE BIT(7)
> #define ADV7511_CSC_UPDATE_MODE BIT(5)
>
> -#define ADV7511_INT0_HDP BIT(7)
> +#define ADV7511_INT0_HPD BIT(7)
> #define ADV7511_INT0_VSYNC BIT(5)
> #define ADV7511_INT0_AUDIO_FIFO_FULL BIT(4)
> #define ADV7511_INT0_EDID_READY BIT(2)
> @@ -157,11 +157,11 @@
> #define ADV7511_PACKET_ENABLE_SPARE2 BIT(1)
> #define ADV7511_PACKET_ENABLE_SPARE1 BIT(0)
>
> -#define ADV7511_REG_POWER2_HDP_SRC_MASK 0xc0
> -#define ADV7511_REG_POWER2_HDP_SRC_BOTH 0x00
> -#define ADV7511_REG_POWER2_HDP_SRC_HDP 0x40
> -#define ADV7511_REG_POWER2_HDP_SRC_CEC 0x80
> -#define ADV7511_REG_POWER2_HDP_SRC_NONE 0xc0
> +#define ADV7511_REG_POWER2_HPD_SRC_MASK 0xc0
> +#define ADV7511_REG_POWER2_HPD_SRC_BOTH 0x00
> +#define ADV7511_REG_POWER2_HPD_SRC_HPD 0x40
> +#define ADV7511_REG_POWER2_HPD_SRC_CEC 0x80
> +#define ADV7511_REG_POWER2_HPD_SRC_NONE 0xc0
> #define ADV7511_REG_POWER2_TDMS_ENABLE BIT(4)
> #define ADV7511_REG_POWER2_GATE_INPUT_CLKBIT(0)
--
Regards,
Laurent Pinchart
[PATCH RESEND 1/3] drm: adv7511: really enable interrupts for EDID detection
Hi Wolfram,
Thank you for the patch.
On Monday 04 January 2016 03:33:45 Wolfram Sang wrote:
> From: Wolfram Sang
>
> The interrupts for EDID_READY or DDC_ERROR were never enabled in this
> driver, so reading EDID always timed out when chip was powered down and
> interrupts were used. Fix this and remove clearing the interrupt flags,
> they are cleared in POWER_DOWN mode anyhow (according to docs and my
> tests).
>
> Signed-off-by: Wolfram Sang
> ---
> drivers/gpu/drm/i2c/adv7511.c | 25 +
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
> index 00416f23b5cb5f..85e994796d96a4 100644
> --- a/drivers/gpu/drm/i2c/adv7511.c
> +++ b/drivers/gpu/drm/i2c/adv7511.c
> @@ -362,12 +362,19 @@ static void adv7511_power_on(struct adv7511 *adv7511)
> {
> adv7511->current_edid_segment = -1;
>
> - regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
> - ADV7511_INT0_EDID_READY);
> - regmap_write(adv7511->regmap, ADV7511_REG_INT(1),
> - ADV7511_INT1_DDC_ERROR);
> regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
> ADV7511_POWER_POWER_DOWN, 0);
> + if (adv7511->i2c_main->irq) {
> + /*
> + * Documentation says the INT_ENABLE registers are reset in
> + * POWER_DOWN mode. My tests with a 7511w show something else
> + * but let's stick to the documentation.
This contradicts the commit message, which one is correct ?
> + */
> + regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
> + ADV7511_INT0_EDID_READY);
> + regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
> + ADV7511_INT1_DDC_ERROR);
> + }
>
> /*
>* Per spec it is allowed to pulse the HDP signal to indicate that the
> @@ -567,12 +574,14 @@ static int adv7511_get_modes(struct drm_encoder
> *encoder,
>
> /* Reading the EDID only works if the device is powered */
> if (!adv7511->powered) {
> - regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
> - ADV7511_INT0_EDID_READY);
> - regmap_write(adv7511->regmap, ADV7511_REG_INT(1),
> - ADV7511_INT1_DDC_ERROR);
> regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
> ADV7511_POWER_POWER_DOWN, 0);
> + if (adv7511->i2c_main->irq) {
> + regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
> + ADV7511_INT0_EDID_READY);
> + regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
> + ADV7511_INT1_DDC_ERROR);
> + }
> adv7511->current_edid_segment = -1;
> }
--
Regards,
Laurent Pinchart
[PATCH RESEND 1/3] drm: adv7511: really enable interrupts for EDID detection
Hi Laurent,
On Mon, Jan 4, 2016 at 3:37 PM, Laurent Pinchart
wrote:
> On Monday 04 January 2016 03:33:45 Wolfram Sang wrote:
>> From: Wolfram Sang
>>
>> The interrupts for EDID_READY or DDC_ERROR were never enabled in this
>> driver, so reading EDID always timed out when chip was powered down and
>> interrupts were used. Fix this and remove clearing the interrupt flags,
>> they are cleared in POWER_DOWN mode anyhow (according to docs and my
>> tests).
>>
>> Signed-off-by: Wolfram Sang
>> ---
>> drivers/gpu/drm/i2c/adv7511.c | 25 +
>> 1 file changed, 17 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
>> index 00416f23b5cb5f..85e994796d96a4 100644
>> --- a/drivers/gpu/drm/i2c/adv7511.c
>> +++ b/drivers/gpu/drm/i2c/adv7511.c
>> @@ -362,12 +362,19 @@ static void adv7511_power_on(struct adv7511 *adv7511)
>> {
>> adv7511->current_edid_segment = -1;
>>
>> - regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
>> - ADV7511_INT0_EDID_READY);
>> - regmap_write(adv7511->regmap, ADV7511_REG_INT(1),
>> - ADV7511_INT1_DDC_ERROR);
>> regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
>> ADV7511_POWER_POWER_DOWN, 0);
>> + if (adv7511->i2c_main->irq) {
>> + /*
>> + * Documentation says the INT_ENABLE registers are reset in
>> + * POWER_DOWN mode. My tests with a 7511w show something else
>> + * but let's stick to the documentation.
>
> This contradicts the commit message, which one is correct ?
Initially I thought the same, until I realized the commit message refers to...
>> + */
>> + regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
>> + ADV7511_INT0_EDID_READY);
>> + regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
>> + ADV7511_INT1_DDC_ERROR);
>> + }
>>
>> /*
>>* Per spec it is allowed to pulse the HDP signal to indicate that the
>> @@ -567,12 +574,14 @@ static int adv7511_get_modes(struct drm_encoder
>> *encoder,
>>
>> /* Reading the EDID only works if the device is powered */
>> if (!adv7511->powered) {
>> - regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
>> - ADV7511_INT0_EDID_READY);
>> - regmap_write(adv7511->regmap, ADV7511_REG_INT(1),
>> - ADV7511_INT1_DDC_ERROR);
... this removal ^.
>> regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
>> ADV7511_POWER_POWER_DOWN, 0);
>> + if (adv7511->i2c_main->irq) {
>> + regmap_write(adv7511->regmap,
>> ADV7511_REG_INT_ENABLE(0),
>> + ADV7511_INT0_EDID_READY);
>> + regmap_write(adv7511->regmap,
>> ADV7511_REG_INT_ENABLE(1),
>> + ADV7511_INT1_DDC_ERROR);
>> + }
>> adv7511->current_edid_segment = -1;
>> }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[Bug 93577] Total war: Attila crashes at startup
WP 4094)): #0 0x769392d7 in do_futex_wait.constprop () from /usr/lib/libpthread.so.0 #1 0x76939384 in __new_sem_wait_slow.constprop.0 () from /usr/lib/libpthread.so.0 #2 0x7543d76e in ?? () from /usr/lib/libSDL2-2.0.so.0 #3 0x7543d8c5 in ?? () from /usr/lib/libSDL2-2.0.so.0 #4 0x753f0c93 in ?? () from /usr/lib/libSDL2-2.0.so.0 #5 0x753f082c in ?? () from /usr/lib/libSDL2-2.0.so.0 #6 0x7543d439 in ?? () from /usr/lib/libSDL2-2.0.so.0 #7 0x769314a4 in start_thread () from /usr/lib/libpthread.so.0 #8 0x7436c13d in clone () from /usr/lib/libc.so.6 Thread 1 (Thread 0x77eed840 (LWP 4090)): #0 0x74314078 in __memcpy_sse2_unaligned () from /usr/lib/libc.so.6 #1 0x0318ae9a in WARSCAPE::TEXTURE_MANAGER_ENTRY::update (this=0x173e47c0, image=..., mip_map_level=0, _src_rect=0x0, dest_x=0, dest_y=0, dest_z=, update_gpu=) at Source/platform/TextureManager.inl:333 #2 0x0344011f in WARSCAPE::TEXTURE_MANAGER_ENTRY::update (this=, image=..., mip_map_level=, dest_x=, dest_y=, dest_z=, update_gpu=, this=, image=..., mip_map_level=, dest_x=, dest_y=, dest_z=, update_gpu=) at Source/platform/TextureManager.inl:86 #3 WARSCAPE::TEXTURE_MANAGER_ENTRY::create_resource (this=, out_of_video_memory=) at Source/platform/TextureManagerEntry.cpp:3131 #4 0x0310e804 in WARSCAPE::TEXTURE_MANAGER::register_texture (this=0xa9fdcd0, texture=..., flags=(TF_DYNAMIC | TF_READABLE | TF_UI_RESOURCE), file_name=..., alt_filename=..., original_filename=..., from_file=, texel_format=, width=, height=, depth=, num_mip_map_levels=, image=, critical=, screen_size_multiplier=, aa_setting=) at Source/platform/TextureManager.cpp:2230 #5 0x03111389 in WARSCAPE::WS_CONTEXT::texture_manager () at Source/WarscapeBase.h:125 ---Type to continue, or q to quit--- #6 WARSCAPE::TEXTURE::register_texture (this=, filename=..., alt_filename=..., orig_filename=..., from_file=, texel_format=, width=, height=, depth=, num_mip_map_levels=, image=, critical=, aa_setting=, this=, flags=, filename=..., alt_filename=..., orig_filename=..., from_file=, texel_format=, width=, height=, depth=, num_mip_map_levels=, image=, critical=, screen_size_multiplier=, aa_setting=) at Source/resource/Texture.cpp:135 #7 WARSCAPE::TEXTURE::TEXTURE (this=0x17067bd0, category=, image=0xc33ddf0, flags=(TF_DYNAMIC | TF_READABLE | TF_UI_RESOURCE), texel_format=TEXTURE_TEXEL_FORMAT::TTF_NUM_FORMATS) at Source/resource/Texture.cpp:210 #8 0x030b09ff in WARSCAPE::TEXTURE_MANAGER::create_default_textures (this=0xa9fdcd0) at Source/platform/TextureManager.cpp:924 #9 0x030b05b0 in WARSCAPE::SCENE::create (this=0x10ff0150, reg_scene=0xaf860f0) at Source/scene/Scene.cpp:1243 #10 0x0310066c in WARSCAPE::WS_ENGINE_IMP::registration_end (this=0xa0b2680, register_scene=0xaf860f0) at Source/platform/Engine.cpp:2497 #11 0x00570385 in EMPIRE::MVC_MANAGER::open_handler (this=0x10e96880) at Source/MVCManager.cpp:938 #12 0x00570763 in EMPIRE::MVC_MANAGER::update (this=0x10e96880, anti_piracy_v2_cracked_1=0, anti_piracy_v2_cracked_2=0, anti_piracy_v2_cracked_3=0, anti_piracy_v2_cracked_4=0) at Source/MVCManager.cpp:1198 #13 0x0058a699 in EMPIRE::EMPIRE_APP_MODULE::run_loop (this=0x57f5100, anti_piracy_v2_cracked_1=0, anti_piracy_v2_cracked_2=0, anti_piracy_v2_cracked_3=0, anti_piracy_v2_cracked_4=0) at Source/Empire.cpp:2326 #14 0x00576431 in TOTALWAR::on_app_update (main_thread=) at Source/POSIX/AppModuleWrapper.cpp:224 #15 0x004e3c33 in run_thread (argc=, argv=) at Source/TotalWar.cpp:163 #16 0x004e3e1b in main (argc=1, argv=0x7fffe798) at Source/TotalWar.cpp:177 I also attach the output of apitrace. Note that the producers of Total War: Attila explicitly state that they only support the NVidia binary driver at the exclusion of everything else, but they do not state what's missing/buggy in the Mesa drivers. Thanks! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/b9add70c/attachment-0001.html>
[PATCH 1/3] drm: Balance error path for GEM handle allocation
On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote:
> The current error path for failure when establishing a handle for a GEM
> object is unbalance, e.g. we call object_close() without calling first
> object_open(). Use the typical onion structure to only undo what has
> been set up prior to the error.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/drm_gem.c | 29 +
> 1 file changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 2e10bba4468b..a08176debc0e 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -343,27 +343,32 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
> spin_unlock(&file_priv->table_lock);
> idr_preload_end();
> mutex_unlock(&dev->object_name_lock);
> - if (ret < 0) {
> - drm_gem_object_handle_unreference_unlocked(obj);
> - return ret;
> - }
> + if (ret < 0)
> + goto err_unref;
> +
> *handlep = ret;
>
> ret = drm_vma_node_allow(&obj->vma_node, file_priv->filp);
> - if (ret) {
> - drm_gem_handle_delete(file_priv, *handlep);
> - return ret;
> - }
> + if (ret)
> + goto err_remove;
>
> if (dev->driver->gem_open_object) {
> ret = dev->driver->gem_open_object(obj, file_priv);
> - if (ret) {
> - drm_gem_handle_delete(file_priv, *handlep);
> - return ret;
> - }
> + if (ret)
> + goto err_revoke;
> }
>
> return 0;
> +
> +err_revoke:
> + drm_vma_node_revoke(&obj->vma_node, file_priv->filp);
> +err_remove:
> + spin_lock(&file_priv->table_lock);
> + idr_remove(&file_priv->object_idr, *handlep);
> + spin_unlock(&file_priv->table_lock);
> +err_unref:
> + drm_gem_object_handle_unreference_unlocked(obj);
> + return ret;
First I misread this as drm_gem_object_unreference_unlocked()
and though we'd leak the handle_count++, but it's
drm_gem_object_handle_unreference_unlocked() which does the
handle_count-- we need.
Reviewed-by: Ville Syrjälä
> }
>
> /**
> --
> 2.6.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
[Bug 93551] Divinity: Original Sin Enhanced Edition(Native) crash on start
https://bugs.freedesktop.org/show_bug.cgi?id=93551 --- Comment #2 from Nicolai Hähnle --- Thanks for the report, but to be honest, the backtrace looks like this is a game bug. The last function on the stack belongs to the game, and then it jumps to 0. This is what you would see if a game doesn't properly check extension support, for example. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/233da46a/attachment.html>
[PATCH 2/3] drm: Only bump object-reference count when adding first handle
On Mon, Jan 04, 2016 at 10:11:00AM +, Chris Wilson wrote:
> We only need a single reference count for all handles (i.e. non-zero
> obj->handle_count) and so can trim a few atomic operations by only
> taking the reference on the first handle and dropping it after the last.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/drm_gem.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index a08176debc0e..ad955d7c99fd 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -220,6 +220,9 @@ static void drm_gem_object_exported_dma_buf_free(struct
> drm_gem_object *obj)
> static void
> drm_gem_object_handle_unreference_unlocked(struct drm_gem_object *obj)
> {
> + struct drm_device *dev = obj->dev;
> + bool final = false;
> +
> if (WARN_ON(obj->handle_count == 0))
> return;
>
> @@ -229,14 +232,16 @@ drm_gem_object_handle_unreference_unlocked(struct
> drm_gem_object *obj)
> * checked for a name
> */
>
> - mutex_lock(&obj->dev->object_name_lock);
> + mutex_lock(&dev->object_name_lock);
> if (--obj->handle_count == 0) {
> drm_gem_object_handle_free(obj);
> drm_gem_object_exported_dma_buf_free(obj);
> + final = true;
> }
> - mutex_unlock(&obj->dev->object_name_lock);
> + mutex_unlock(&dev->object_name_lock);
>
> - drm_gem_object_unreference_unlocked(obj);
> + if (final)
> + drm_gem_object_unreference_unlocked(obj);
> }
>
> /**
> @@ -329,6 +334,8 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
> int ret;
>
> WARN_ON(!mutex_is_locked(&dev->object_name_lock));
> + if (obj->handle_count++ == 0)
> + drm_gem_object_reference(obj);
Hmm. Yeah, handle_count is protected by object_name_lock, so this looks
better here rather than within the spinlocked section.
Patch looks sane:
Reviewed-by: Ville Syrjälä
>
> /*
>* Get the user-visible handle using idr. Preload and perform
> @@ -338,10 +345,10 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
> spin_lock(&file_priv->table_lock);
>
> ret = idr_alloc(&file_priv->object_idr, obj, 1, 0, GFP_NOWAIT);
> - drm_gem_object_reference(obj);
> - obj->handle_count++;
> +
> spin_unlock(&file_priv->table_lock);
> idr_preload_end();
> +
> mutex_unlock(&dev->object_name_lock);
> if (ret < 0)
> goto err_unref;
> --
> 2.6.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
[PATCH 3/3] drm: Use a normal idr allocation for the obj->name
On Mon, Jan 04, 2016 at 10:11:01AM +, Chris Wilson wrote:
> Unlike the handle, the name table uses a sleeping mutex rather than a
> spinlock. The allocation is in a normal context, and we can use the
> simpler sleeping gfp_t, rather than have to take from the atomic
> reserves.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_gem.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index ad955d7c99fd..1b0c2c127072 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -642,7 +642,6 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
> return -ENOENT;
>
> mutex_lock(&dev->object_name_lock);
> - idr_preload(GFP_KERNEL);
> /* prevent races with concurrent gem_close. */
> if (obj->handle_count == 0) {
> ret = -ENOENT;
> @@ -650,7 +649,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
> }
>
> if (!obj->name) {
> - ret = idr_alloc(&dev->object_name_idr, obj, 1, 0, GFP_NOWAIT);
> + ret = idr_alloc(&dev->object_name_idr, obj, 1, 0, GFP_KERNEL);
> if (ret < 0)
> goto err;
>
> @@ -661,7 +660,6 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
> ret = 0;
>
> err:
> - idr_preload_end();
> mutex_unlock(&dev->object_name_lock);
> drm_gem_object_unreference_unlocked(obj);
> return ret;
> --
> 2.6.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
[Bug 76484] [radeonsi] Strike Suit Zero fail to start
https://bugs.freedesktop.org/show_bug.cgi?id=76484 --- Comment #5 from Nicolai Hähnle --- Judging by the backtraces, the game overrides the C++ operator delete in a way that gets confused with LLVM (which is also a C++ library) and then crashes. Probably it's a game bug. Your best bet for working around this problem is to link LLVM statically (i.e. convince the LLVM build to statically link against libstdc++, and then statically link LLVM into Mesa). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/31ba3f5f/attachment.html>
[PATCH 1/3] drm: Balance error path for GEM handle allocation
On Mon, Jan 04, 2016 at 10:18:50AM +, Chris Wilson wrote:
> On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote:
> > The current error path for failure when establishing a handle for a GEM
> > object is unbalance, e.g. we call object_close() without calling first
> > object_open(). Use the typical onion structure to only undo what has
> > been set up prior to the error.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/drm_gem.c | 29 +
> > 1 file changed, 17 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index 2e10bba4468b..a08176debc0e 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -343,27 +343,32 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
> > spin_unlock(&file_priv->table_lock);
> > idr_preload_end();
> > mutex_unlock(&dev->object_name_lock);
> > - if (ret < 0) {
> > - drm_gem_object_handle_unreference_unlocked(obj);
> > - return ret;
> > - }
> > + if (ret < 0)
> > + goto err_unref;
> > +
> > *handlep = ret;
> >
> > ret = drm_vma_node_allow(&obj->vma_node, file_priv->filp);
> > - if (ret) {
> > - drm_gem_handle_delete(file_priv, *handlep);
> > - return ret;
> > - }
> > + if (ret)
> > + goto err_remove;
> >
> > if (dev->driver->gem_open_object) {
> > ret = dev->driver->gem_open_object(obj, file_priv);
> > - if (ret) {
> > - drm_gem_handle_delete(file_priv, *handlep);
> > - return ret;
> > - }
> > + if (ret)
> > + goto err_revoke;
> > }
> >
> > return 0;
> > +
> > +err_revoke:
> > + drm_vma_node_revoke(&obj->vma_node, file_priv->filp);
> > +err_remove:
> > + spin_lock(&file_priv->table_lock);
> > + idr_remove(&file_priv->object_idr, *handlep);
>
> For bonus points, we could *handlep = 0; here.
For these sort of things I usually prefer to not clobber any
return parameters unless the whole operation suceeds.
>
> > + spin_unlock(&file_priv->table_lock);
> > +err_unref:
> > + drm_gem_object_handle_unreference_unlocked(obj);
> > + return ret;
> > }
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
[Intel-gfx] [PATCH 1/3] drm: Balance error path for GEM handle allocation
On Mon, Jan 04, 2016 at 05:24:11PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote:
> > The current error path for failure when establishing a handle for a GEM
> > object is unbalance, e.g. we call object_close() without calling first
> > object_open(). Use the typical onion structure to only undo what has
> > been set up prior to the error.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/drm_gem.c | 29 +
> > 1 file changed, 17 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index 2e10bba4468b..a08176debc0e 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -343,27 +343,32 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
> > spin_unlock(&file_priv->table_lock);
> > idr_preload_end();
> > mutex_unlock(&dev->object_name_lock);
> > - if (ret < 0) {
> > - drm_gem_object_handle_unreference_unlocked(obj);
> > - return ret;
> > - }
> > + if (ret < 0)
> > + goto err_unref;
> > +
> > *handlep = ret;
> >
> > ret = drm_vma_node_allow(&obj->vma_node, file_priv->filp);
> > - if (ret) {
> > - drm_gem_handle_delete(file_priv, *handlep);
> > - return ret;
> > - }
> > + if (ret)
> > + goto err_remove;
> >
> > if (dev->driver->gem_open_object) {
> > ret = dev->driver->gem_open_object(obj, file_priv);
> > - if (ret) {
> > - drm_gem_handle_delete(file_priv, *handlep);
> > - return ret;
> > - }
> > + if (ret)
> > + goto err_revoke;
> > }
> >
> > return 0;
> > +
> > +err_revoke:
> > + drm_vma_node_revoke(&obj->vma_node, file_priv->filp);
> > +err_remove:
> > + spin_lock(&file_priv->table_lock);
> > + idr_remove(&file_priv->object_idr, *handlep);
> > + spin_unlock(&file_priv->table_lock);
> > +err_unref:
> > + drm_gem_object_handle_unreference_unlocked(obj);
> > + return ret;
>
> First I misread this as drm_gem_object_unreference_unlocked()
> and though we'd leak the handle_count++, but it's
> drm_gem_object_handle_unreference_unlocked() which does the
> handle_count-- we need.
>
> Reviewed-by: Ville Syrjälä
BTW while looking at the code I spotted that drm_gem_handle_delete()
contains an open coded copy of drm_gem_object_release_handle(). Might
make sense to eliminate that duplication.
>
> > }
> >
> > /**
> > --
> > 2.6.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
[PATCH 1/3] drm: Balance error path for GEM handle allocation
On Mon, Jan 04, 2016 at 05:33:45PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 04, 2016 at 10:18:50AM +, Chris Wilson wrote:
> > On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote:
> > > The current error path for failure when establishing a handle for a GEM
> > > object is unbalance, e.g. we call object_close() without calling first
> > > object_open(). Use the typical onion structure to only undo what has
> > > been set up prior to the error.
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/drm_gem.c | 29 +
> > > 1 file changed, 17 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > > index 2e10bba4468b..a08176debc0e 100644
> > > --- a/drivers/gpu/drm/drm_gem.c
> > > +++ b/drivers/gpu/drm/drm_gem.c
> > > @@ -343,27 +343,32 @@ drm_gem_handle_create_tail(struct drm_file
> > > *file_priv,
> > > spin_unlock(&file_priv->table_lock);
> > > idr_preload_end();
> > > mutex_unlock(&dev->object_name_lock);
> > > - if (ret < 0) {
> > > - drm_gem_object_handle_unreference_unlocked(obj);
> > > - return ret;
> > > - }
> > > + if (ret < 0)
> > > + goto err_unref;
> > > +
> > > *handlep = ret;
> > >
> > > ret = drm_vma_node_allow(&obj->vma_node, file_priv->filp);
> > > - if (ret) {
> > > - drm_gem_handle_delete(file_priv, *handlep);
> > > - return ret;
> > > - }
> > > + if (ret)
> > > + goto err_remove;
> > >
> > > if (dev->driver->gem_open_object) {
> > > ret = dev->driver->gem_open_object(obj, file_priv);
> > > - if (ret) {
> > > - drm_gem_handle_delete(file_priv, *handlep);
> > > - return ret;
> > > - }
> > > + if (ret)
> > > + goto err_revoke;
> > > }
> > >
> > > return 0;
> > > +
> > > +err_revoke:
> > > + drm_vma_node_revoke(&obj->vma_node, file_priv->filp);
> > > +err_remove:
> > > + spin_lock(&file_priv->table_lock);
> > > + idr_remove(&file_priv->object_idr, *handlep);
> >
> > For bonus points, we could *handlep = 0; here.
>
> For these sort of things I usually prefer to not clobber any
> return parameters unless the whole operation suceeds.
True, resetting handlep back to the INVALID_HANDLE value was just a step
in the right direction ;-)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[Bug 93546] Civilization 5 - Leaders in the diplomatic interactions screen appear completely black
https://bugs.freedesktop.org/show_bug.cgi?id=93546 --- Comment #4 from Nicolai Hähnle --- You need to produce a 32 bit build of apitrace. You'll need multiarch/multilib support in your distribution and 32-bit variants of certain packages (e.g. on Debian/Ubuntu, install the g++-multilib package, and libwhatever-dev:i386 if you get error messages for libwhatever). When running cmake, add the following parameters: -DCMAKE_C_FLAGS=-m32 -DCMAKE_CXX_FLAGS=-m32 -DCMAKE_EXE_LINKER_FLAGS=-m32 -DENABLE_GUI=FALSE Traces recorded using the 32 bit apitrace can be played back on apitrace of any bitness. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/a90f2ce1/attachment.html>
[PATCH] drm: powerplay: use div64_s64 instead of do_div
On Fri, Jan 1, 2016 at 8:07 AM, Arnd Bergmann wrote:
> The newly added code for Fiji creates a correct compiler warning
> about invalid use of the do_div macro:
>
> In file included from powerplay/hwmgr/ppatomctrl.c:31:0:
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppevvmath.h: In function
> 'fDivide':
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppevvmath.h:382:89: warning:
> comparison of distinct pointer types lacks a cast
> do_div(longlongX, longlongY); /*Q(32,32) divided by Q(16,16) = Q(16,16)
> Back to original format */
>
> do_div() divides an unsigned 64-bit number by an unsigned 32-bit number.
> The code instead wants to divide two signed 64-bit numbers, which is done
> using the div64_s64 function.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 770911a3cfbb ("drm/amd/powerplay: add/update headers for Fiji SMU and
> DPM")
Applied. thanks!
Alex
> ---
> Found on ARM allmodconfig on yesterday's linux-next
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
> b/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
> index 42f2423cddea..411cb0fcdf98 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
> @@ -379,7 +379,7 @@ fInt fDivide (fInt X, fInt Y)
>
> longlongX = longlongX << 16; /*Q(16,16) -> Q(32,32) */
>
> -do_div(longlongX, longlongY); /*Q(32,32) divided by Q(16,16) = Q(16,16)
> Back to original format */
> +div64_s64(longlongX, longlongY); /*Q(32,32) divided by Q(16,16) =
> Q(16,16) Back to original format */
>
> fQuotient.full = (int)longlongX;
> return fQuotient;
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: Update radeon_get_vblank_counter_kms()
From: Thierry Reding
Commit 88e72717c2de ("drm/irq: Use unsigned int pipe in public API")
updated the prototype of this function but not the implementation. This
wasn't noticed even through compile tests because the prototype is part
of the source file that uses it and hence the compiler won't know the
prototype when it compiles the implementation.
The right thing would've been to move the prototype to a header that's
included in radeon_kms.c so that the implementation signature could be
checked against it, but the closest thing would've been radeon_drv.h
and including that results in a lot of build errors, so we'll leave it
as is for now.
Cc: Christian König
Cc: Alex Deucher
Signed-off-by: Thierry Reding
---
Changes in v2:
- remove unnecessary check for unsigned int < 0
drivers/gpu/drm/radeon/radeon_kms.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 2e8b114272dd..74068bf0b8bb 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -748,19 +748,19 @@ void radeon_driver_preclose_kms(struct drm_device *dev,
* radeon_get_vblank_counter_kms - get frame count
*
* @dev: drm dev pointer
- * @crtc: crtc to get the frame count from
+ * @pipe: crtc to get the frame count from
*
* Gets the frame count on the requested crtc (all asics).
* Returns frame count on success, -EINVAL on failure.
*/
-u32 radeon_get_vblank_counter_kms(struct drm_device *dev, int crtc)
+u32 radeon_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe)
{
int vpos, hpos, stat;
u32 count;
struct radeon_device *rdev = dev->dev_private;
- if (crtc < 0 || crtc >= rdev->num_crtc) {
- DRM_ERROR("Invalid crtc %d\n", crtc);
+ if (pipe >= rdev->num_crtc) {
+ DRM_ERROR("Invalid crtc %u\n", pipe);
return -EINVAL;
}
@@ -772,29 +772,29 @@ u32 radeon_get_vblank_counter_kms(struct drm_device *dev,
int crtc)
* and start of vsync, so vpos >= 0 means to bump the hw frame counter
* result by 1 to give the proper appearance to caller.
*/
- if (rdev->mode_info.crtcs[crtc]) {
+ if (rdev->mode_info.crtcs[pipe]) {
/* Repeat readout if needed to provide stable result if
* we cross start of vsync during the queries.
*/
do {
- count = radeon_get_vblank_counter(rdev, crtc);
+ count = radeon_get_vblank_counter(rdev, pipe);
/* Ask radeon_get_crtc_scanoutpos to return vpos as
* distance to start of vblank, instead of regular
* vertical scanout pos.
*/
stat = radeon_get_crtc_scanoutpos(
- dev, crtc, GET_DISTANCE_TO_VBLANKSTART,
+ dev, pipe, GET_DISTANCE_TO_VBLANKSTART,
&vpos, &hpos, NULL, NULL,
- &rdev->mode_info.crtcs[crtc]->base.hwmode);
- } while (count != radeon_get_vblank_counter(rdev, crtc));
+ &rdev->mode_info.crtcs[pipe]->base.hwmode);
+ } while (count != radeon_get_vblank_counter(rdev, pipe));
if (((stat & (DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE))
!=
(DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE))) {
DRM_DEBUG_VBL("Query failed! stat %d\n", stat);
}
else {
- DRM_DEBUG_VBL("crtc %d: dist from vblank start %d\n",
- crtc, vpos);
+ DRM_DEBUG_VBL("crtc %u: dist from vblank start %d\n",
+ pipe, vpos);
/* Bump counter if we are at >= leading edge of vblank,
* but before vsync where vpos would turn negative and
@@ -806,7 +806,7 @@ u32 radeon_get_vblank_counter_kms(struct drm_device *dev,
int crtc)
}
else {
/* Fallback to use value as is. */
- count = radeon_get_vblank_counter(rdev, crtc);
+ count = radeon_get_vblank_counter(rdev, pipe);
DRM_DEBUG_VBL("NULL mode info! Returned count may be wrong.\n");
}
--
2.5.0
[PATCH 0/8] Add ASoC support for AMD APUs [v6]
On Wed, Dec 23, 2015 at 02:01:08PM -0500, Alex Deucher wrote: > I talked to Dave Airlie on IRC and he has acked the drm side. I'd expect to see any acks in the changelogs for the patches as normal. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/a8059dda/attachment.sig>
[PATCH RESEND 2/3] drm: adv7511: mark ADV7511_REG_EDID_READ_CTRL volatile
> A small note though, even though the patch is correct, it will be of limited > use as the EDID_READ_CTRL register is never accessed by the driver. It was useful to me when debugging and looking at the register set in debugfs. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/dfa5a005/attachment.sig>
[PATCH RESEND 1/3] drm: adv7511: really enable interrupts for EDID detection
On Mon, Jan 04, 2016 at 04:37:44PM +0200, Laurent Pinchart wrote:
> Hi Wolfram,
>
> Thank you for the patch.
>
> On Monday 04 January 2016 03:33:45 Wolfram Sang wrote:
> > From: Wolfram Sang
> >
> > The interrupts for EDID_READY or DDC_ERROR were never enabled in this
> > driver, so reading EDID always timed out when chip was powered down and
> > interrupts were used. Fix this and remove clearing the interrupt flags,
> > they are cleared in POWER_DOWN mode anyhow (according to docs and my
> > tests).
> >
> > Signed-off-by: Wolfram Sang
> > ---
> > drivers/gpu/drm/i2c/adv7511.c | 25 +
> > 1 file changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
> > index 00416f23b5cb5f..85e994796d96a4 100644
> > --- a/drivers/gpu/drm/i2c/adv7511.c
> > +++ b/drivers/gpu/drm/i2c/adv7511.c
> > @@ -362,12 +362,19 @@ static void adv7511_power_on(struct adv7511 *adv7511)
> > {
> > adv7511->current_edid_segment = -1;
> >
> > - regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
> > -ADV7511_INT0_EDID_READY);
> > - regmap_write(adv7511->regmap, ADV7511_REG_INT(1),
> > -ADV7511_INT1_DDC_ERROR);
> > regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
> >ADV7511_POWER_POWER_DOWN, 0);
> > + if (adv7511->i2c_main->irq) {
> > + /*
> > +* Documentation says the INT_ENABLE registers are reset in
> > +* POWER_DOWN mode. My tests with a 7511w show something else
> > +* but let's stick to the documentation.
>
> This contradicts the commit message, which one is correct ?
As Geert mentioned, the commit message refers to the interrupt flags not
the interrupt_enable flags.
Shall I rephrase?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/07977b9d/attachment-0001.sig>
[PATCH] drm/radeon: Update radeon_get_vblank_counter_kms()
On Mon, Jan 4, 2016 at 10:44 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Commit 88e72717c2de ("drm/irq: Use unsigned int pipe in public API")
> updated the prototype of this function but not the implementation. This
> wasn't noticed even through compile tests because the prototype is part
> of the source file that uses it and hence the compiler won't know the
> prototype when it compiles the implementation.
>
> The right thing would've been to move the prototype to a header that's
> included in radeon_kms.c so that the implementation signature could be
> checked against it, but the closest thing would've been radeon_drv.h
> and including that results in a lot of build errors, so we'll leave it
> as is for now.
>
> Cc: Christian König
> Cc: Alex Deucher
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - remove unnecessary check for unsigned int < 0
I had applied your previous patch before Michel's feedback so it's
already in drm-next, any change you could spin a new patch to just
drop the < 0 check?
Thanks,
Alex
>
> drivers/gpu/drm/radeon/radeon_kms.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 2e8b114272dd..74068bf0b8bb 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -748,19 +748,19 @@ void radeon_driver_preclose_kms(struct drm_device *dev,
> * radeon_get_vblank_counter_kms - get frame count
> *
> * @dev: drm dev pointer
> - * @crtc: crtc to get the frame count from
> + * @pipe: crtc to get the frame count from
> *
> * Gets the frame count on the requested crtc (all asics).
> * Returns frame count on success, -EINVAL on failure.
> */
> -u32 radeon_get_vblank_counter_kms(struct drm_device *dev, int crtc)
> +u32 radeon_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe)
> {
> int vpos, hpos, stat;
> u32 count;
> struct radeon_device *rdev = dev->dev_private;
>
> - if (crtc < 0 || crtc >= rdev->num_crtc) {
> - DRM_ERROR("Invalid crtc %d\n", crtc);
> + if (pipe >= rdev->num_crtc) {
> + DRM_ERROR("Invalid crtc %u\n", pipe);
> return -EINVAL;
> }
>
> @@ -772,29 +772,29 @@ u32 radeon_get_vblank_counter_kms(struct drm_device
> *dev, int crtc)
> * and start of vsync, so vpos >= 0 means to bump the hw frame counter
> * result by 1 to give the proper appearance to caller.
> */
> - if (rdev->mode_info.crtcs[crtc]) {
> + if (rdev->mode_info.crtcs[pipe]) {
> /* Repeat readout if needed to provide stable result if
> * we cross start of vsync during the queries.
> */
> do {
> - count = radeon_get_vblank_counter(rdev, crtc);
> + count = radeon_get_vblank_counter(rdev, pipe);
> /* Ask radeon_get_crtc_scanoutpos to return vpos as
> * distance to start of vblank, instead of regular
> * vertical scanout pos.
> */
> stat = radeon_get_crtc_scanoutpos(
> - dev, crtc, GET_DISTANCE_TO_VBLANKSTART,
> + dev, pipe, GET_DISTANCE_TO_VBLANKSTART,
> &vpos, &hpos, NULL, NULL,
> - &rdev->mode_info.crtcs[crtc]->base.hwmode);
> - } while (count != radeon_get_vblank_counter(rdev, crtc));
> + &rdev->mode_info.crtcs[pipe]->base.hwmode);
> + } while (count != radeon_get_vblank_counter(rdev, pipe));
>
> if (((stat & (DRM_SCANOUTPOS_VALID |
> DRM_SCANOUTPOS_ACCURATE)) !=
> (DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE))) {
> DRM_DEBUG_VBL("Query failed! stat %d\n", stat);
> }
> else {
> - DRM_DEBUG_VBL("crtc %d: dist from vblank start %d\n",
> - crtc, vpos);
> + DRM_DEBUG_VBL("crtc %u: dist from vblank start %d\n",
> + pipe, vpos);
>
> /* Bump counter if we are at >= leading edge of
> vblank,
> * but before vsync where vpos would turn negative and
> @@ -806,7 +806,7 @@ u32 radeon_get_vblank_counter_kms(struct drm_device *dev,
> int crtc)
> }
> else {
> /* Fallback to use value as is. */
> - count = radeon_get_vblank_counter(rdev, crtc);
> + count = radeon_get_vblank_counter(rdev, pipe);
> DRM_DEBUG_VBL("NULL mode info! Returned count may be wrong.\n");
> }
>
> --
> 2.5.0
>
> ___
> dri-devel mailing list
>
[PATCH 0/1] apple-gmux: Add initial documentation
Initial documentation for apple-gmux. If anyone has additions or corrections please let me know. This uses asciidoc markup, an HTML rendered version is available here: http://wunner.de/gpu_docs/handlers.html If you prefer perusing the patch in a browser: https://github.com/l1k/linux/commit/68eb066089346b4ba9aefdcbc69e66524427515e @Darren Hart: Barring any objections, please kindly provide an ack for merging via drm-next or drm-intel as I will post a new iteration of my GPU switching patches shortly which are based on this patch and which should also go in via drm-next/drm-intel. Thank you! Lukas Wunner (1): apple-gmux: Add initial documentation Documentation/DocBook/gpu.tmpl| 22 drivers/platform/x86/apple-gmux.c | 113 ++ 2 files changed, 135 insertions(+) -- 1.8.5.2 (Apple Git-48)
[PATCH 1/1] apple-gmux: Add initial documentation
Document what I've learned so far about the gmux so that we can
collaboratively reverse-engineer its remaining unknown bits
without everyone having to start from scratch.
The DOC sections are bound together in the gpu.tmpl DocBook
under a new vga_switcheroo "Handlers" chapter. Eventually
this should be amended with documentation about the four other
handlers that exist so far (nouveau v1 DSM, nouveau Optimus DSM,
radeon ATPX, amdgpu ATPX).
Requires kernel-doc with asciidoc support.
The EFI variable was reverse-engineered by Bruno Bierbaumer
and Andreas Heider .
Some of the remaining open questions:
* How are vblank intervals synchronized on retinas to achieve seamless
switching? Is the DP mux capable of this? It's not mentioned in the
data sheets. Or is it done at the OS level, i.e. do we have to
synchronize vblank intervals between DRM drivers? There's a signal
coming from the panel connector and going into gmux, could this be
the vblank signal as received by the panel to properly time the
switch?
* On retinas there's an I2C bus between gmux and the connector of the
right I/O board, apparently leading to the Parade PS8401A HDMI
repeater. What is this for, is it controlled via gmux registers?
Data sheet:
http://www.paradetech.com/products/jitter-cleaning-repeaters/ps8401/
* On retinas there's an I2C bus between gmux and the LED driver.
Pre-retinas connected the LED driver to SMBUS. Are there additional
gmux registers on retinas to control it?
* The MacPro6,1 2013 also has a gmux, the same Renesas R4F2113 as the
retina MacBook Pro. The Mac Pro doesn't have a built-in display,
so what is its purpose? Power control of the dual FirePro GPUs?
Switching of the external DP/Thunderbolt ports? The iFixit teardown
clearly shows one TI HD3SS212 DisplayPort mux on the logic board next
to one of the three Thunderbolt controllers. However six muxes would
be necessary to switch all six ports between GPUs. The mux is probably
necessary for one of the display configurations allowed by Apple,
but which one?
https://www.ifixit.com/Teardown/Mac+Pro+Late+2013+Teardown/20778
https://d3nevzfk7ii3be.cloudfront.net/igi/fELBTnt31QhnDsqq.huge
https://support.apple.com/en-us/HT202801
* Registers we haven't decoded yet:
0x700 32 Bit configmap?
0x708 32 Bit power sequence?
0x712 8 Bit status of clock from panel on retinas?
0x713 8 Bit dito?
0x724 16 Bit backlight, raw value?
0x760 32 Bit backlight
0x764 32 Bit backlight
0x768 8 Bit backlight
0x76a 16 Bit backlight
0x76c 16 Bit backlight
0x76e 16 Bit backlight
0x77fedp/dp/hdmi probe? retina only.
Signed-off-by: Lukas Wunner
---
Documentation/DocBook/gpu.tmpl| 22
drivers/platform/x86/apple-gmux.c | 113 ++
2 files changed, 135 insertions(+)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 225a246..9e95aa1 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -3658,8 +3658,30 @@ int num_ioctls;
+
+Handlers
+
+ apple-gmux Handler
+!Pdrivers/platform/x86/apple-gmux.c Overview
+!Pdrivers/platform/x86/apple-gmux.c Interrupt
+
+Graphics mux
+!Pdrivers/platform/x86/apple-gmux.c Graphics mux
+
+
+Power control
+!Pdrivers/platform/x86/apple-gmux.c Power control
+
+
+Backlight control
+!Pdrivers/platform/x86/apple-gmux.c Backlight control
+
+
+
+
!Cdrivers/gpu/vga/vga_switcheroo.c
!Cinclude/linux/vga_switcheroo.h
+!Cdrivers/platform/x86/apple-gmux.c
diff --git a/drivers/platform/x86/apple-gmux.c
b/drivers/platform/x86/apple-gmux.c
index aa58d41..f236250 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -3,6 +3,7 @@
*
* Copyright (C) Canonical Ltd.
* Copyright (C) 2010-2012 Andreas Heider
+ * Copyright (C) 2015 Lukas Wunner
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -26,6 +27,24 @@
#include
#include
+/**
+ * DOC: Overview
+ *
+ * :1: http://www.latticesemi.com/en/Products/FPGAandCPLD/LatticeXP2.aspx
+ * :2: http://www.renesas.com/products/mpumcu/h8s/h8s2100/h8s2113/index.jsp
+ *
+ * gmux is a microcontroller built into the MacBook Pro to support dual GPUs:
+ * A {1}[Lattice XP2] on pre-retinas, a {2}[Renesas R4F2113] on retinas.
+ *
+ * (The MacPro6,1 2013 also has a gmux, however it is unclear why since it has
+ * dual GPUs but no built-in display.)
+ *
+ * gmux is connected to the LPC bus of the southbridge. Its I/O ports are
+ * accessed differently depending on the microcontroller: Driver functions
+ * to access a pre-retina gmux are infixed `_pio_`, those for a retina gmux
+ * are infixed `_index_`.
+ */
+
struct apple_gmux_data {
unsigned long iostart;
unsigned long iolen;
@@ -247,6 +266,20 @@ static bool g
[PATCH] drm/radeon: Drop unnecessary unsigned int < 0 check
From: Thierry Reding
Unsigned integers can never be negative, so drop this check.
Cc: Christian König
Cc: Alex Deucher
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 4fab44e0f36b..414953c46a38 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -759,7 +759,7 @@ u32 radeon_get_vblank_counter_kms(struct drm_device *dev,
unsigned int pipe)
u32 count;
struct radeon_device *rdev = dev->dev_private;
- if (pipe < 0 || pipe >= rdev->num_crtc) {
+ if (pipe >= rdev->num_crtc) {
DRM_ERROR("Invalid crtc %u\n", pipe);
return -EINVAL;
}
--
2.5.0
[PATCH] drm/radeon: Update radeon_get_vblank_counter_kms()
On Mon, Jan 04, 2016 at 11:45:05AM -0500, Alex Deucher wrote:
> On Mon, Jan 4, 2016 at 10:44 AM, Thierry Reding
> wrote:
> > From: Thierry Reding
> >
> > Commit 88e72717c2de ("drm/irq: Use unsigned int pipe in public API")
> > updated the prototype of this function but not the implementation. This
> > wasn't noticed even through compile tests because the prototype is part
> > of the source file that uses it and hence the compiler won't know the
> > prototype when it compiles the implementation.
> >
> > The right thing would've been to move the prototype to a header that's
> > included in radeon_kms.c so that the implementation signature could be
> > checked against it, but the closest thing would've been radeon_drv.h
> > and including that results in a lot of build errors, so we'll leave it
> > as is for now.
> >
> > Cc: Christian König
> > Cc: Alex Deucher
> > Signed-off-by: Thierry Reding
> > ---
> > Changes in v2:
> > - remove unnecessary check for unsigned int < 0
>
> I had applied your previous patch before Michel's feedback so it's
> already in drm-next, any change you could spin a new patch to just
> drop the < 0 check?
Done.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160104/1d5ee0d6/attachment-0001.sig>
[PATCH 0/4] Component helper updates
On Mon, Dec 07, 2015 at 03:01:43PM +, Russell King - ARM Linux wrote: > Given the lack of interest in these patches, I've put these into my > "for-next" branch so that they can get some exposure in linux-next. These have been in for-next, and no one's reported any issues. I've now queued these into my for-linus branch in preparation to merging during the next merge window. > On Mon, Nov 23, 2015 at 04:02:11PM +, Russell King - ARM Linux wrote: > > Greg, > > > > These four patches update the component helper by: > > * Removing the legacy matching code with the .add_components method > > in the master's operation structure. Nothing in -rc1 appears to be > > using the legacy functions or method, according to my git greps. > > > > * A slight code reorganisation which results in slightly easier to read > > code. > > > > * Switch to tracking components via an array rather than a list, which > > allows us to keep the matching and matched components together, and > > more importantly allows us to reduce the amount of matching - with > > this structure, we can incrementally add the component devices as > > they become available, rather than re-running the list of matches > > each time something changes. > > > > * Fix the lack of match release functionality, which Liviu Dudau > > reminded me was missing. This allows people who want to pass > > device_node structures in to (correctly) retain the reference to the > > node, and drop the node when the need to do matches is no longer > > required. > > > > The first three patches have been well tested over the last year as I've > > had them in my tree that long. I hadn't considered them important enough > > to send as they're only removing and cleaning up functionality. However, > > with the need to fix something, it now makes sense to get them merged. > > > > The last patch has been tested with etnaviv DRM to prove that the match > > release works by unloading the module. On unload, the release function > > is correctly called. > > > > This is intended for the next merge window. Please apply. > > > > drivers/base/component.c | 281 > > -- > > include/linux/component.h | 33 -- > > 2 files changed, 167 insertions(+), 147 deletions(-) > > > > -- > > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > > according to speedtest.net. > > > > ___ > > linux-arm-kernel mailing list > > linux-arm-kernel at lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > -- > RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. > > ___ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH 0/4] drm DP MST fixes
I've applied these to my tree. Resending with Acks and stable cc'ed as per Dave's request. Mykola Lysenko (4): drm/dp/mst: process broadcast messages correctly drm/dp/mst: always send reply for UP request drm/dp/mst: fix in MSTB RAD initialization drm/dp/mst: fix in RAD element access drivers/gpu/drm/drm_dp_mst_topology.c | 141 +- include/drm/drm_dp_mst_helper.h | 2 - 2 files changed, 103 insertions(+), 40 deletions(-) -- 2.5.0
[PATCH 1/4] drm/dp/mst: process broadcast messages correctly
From: Mykola Lysenko
In case broadcast message received in UP request,
RAD cannot be used to identify message originator.
Message should be parsed, originator should be found
by GUID from parsed message.
Also reply with broadcast in case broadcast message
received (for now it is always broadcast)
Acked-by: Dave Airlie
Signed-off-by: Mykola Lysenko
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/drm_dp_mst_topology.c | 95 +++
1 file changed, 84 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index c5a942b..7710de6 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1215,6 +1215,50 @@ out:
return mstb;
}
+static struct drm_dp_mst_branch *get_mst_branch_device_by_guid_helper(
+ struct drm_dp_mst_branch *mstb,
+ uint8_t *guid)
+{
+ struct drm_dp_mst_branch *found_mstb;
+ struct drm_dp_mst_port *port;
+
+ list_for_each_entry(port, &mstb->ports, next) {
+ if (!port->mstb)
+ continue;
+
+ if (port->guid_valid && memcmp(port->guid, guid, 16) == 0)
+ return port->mstb;
+
+ found_mstb = get_mst_branch_device_by_guid_helper(port->mstb,
guid);
+
+ if (found_mstb)
+ return found_mstb;
+ }
+
+ return NULL;
+}
+
+static struct drm_dp_mst_branch *drm_dp_get_mst_branch_device_by_guid(
+ struct drm_dp_mst_topology_mgr *mgr,
+ uint8_t *guid)
+{
+ struct drm_dp_mst_branch *mstb;
+
+ /* find the port by iterating down */
+ mutex_lock(&mgr->lock);
+
+ if (mgr->guid_valid && memcmp(mgr->guid, guid, 16) == 0)
+ mstb = mgr->mst_primary;
+ else
+ mstb = get_mst_branch_device_by_guid_helper(mgr->mst_primary,
guid);
+
+ if (mstb)
+ kref_get(&mstb->kref);
+
+ mutex_unlock(&mgr->lock);
+ return mstb;
+}
+
static void drm_dp_check_and_send_link_address(struct drm_dp_mst_topology_mgr
*mgr,
struct drm_dp_mst_branch *mstb)
{
@@ -1325,6 +1369,7 @@ static int set_hdr_from_dst_qlock(struct
drm_dp_sideband_msg_hdr *hdr,
struct drm_dp_sideband_msg_tx *txmsg)
{
struct drm_dp_mst_branch *mstb = txmsg->dst;
+ u8 req_type;
/* both msg slots are full */
if (txmsg->seqno == -1) {
@@ -1341,7 +1386,13 @@ static int set_hdr_from_dst_qlock(struct
drm_dp_sideband_msg_hdr *hdr,
txmsg->seqno = 1;
mstb->tx_slots[txmsg->seqno] = txmsg;
}
- hdr->broadcast = 0;
+
+ req_type = txmsg->msg[0] & 0x7f;
+ if (req_type == DP_CONNECTION_STATUS_NOTIFY ||
+ req_type == DP_RESOURCE_STATUS_NOTIFY)
+ hdr->broadcast = 1;
+ else
+ hdr->broadcast = 0;
hdr->path_msg = txmsg->path_msg;
hdr->lct = mstb->lct;
hdr->lcr = mstb->lct - 1;
@@ -2157,28 +2208,50 @@ static int drm_dp_mst_handle_up_req(struct
drm_dp_mst_topology_mgr *mgr)
if (mgr->up_req_recv.have_eomt) {
struct drm_dp_sideband_msg_req_body msg;
- struct drm_dp_mst_branch *mstb;
+ struct drm_dp_mst_branch *mstb = NULL;
bool seqno;
- mstb = drm_dp_get_mst_branch_device(mgr,
-
mgr->up_req_recv.initial_hdr.lct,
-
mgr->up_req_recv.initial_hdr.rad);
- if (!mstb) {
- DRM_DEBUG_KMS("Got MST reply from unknown device %d\n",
mgr->up_req_recv.initial_hdr.lct);
- memset(&mgr->up_req_recv, 0, sizeof(struct
drm_dp_sideband_msg_rx));
- return 0;
+
+ if (!mgr->up_req_recv.initial_hdr.broadcast) {
+ mstb = drm_dp_get_mst_branch_device(mgr,
+
mgr->up_req_recv.initial_hdr.lct,
+
mgr->up_req_recv.initial_hdr.rad);
+ if (!mstb) {
+ DRM_DEBUG_KMS("Got MST reply from unknown
device %d\n", mgr->up_req_recv.initial_hdr.lct);
+ memset(&mgr->up_req_recv, 0, sizeof(struct
drm_dp_sideband_msg_rx));
+ return 0;
+ }
}
seqno = mgr->up_req_recv.initial_hdr.seqno;
drm_dp_sideband_parse_req(&mgr->up_req_recv, &msg);
if (msg.req_type == DP_CONNECTION_STATUS_NOTIFY) {
- drm_dp_send_up_ack_reply(mgr, mstb, msg.req_type,
seqno, false);
+ drm_dp_send_up_ack_reply(mgr, mgr->mst_primary,
msg.
[PATCH 2/4] drm/dp/mst: always send reply for UP request
From: Mykola Lysenko
We should always send reply for UP request in order
to make downstream device clean-up resources appropriately.
Issue was that reply for UP request was sent only once.
Acked-by: Dave Airlie
Signed-off-by: Mykola Lysenko
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/drm_dp_mst_topology.c | 30 +++---
include/drm/drm_dp_mst_helper.h | 2 --
2 files changed, 11 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 7710de6..ca92a32 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1494,26 +1494,18 @@ static void process_single_down_tx_qlock(struct
drm_dp_mst_topology_mgr *mgr)
}
/* called holding qlock */
-static void process_single_up_tx_qlock(struct drm_dp_mst_topology_mgr *mgr)
+static void process_single_up_tx_qlock(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_sideband_msg_tx *txmsg)
{
- struct drm_dp_sideband_msg_tx *txmsg;
int ret;
/* construct a chunk from the first msg in the tx_msg queue */
- if (list_empty(&mgr->tx_msg_upq)) {
- mgr->tx_up_in_progress = false;
- return;
- }
-
- txmsg = list_first_entry(&mgr->tx_msg_upq, struct
drm_dp_sideband_msg_tx, next);
ret = process_single_tx_qlock(mgr, txmsg, true);
- if (ret == 1) {
- /* up txmsgs aren't put in slots - so free after we send it */
- list_del(&txmsg->next);
- kfree(txmsg);
- } else if (ret)
+
+ if (ret != 1)
DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
- mgr->tx_up_in_progress = true;
+
+ txmsg->dst->tx_slots[txmsg->seqno] = NULL;
}
static void drm_dp_queue_down_tx(struct drm_dp_mst_topology_mgr *mgr,
@@ -1907,11 +1899,12 @@ static int drm_dp_send_up_ack_reply(struct
drm_dp_mst_topology_mgr *mgr,
drm_dp_encode_up_ack_reply(txmsg, req_type);
mutex_lock(&mgr->qlock);
- list_add_tail(&txmsg->next, &mgr->tx_msg_upq);
- if (!mgr->tx_up_in_progress) {
- process_single_up_tx_qlock(mgr);
- }
+
+ process_single_up_tx_qlock(mgr, txmsg);
+
mutex_unlock(&mgr->qlock);
+
+ kfree(txmsg);
return 0;
}
@@ -2843,7 +2836,6 @@ int drm_dp_mst_topology_mgr_init(struct
drm_dp_mst_topology_mgr *mgr,
mutex_init(&mgr->qlock);
mutex_init(&mgr->payload_lock);
mutex_init(&mgr->destroy_connector_lock);
- INIT_LIST_HEAD(&mgr->tx_msg_upq);
INIT_LIST_HEAD(&mgr->tx_msg_downq);
INIT_LIST_HEAD(&mgr->destroy_connector_list);
INIT_WORK(&mgr->work, drm_dp_mst_link_probe_work);
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 74b5888..4fc55a8 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -451,9 +451,7 @@ struct drm_dp_mst_topology_mgr {
the mstb tx_slots and txmsg->state once they are queued */
struct mutex qlock;
struct list_head tx_msg_downq;
- struct list_head tx_msg_upq;
bool tx_down_in_progress;
- bool tx_up_in_progress;
/* payload info + lock for it */
struct mutex payload_lock;
--
2.5.0
[PATCH 3/4] drm/dp/mst: fix in MSTB RAD initialization
From: Mykola Lysenko
This fix is needed to support more then two
branch displays, so RAD address consist at
least of 2 elements
Acked-by: Dave Airlie
Signed-off-by: Mykola Lysenko
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/drm_dp_mst_topology.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index ca92a32..d809ce8 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -978,17 +978,17 @@ static struct drm_dp_mst_port *drm_dp_get_port(struct
drm_dp_mst_branch *mstb, u
static u8 drm_dp_calculate_rad(struct drm_dp_mst_port *port,
u8 *rad)
{
- int lct = port->parent->lct;
+ int parent_lct = port->parent->lct;
int shift = 4;
- int idx = lct / 2;
- if (lct > 1) {
- memcpy(rad, port->parent->rad, idx);
- shift = (lct % 2) ? 4 : 0;
+ int idx = (parent_lct - 1) / 2;
+ if (parent_lct > 1) {
+ memcpy(rad, port->parent->rad, idx + 1);
+ shift = (parent_lct % 2) ? 4 : 0;
} else
rad[0] = 0;
rad[idx] |= port->port_num << shift;
- return lct + 1;
+ return parent_lct + 1;
}
/*
--
2.5.0
[PATCH 4/4] drm/dp/mst: fix in RAD element access
From: Mykola Lysenko
This is needed to receive correct port
number from RAD, so MSTB could be found
Acked-by: Dave Airlie
Signed-off-by: Mykola Lysenko
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index d809ce8..6ed90a2 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1044,7 +1044,7 @@ static void build_mst_prop_path(const struct
drm_dp_mst_branch *mstb,
snprintf(proppath, proppath_size, "mst:%d", mstb->mgr->conn_base_id);
for (i = 0; i < (mstb->lct - 1); i++) {
int shift = (i % 2) ? 0 : 4;
- int port_num = mstb->rad[i / 2] >> shift;
+ int port_num = (mstb->rad[i / 2] >> shift) & 0xf;
snprintf(temp, sizeof(temp), "-%d", port_num);
strlcat(proppath, temp, proppath_size);
}
@@ -1195,7 +1195,7 @@ static struct drm_dp_mst_branch
*drm_dp_get_mst_branch_device(struct drm_dp_mst_
for (i = 0; i < lct - 1; i++) {
int shift = (i % 2) ? 0 : 4;
- int port_num = rad[i / 2] >> shift;
+ int port_num = (rad[i / 2] >> shift) & 0xf;
list_for_each_entry(port, &mstb->ports, next) {
if (port->port_num == port_num) {
--
2.5.0
[PATCH] drm/radeon: Drop unnecessary unsigned int < 0 check
On Mon, Jan 4, 2016 at 12:19 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Unsigned integers can never be negative, so drop this check.
>
> Cc: Christian König
> Cc: Alex Deucher
> Signed-off-by: Thierry Reding
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 4fab44e0f36b..414953c46a38 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -759,7 +759,7 @@ u32 radeon_get_vblank_counter_kms(struct drm_device *dev,
> unsigned int pipe)
> u32 count;
> struct radeon_device *rdev = dev->dev_private;
>
> - if (pipe < 0 || pipe >= rdev->num_crtc) {
> + if (pipe >= rdev->num_crtc) {
> DRM_ERROR("Invalid crtc %u\n", pipe);
> return -EINVAL;
> }
> --
> 2.5.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 00/13] MT8173 DRM support
Hi,
this MT8173 DRM update changes the clock bindings once more, as the MIPI_TX
D-PHY and the HDMI PHY have internal PLLs that are better abstracted using
the common clock framework. The clock outputs of the PHY modules are routed
to the respective encoders, in the HDMI case by way of the TOP clock module.
I'd like it if Michael or Stephen could take a look at the clock patches and
maybe give an Ack or a Nope for this to be merged through the DRM tree.
Various other issues have been fixed, for more details see the individual
patches.
Some changes since v7:
- Added PLL reference input clocks and output clocks to the MIPI TX D-PHY and
HDMI PHY nodes
- Added HS input clocks to the MIPI DSI encoder nodes
- Dropped the hdmitx_dig_cts clock from the TOP dividers, it is not a child
of tvdpll_445p5m anyway. This clock signal really is provided by the HDMI PHY
- Added "power-domains" properties to all nodes in the MM domain
- Documented the merge and split function block bindings
- Merged Daniel's wait for exclusive fences on incoming framebuffers
using reservation_object_wait_timeout_rcu in .atomic_complete() into
the DRM driver patch. This allowed to drop the drm/atomic-helper
wait_for_fences export patch again.
- Added missing atomic destroy_state callbacks, cleaned up reset callbacks
- Added a pending_planes flag to mtk_crtc so we can atomically update the
plane configuration
- Fixed OD ddp_comp function setup
- Separated enabling MIPI TX phy output from enabling the PLL (via CCF),
this allows to keep the pixel clock running separately from the encoder
output when disabling the crtc, to wait for the last vblank.
- Fixed mtk_dpi_power_on reference counting
- Fill ELD info in the HDMI driver, for future audio support.
- Renamed the MT8173 specific HDMI PHY driver, as MT2701 has a different PHY.
- Update iommus binding to v7 IOMMU patches.
The following patches are needed to cleanly apply the device tree changes on
top of v4.4-rc1:
61aee9342514 ("arm64: dts: mt8173: add MT8173 display PWM driver support node")
from https://github.com/mbgg/linux-mediatek.git v4.4-next/arm64
https://patchwork.kernel.org/patch/7880431/ ("dts: mt8173: Add iommu/smi nodes
for mt8173")
And to build:
https://patchwork.kernel.org/patch/7880301/ ("dt-bindings: mediatek: Add smi
dts binding")
https://patchwork.kernel.org/patch/7880321/ ("memory: mediatek: Add SMI driver")
CK Hu (5):
dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
drm/mediatek: Add DSI sub driver
arm64: dts: mt8173: Add display subsystem related nodes
arm64: dts: mt8173: Add HDMI related nodes
Jie Qiu (3):
drm/mediatek: Add DPI sub driver
drm/mediatek: Add HDMI support
drm/mediatek: enable hdmi output control bit
Philipp Zabel (5):
dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding
clk: mediatek: make dpi0_sel propagate rate changes
clk: mediatek: Add hdmi_ref HDMI PHY PLL reference clock output
dt-bindings: hdmi-connector: add DDC I2C bus phandle documentation
clk: mediatek: remove hdmitx_dig_cts from TOP clocks
.../bindings/display/connector/hdmi-connector.txt | 1 +
.../bindings/display/mediatek/mediatek,disp.txt| 203 +
.../bindings/display/mediatek/mediatek,dpi.txt | 35 +
.../bindings/display/mediatek/mediatek,dsi.txt | 60 ++
.../bindings/display/mediatek/mediatek,hdmi.txt| 148
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 312
drivers/clk/mediatek/clk-mt8173.c | 8 +-
drivers/clk/mediatek/clk-mtk.h | 7 +-
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/mediatek/Kconfig | 22 +
drivers/gpu/drm/mediatek/Makefile | 22 +
drivers/gpu/drm/mediatek/mtk_cec.c | 245 ++
drivers/gpu/drm/mediatek/mtk_cec.h | 25 +
drivers/gpu/drm/mediatek/mtk_disp_ovl.c| 301
drivers/gpu/drm/mediatek/mtk_dpi.c | 737 ++
drivers/gpu/drm/mediatek/mtk_dpi.h | 84 ++
drivers/gpu/drm/mediatek/mtk_dpi_regs.h| 228 ++
drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 603 +++
drivers/gpu/drm/mediatek/mtk_drm_crtc.h| 32 +
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 355 +
drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 41 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 275 +++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 148
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 581 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 55 ++
drivers/gpu/drm/mediatek/mtk_drm_fb.c | 165
drivers/gpu/drm/mediatek/mtk_drm_fb.h | 29 +
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 227 ++
[PATCH v8 01/13] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
From: CK Hu
Add device tree binding documentation for the display subsystem in
Mediatek MT8173 SoCs.
Signed-off-by: CK Hu
Signed-off-by: Philipp Zabel
Acked-by: Rob Herring
---
Changes since v7:
- Add 26 MHz PLL reference input clocks and DSI high-speed output clocks
to the MIPI TX D-PHY nodes
- Add HS input clocks to the MIPI DSI encoder nodes
- Add power-domains property to all nodes in the MM domain
- Document the merge and split blocks
---
.../bindings/display/mediatek/mediatek,disp.txt| 203 +
.../bindings/display/mediatek/mediatek,dpi.txt | 35
.../bindings/display/mediatek/mediatek,dsi.txt | 60 ++
3 files changed, 298 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
new file mode 100644
index 000..db6e77e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -0,0 +1,203 @@
+Mediatek display subsystem
+==
+
+The Mediatek display subsystem consists of various DISP function blocks in the
+MMSYS register space. The connections between them can be configured by output
+and input selectors in the MMSYS_CONFIG register space. Pixel clock and start
+of frame signal are distributed to the other function blocks by a DISP_MUTEX
+function block.
+
+All DISP device tree nodes must be siblings to the central MMSYS_CONFIG node.
+For a description of the MMSYS_CONFIG binding, see
+Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt.
+
+DISP function blocks
+
+
+A display stream starts at a source function block that reads pixel data from
+memory and ends with a sink function block that drives pixels on a display
+interface, or writes pixels back to memory. All DISP function blocks have
+their own register space, interrupt, and clock gate. The blocks that can
+access memory additionally have to list the IOMMU and local arbiter they are
+connected to.
+
+For a description of the display interface sink function blocks, see
+Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt and
+Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt.
+
+Required properties (all function blocks):
+- compatible: "mediatek,-disp-", one of
+ "mediatek,-disp-ovl" - overlay (4 layers, blending, csc)
+ "mediatek,-disp-rdma" - read DMA / line buffer
+ "mediatek,-disp-wdma" - write DMA
+ "mediatek,-disp-color" - color processor
+ "mediatek,-disp-aal" - adaptive ambient light controller
+ "mediatek,-disp-gamma" - gamma correction
+ "mediatek,-disp-merge" - merge streams from two RDMA sources
+ "mediatek,-disp-split" - split stream to two encoders
+ "mediatek,-disp-ufoe" - data compression engine
+ "mediatek,-dsi"- DSI controller, see mediatek,dsi.txt
+ "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt
+ "mediatek,-disp-mutex" - display mutex
+ "mediatek,-disp-od"- overdrive
+- reg: Physical base address and length of the function block register space
+- interrupts: The interrupt signal from the function block (required, except
for
+ merge and split function blocks).
+- clocks: device clocks
+ See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+ For most function blocks this is just a single clock input. Only the DSI and
+ DPI controller nodes have multiple clock inputs. These are documented in
+ mediatek,dsi.txt and mediatek,dpi.txt, respectively.
+
+Required properties (DMA function blocks):
+- compatible: Should be one of
+ "mediatek,-disp-ovl"
+ "mediatek,-disp-rdma"
+ "mediatek,-disp-wdma"
+- larb: Should contain a phandle pointing to the local arbiter device as
defined
+ in Documentation/devicetree/bindings/soc/mediatek/mediatek,smi-larb.txt
+- iommus: Should point to the respective IOMMU block with master port as
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ for details.
+
+Examples:
+
+mmsys: clock-controller at 1400 {
+ compatible = "mediatek,mt8173-mmsys", "syscon";
+ reg = <0 0x1400 0 0x1000>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ #clock-cells = <1>;
+};
+
+ovl0: ovl at 1400c000 {
+ compatible = "mediatek,mt8173-disp-ovl";
+ reg = <0 0x1400c000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ clocks = <&mmsys CLK_MM_DISP_OVL0>;
+ iommus = <&iommu M4U_PORT_DISP_OVL0>;
+ mediatek,larb = <&larb0>;
+};
+
+ovl1: ovl at 1400d000 {
+ compatible = "mediatek,mt8
[PATCH v8 02/13] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
From: CK Hu This patch adds an initial DRM driver for the Mediatek MT8173 DISP subsystem. It currently supports two fixed output streams from the OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively. Signed-off-by: CK Hu Signed-off-by: YT Shen Signed-off-by: Daniel Kurtz Signed-off-by: Philipp Zabel --- Changes since v7: - Move PANEL and MIPI_DSI config selection to later patches - Sort object files alphabetically in Makefile - Drop mtk_crtc->pipe, use drm_crtc_handle_vblank instead - Move copied event from mtk_crtc_state back to mtk_crtc - Wait for exclusive fences on incoming framebuffers using reservation_object_wait_timeout_rcu in .atomic_complete(). - Add missing atomic destroy_state callbacks - Rename mtk_crtc_ddp_power_on/of to _clk_enable/disable - Add a pending_planes flag to mtk_crtc so we can atomically update the plane configuration - Fold mtk_drm_crtc_commit into mtk_drm_crtc_atomic_flush - Make all ddp_comp callbacks take a struct mtk_ddp_comp * first parameter. - Fix OD ddp_comp function setup - Defer until iommu is present - Fix probe error path - Relax some writels --- drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/mediatek/Kconfig| 12 + drivers/gpu/drm/mediatek/Makefile | 10 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 301 ++ drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 603 drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 32 ++ drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 355 drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 41 ++ drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 275 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 148 +++ drivers/gpu/drm/mediatek/mtk_drm_drv.c | 577 ++ drivers/gpu/drm/mediatek/mtk_drm_drv.h | 52 +++ drivers/gpu/drm/mediatek/mtk_drm_fb.c | 165 drivers/gpu/drm/mediatek/mtk_drm_fb.h | 29 ++ drivers/gpu/drm/mediatek/mtk_drm_gem.c | 227 +++ drivers/gpu/drm/mediatek/mtk_drm_gem.h | 55 +++ drivers/gpu/drm/mediatek/mtk_drm_plane.c| 242 +++ drivers/gpu/drm/mediatek/mtk_drm_plane.h| 59 +++ 19 files changed, 3186 insertions(+) create mode 100644 drivers/gpu/drm/mediatek/Kconfig create mode 100644 drivers/gpu/drm/mediatek/Makefile create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ovl.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.h create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.h create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.h create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.h create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.h create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.h diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index c4bf9a1..8fdb0c2 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -266,3 +266,5 @@ source "drivers/gpu/drm/amd/amdkfd/Kconfig" source "drivers/gpu/drm/imx/Kconfig" source "drivers/gpu/drm/vc4/Kconfig" + +source "drivers/gpu/drm/mediatek/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 1e9ff4c..607a49f 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_DRM_MSM) += msm/ obj-$(CONFIG_DRM_TEGRA) += tegra/ obj-$(CONFIG_DRM_STI) += sti/ obj-$(CONFIG_DRM_IMX) += imx/ +obj-$(CONFIG_DRM_MEDIATEK) += mediatek/ obj-y += i2c/ obj-y += panel/ obj-y += bridge/ diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig new file mode 100644 index 000..8dad892 --- /dev/null +++ b/drivers/gpu/drm/mediatek/Kconfig @@ -0,0 +1,12 @@ +config DRM_MEDIATEK + tristate "DRM Support for Mediatek SoCs" + depends on DRM + depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST) + select DRM_KMS_HELPER + select IOMMU_DMA + select MTK_SMI + help + Choose this option if you have a Mediatek SoCs. + The module will be called mediatek-drm + This driver provides kernel mode setting and + buffer management to userspace. diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile new file mode 100644 index 000..c7cc41a --- /dev/null +++ b/drivers/gpu/drm/mediatek/Makefile @@ -0,0 +1,10 @@ +mediatek-drm-y := mtk_disp_ovl.o \ + mtk
[PATCH v8 03/13] drm/mediatek: Add DSI sub driver
From: CK Hu
This patch add a drm encoder/connector driver for the MIPI DSI function
block of the Mediatek display subsystem and a phy driver for the MIPI TX
D-PHY control module.
Signed-off-by: Jitao Shi
Signed-off-by: Philipp Zabel
---
Changes since v7:
- Select the PANEL and MIPI_DSI config options
- Separate enabling MIPI TX phy output from enabling the PLL
- Make the PLL controllable via the common clock framework via
the D-PHY's high-speed clock output to the DSI encoder
---
drivers/gpu/drm/mediatek/Kconfig | 3 +
drivers/gpu/drm/mediatek/Makefile | 4 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +
drivers/gpu/drm/mediatek/mtk_dsi.c | 847 +
drivers/gpu/drm/mediatek/mtk_dsi.h | 58 +++
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 487 +++
7 files changed, 1402 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/mediatek/mtk_dsi.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_dsi.h
create mode 100644 drivers/gpu/drm/mediatek/mtk_mipi_tx.c
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index 8dad892..b7e0404 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -3,6 +3,9 @@ config DRM_MEDIATEK
depends on DRM
depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST)
select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
+ select DRM_PANEL
+ select DRM_PANEL_SIMPLE
select IOMMU_DMA
select MTK_SMI
help
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index c7cc41a..e1a40f4 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -5,6 +5,8 @@ mediatek-drm-y := mtk_disp_ovl.o \
mtk_drm_drv.o \
mtk_drm_fb.o \
mtk_drm_gem.o \
- mtk_drm_plane.o
+ mtk_drm_plane.o \
+ mtk_dsi.o \
+ mtk_mipi_tx.o
obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 9db22b4..39267f9 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -536,6 +536,8 @@ static struct platform_driver mtk_drm_platform_driver = {
static struct platform_driver * const mtk_drm_drivers[] = {
&mtk_drm_platform_driver,
&mtk_disp_ovl_driver,
+ &mtk_dsi_driver,
+ &mtk_mipi_tx_driver,
};
static int __init mtk_drm_init(void)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index 75e1b7d..e86c19e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -48,5 +48,7 @@ struct mtk_drm_private {
};
extern struct platform_driver mtk_disp_ovl_driver;
+extern struct platform_driver mtk_dsi_driver;
+extern struct platform_driver mtk_mipi_tx_driver;
#endif /* MTK_DRM_DRV_H */
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
new file mode 100644
index 000..6ab5a31
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -0,0 +1,847 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mtk_dsi.h"
+
+#define DSI_VIDEO_FIFO_DEPTH (1920 / 4)
+#define DSI_HOST_FIFO_DEPTH64
+
+#define DSI_START 0x00
+
+#define DSI_CON_CTRL 0x10
+#define DSI_RESET BIT(0)
+#define DSI_EN BIT(1)
+
+#define DSI_MODE_CTRL 0x14
+#define MODE (3)
+#define CMD_MODE 0
+#define SYNC_PULSE_MODE1
+#define SYNC_EVENT_MODE2
+#define BURST_MODE 3
+#define FRM_MODE BIT(16)
+#define MIX_MODE BIT(17)
+
+#define DSI_TXRX_CTRL 0x18
+#define VC_NUM (2 << 0)
+#define LANE_NUM (0xf << 2)
+#define DIS_EOTBIT(6)
+#define NULL_ENBIT(7)
+#define TE_FREERUN BIT(8)
+#define EXT_TE_EN BIT(9)
+#define EXT_TE_EDGEBIT(10)
+#define MAX_RTN_SIZE (0xf << 12)
+#defi
[PATCH v8 05/13] dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding
Add the device tree binding documentation for Mediatek HDMI,
HDMI PHY and HDMI DDC devices.
Signed-off-by: Philipp Zabel
Acked-by: Rob Herring
---
Changes since v7:
- Add the HDMI PLL clock output that is fed back into the
TOP clock module.
- Switch the hdmi_sel mux to it in the example.
---
.../bindings/display/mediatek/mediatek,hdmi.txt| 148 +
1 file changed, 148 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
new file mode 100644
index 000..7b12424
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
@@ -0,0 +1,148 @@
+Mediatek HDMI Encoder
+=
+
+The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from
+its parallel input.
+
+Required properties:
+- compatible: Should be "mediatek,-hdmi".
+- reg: Physical base address and length of the controller's registers
+- interrupts: The interrupt signal from the function block.
+- clocks: device clocks
+ See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must contain "pixel", "pll", "bclk", and "spdif".
+- phys: phandle link to the HDMI PHY node.
+ See Documentation/devicetree/bindings/phy/phy-bindings.txt for details.
+- phy-names: must contain "hdmi"
+- mediatek,syscon-hdmi: phandle link and register offset to the system
+ configuration registers. For mt8173 this must be offset 0x900 into the
+ MMSYS_CONFIG region: <&mmsys 0x900>.
+- ports: A node containing input and output port nodes with endpoint
+ definitions as documented in Documentation/devicetree/bindings/graph.txt.
+- port at 0: The input port in the ports node should be connected to a DPI
output
+ port.
+- port at 1: The output port in the ports node should be connected to the input
+ port of a connector node that contains a ddc-i2c-bus property, or to the
+ input port of an attached bridge chip, such as a SlimPort transmitter.
+
+HDMI CEC
+
+
+The HDMI CEC controller handles hotplug detection and CEC communication.
+
+Required properties:
+- compatible: Should be "mediatek,-cec"
+- reg: Physical base address and length of the controller's registers
+- interrupts: The interrupt signal from the function block.
+- clocks: device clock
+
+HDMI DDC
+
+
+The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
+The Mediatek's I2C controller is used to interface with I2C devices.
+
+Required properties:
+- compatible: Should be "mediatek,-hdmi-ddc"
+- reg: Physical base address and length of the controller's registers
+- clocks: device clock
+- clock-names: Should be "ddc-i2c".
+
+HDMI PHY
+
+
+The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
+output and drives the HDMI pads.
+
+Required properties:
+- compatible: "mediatek,-hdmi-phy"
+- reg: Physical base address and length of the module's registers
+- clocks: PLL reference clock
+- clock-names: must contain "pll_ref"
+- clock-output-names: must be "hdmitx_dig_cts" on mt8173
+- #phy-cells: must be <0>
+- #clock-cells: must be <0>
+
+Optional properties:
+- mediatek,ibias: TX DRV bias current for <1.65Gbps, defaults to 0xa
+- mediatek,ibias_up: TX DRV bias current for >1.65Gbps, defaults to 0x1c
+
+Example:
+
+cec: cec at 10013000 {
+ compatible = "mediatek,mt8173-cec";
+ reg = <0 0x10013000 0 0xbc>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_CEC>;
+};
+
+hdmi_phy: hdmi-phy at 10209100 {
+ compatible = "mediatek,mt8173-hdmi-phy";
+ reg = <0 0x10209100 0 0x24>;
+ clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
+ clock-names = "pll_ref";
+ clock-output-names = "hdmitx_dig_cts";
+ mediatek,ibias = <0xa>;
+ mediatek,ibias_up = <0x1c>;
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+};
+
+hdmi_ddc0: i2c at 11012000 {
+ compatible = "mediatek,mt8173-hdmi-ddc";
+ reg = <0 0x11012000 0 0x1c>;
+ interrupts = ;
+ clocks = <&pericfg CLK_PERI_I2C5>;
+ clock-names = "ddc-i2c";
+};
+
+hdmi0: hdmi at 14025000 {
+ compatible = "mediatek,mt8173-hdmi";
+ reg = <0 0x14025000 0 0x400>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_HDMI_PIXEL>,
+<&mmsys CLK_MM_HDMI_PLLCK>,
+<&mmsys CLK_MM_HDMI_AUDIO>,
+<&mmsys CLK_MM_HDMI_SPDIF>;
+ clock-names = "pixel", "pll", "bclk", "spdif";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_pin>;
+ phys = <&hdmi_phy>;
+ phy-names = "hdmi";
+ mediatek,syscon-hdmi = <&mmsys 0x900>;
+ assigned-clocks = <&topckgen CLK_TOP_HDMI_SEL>;
+ assigned-clock-parents = <&hdmi_phy>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+
[PATCH v8 04/13] drm/mediatek: Add DPI sub driver
From: Jie Qiu
Add DPI connector/encoder to support HDMI output via the
attached HDMI bridge.
Signed-off-by: Jie Qiu
Signed-off-by: Philipp Zabel
---
Changes since v7:
- Fix mtk_dpi_power_on reference counting
- Make mtk_dpi_power_off return void
---
drivers/gpu/drm/mediatek/Makefile | 3 +-
drivers/gpu/drm/mediatek/mtk_dpi.c | 737
drivers/gpu/drm/mediatek/mtk_dpi.h | 84
drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 228 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
6 files changed, 1053 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/mediatek/mtk_dpi.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_dpi.h
create mode 100644 drivers/gpu/drm/mediatek/mtk_dpi_regs.h
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index e1a40f4..218071c 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -7,6 +7,7 @@ mediatek-drm-y := mtk_disp_ovl.o \
mtk_drm_gem.o \
mtk_drm_plane.o \
mtk_dsi.o \
- mtk_mipi_tx.o
+ mtk_mipi_tx.o \
+ mtk_dpi.o
obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
new file mode 100644
index 000..48eafa0
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -0,0 +1,737 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Jie Qiu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mtk_dpi.h"
+#include "mtk_dpi_regs.h"
+
+enum mtk_dpi_polarity {
+ MTK_DPI_POLARITY_RISING,
+ MTK_DPI_POLARITY_FALLING,
+};
+
+struct mtk_dpi_polarities {
+ enum mtk_dpi_polarity de_pol;
+ enum mtk_dpi_polarity ck_pol;
+ enum mtk_dpi_polarity hsync_pol;
+ enum mtk_dpi_polarity vsync_pol;
+};
+
+struct mtk_dpi_sync_param {
+ u32 sync_width;
+ u32 front_porch;
+ u32 back_porch;
+ bool shift_half_line;
+};
+
+struct mtk_dpi_yc_limit {
+ u16 y_top;
+ u16 y_bottom;
+ u16 c_top;
+ u16 c_bottom;
+};
+
+static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
+{
+ u32 tmp = readl(dpi->regs + offset) & ~mask;
+
+ tmp |= (val & mask);
+ writel(tmp, dpi->regs + offset);
+}
+
+static void mtk_dpi_sw_reset(struct mtk_dpi *dpi, bool reset)
+{
+ mtk_dpi_mask(dpi, DPI_RET, reset ? RST : 0, RST);
+}
+
+static void mtk_dpi_enable(struct mtk_dpi *dpi)
+{
+ mtk_dpi_mask(dpi, DPI_EN, EN, EN);
+}
+
+static void mtk_dpi_disable(struct mtk_dpi *dpi)
+{
+ mtk_dpi_mask(dpi, DPI_EN, 0, EN);
+}
+
+static void mtk_dpi_config_hsync(struct mtk_dpi *dpi,
+struct mtk_dpi_sync_param *sync)
+{
+ mtk_dpi_mask(dpi, DPI_TGEN_HWIDTH,
+ sync->sync_width << HPW, HPW_MASK);
+ mtk_dpi_mask(dpi, DPI_TGEN_HPORCH,
+ sync->back_porch << HBP, HBP_MASK);
+ mtk_dpi_mask(dpi, DPI_TGEN_HPORCH, sync->front_porch << HFP,
+ HFP_MASK);
+}
+
+static void mtk_dpi_config_vsync(struct mtk_dpi *dpi,
+struct mtk_dpi_sync_param *sync,
+u32 width_addr, u32 porch_addr)
+{
+ mtk_dpi_mask(dpi, width_addr,
+sync->sync_width << VSYNC_WIDTH_SHIFT,
+VSYNC_WIDTH_MASK);
+ mtk_dpi_mask(dpi, width_addr,
+sync->shift_half_line << VSYNC_HALF_LINE_SHIFT,
+VSYNC_HALF_LINE_MASK);
+ mtk_dpi_mask(dpi, porch_addr,
+sync->back_porch << VSYNC_BACK_PORCH_SHIFT,
+VSYNC_BACK_PORCH_MASK);
+ mtk_dpi_mask(dpi, porch_addr,
+sync->front_porch << VSYNC_FRONT_PORCH_SHIFT,
+VSYNC_FRONT_PORCH_MASK);
+}
+
+static void mtk_dpi_config_vsync_lodd(struct mtk_dpi *dpi,
+ struct mtk_dpi_sync_param *sync)
+{
+ mtk_dpi_config_vsync(dpi, sync, DPI_TGEN_VWIDTH, DPI_TGEN_VPORCH);
+}
+
+static void mtk_dpi_config_vsync_leven(struct mtk_dpi *dpi,
+ struct mtk_dpi_sync_param *sync)
+{
+ mtk_dpi_config_vsync(dpi, sync, DPI_TGEN_VWIDTH_LEVEN,
+DPI_TGEN_VPORCH_LEVEN);
+}
+
+static void mtk_dpi_config_vsyn
[PATCH v8 06/13] drm/mediatek: Add HDMI support
From: Jie Qiu This patch adds drivers for the HDMI bridge connected to the DPI0 display subsystem function block, for the HDMI DDC block, and for the HDMI PHY to support HDMI output. Signed-off-by: Jie Qiu Signed-off-by: Philipp Zabel --- Changes since v7: - Fill ELD info - Fix error messages - Replace hpd_event_data with the hdmi encoder device - Rename MT8173 specific HDMI PHY driver, MT2701 has a different PHY. - Register the PLL in the HDMI PHY module with the common clock framework. Its output hdmitx_dig_cts is routed back into the TOP clock module. - Fold contents of public mtk_hdmi_audio.h header into private mtk_hdmi.h header. --- drivers/gpu/drm/mediatek/Kconfig | 7 + drivers/gpu/drm/mediatek/Makefile | 9 + drivers/gpu/drm/mediatek/mtk_cec.c | 245 drivers/gpu/drm/mediatek/mtk_cec.h | 25 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 + drivers/gpu/drm/mediatek/mtk_drm_hdmi_drv.c| 610 drivers/gpu/drm/mediatek/mtk_hdmi.c| 482 drivers/gpu/drm/mediatek/mtk_hdmi.h| 231 drivers/gpu/drm/mediatek/mtk_hdmi_ddc_drv.c| 362 drivers/gpu/drm/mediatek/mtk_hdmi_hw.c | 757 + drivers/gpu/drm/mediatek/mtk_hdmi_hw.h | 76 +++ drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 221 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 506 + 13 files changed, 3532 insertions(+) create mode 100644 drivers/gpu/drm/mediatek/mtk_cec.c create mode 100644 drivers/gpu/drm/mediatek/mtk_cec.h create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_hdmi_drv.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi.h create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_ddc_drv.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_hw.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_hw.h create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_regs.h create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig index b7e0404..829ab66 100644 --- a/drivers/gpu/drm/mediatek/Kconfig +++ b/drivers/gpu/drm/mediatek/Kconfig @@ -13,3 +13,10 @@ config DRM_MEDIATEK The module will be called mediatek-drm This driver provides kernel mode setting and buffer management to userspace. + +config DRM_MEDIATEK_HDMI + tristate "DRM HDMI Support for Mediatek SoCs" + depends on DRM_MEDIATEK + select GENERIC_PHY + help + DRM/KMS HDMI driver for Mediatek SoCs diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile index 218071c..2a81eeb 100644 --- a/drivers/gpu/drm/mediatek/Makefile +++ b/drivers/gpu/drm/mediatek/Makefile @@ -11,3 +11,12 @@ mediatek-drm-y := mtk_disp_ovl.o \ mtk_dpi.o obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o + +mediatek-drm-hdmi-objs := mtk_cec.o \ + mtk_drm_hdmi_drv.o \ + mtk_hdmi.o \ + mtk_hdmi_ddc_drv.o \ + mtk_hdmi_hw.o \ + mtk_mt8173_hdmi_phy.o + +obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c b/drivers/gpu/drm/mediatek/mtk_cec.c new file mode 100644 index 000..cba3647 --- /dev/null +++ b/drivers/gpu/drm/mediatek/mtk_cec.c @@ -0,0 +1,245 @@ +/* + * Copyright (c) 2014 MediaTek Inc. + * Author: Jie Qiu + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#include +#include +#include +#include +#include + +#include "mtk_cec.h" + +#define TR_CONFIG 0x00 +#define CLEAR_CEC_IRQ BIT(15) + +#define CEC_CKGEN 0x04 +#define CEC_32K_PDNBIT(19) +#define PDNBIT(16) + +#define RX_EVENT 0x54 +#define HDMI_PORD BIT(25) +#define HDMI_HTPLG BIT(24) +#define HDMI_PORD_INT_EN BIT(9) +#define HDMI_HTPLG_INT_EN BIT(8) + +#define RX_GEN_WD 0x58 +#define HDMI_PORD_INT_32K_STATUS BIT(26) +#define RX_RISC_INT_32K_STATUS BIT(25) +#define HDMI_HTPLG_INT_32K_STATUS BIT(24) +#define HDMI_PORD_INT_32K_CLR BIT(18) +#define RX_INT_32K_CLR BIT(17) +#define HDMI_HTPLG_INT_32K_CLR BIT(16) +#define HDMI_PORD_INT_32K_STA_MASK BIT(10) +#define RX_RISC_INT
[PATCH v8 07/13] drm/mediatek: enable hdmi output control bit
From: Jie Qiu
MT8173 HDMI hardware has a output control bit to enable/disable HDMI
output. Because of security reason, so this bit can ONLY be controlled
in ARM supervisor mode. Now the only way to enter ARM supervisor is the
ARM trusted firmware. So atf provides a API for HDMI driver to call to
setup this HDMI control bit to enable HDMI output in supervisor mode.
Signed-off-by: Jie Qiu
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/mediatek/mtk_hdmi_hw.c | 11 +++
drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_hw.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_hw.c
index 7652266..8bee167 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_hw.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_hw.c
@@ -19,8 +19,15 @@
#include
#include
#include
+#include
#include
+static int (*invoke_psci_fn)(u64, u64, u64, u64);
+typedef int (*psci_initcall_t)(const struct device_node *);
+
+asmlinkage int __invoke_psci_fn_hvc(u64, u64, u64, u64);
+asmlinkage int __invoke_psci_fn_smc(u64, u64, u64, u64);
+
static u32 mtk_hdmi_read(struct mtk_hdmi *hdmi, u32 offset)
{
return readl(hdmi->regs + offset);
@@ -170,6 +177,10 @@ void mtk_hdmi_hw_vid_black(struct mtk_hdmi *hdmi,
void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi *hdmi, bool enable)
{
+ invoke_psci_fn = __invoke_psci_fn_smc;
+ invoke_psci_fn(MTK_SIP_SET_AUTHORIZED_SECURE_REG,
+ 0x14000904, 0x8000, 0);
+
regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
HDMI_PCLK_FREE_RUN, enable ? HDMI_PCLK_FREE_RUN : 0);
regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
index de7ee22..8d7d60a 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
@@ -218,4 +218,5 @@
#define MHL_SYNC_AUTO_EN BIT(30)
#define HDMI_PCLK_FREE_RUN BIT(31)
+#define MTK_SIP_SET_AUTHORIZED_SECURE_REG 0x8201
#endif
--
2.6.2
[PATCH v8 08/13] arm64: dts: mt8173: Add display subsystem related nodes
From: CK Hu
This patch adds the device nodes for the DISP function blocks
comprising the display subsystem.
Signed-off-by: CK Hu
Signed-off-by: Cawa Cheng
Signed-off-by: Jie Qiu
Signed-off-by: Daniel Kurtz
Signed-off-by: Philipp Zabel
---
Changes since v7:
- Add 26 MHz PLL reference input clock and the high-speed output clock to
the MIPI TX D-PHY nodes
- The HS output clock is routed to the DSI encoder module
- Add power-domains property to all nodes in the MM domain
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 237 +++
1 file changed, 237 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 4901f13..68c1cb2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -25,6 +25,23 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ ovl0 = &ovl0;
+ ovl1 = &ovl1;
+ rdma0 = &rdma0;
+ rdma1 = &rdma1;
+ rdma2 = &rdma2;
+ wdma0 = &wdma0;
+ wdma1 = &wdma1;
+ color0 = &color0;
+ color1 = &color1;
+ split0 = &split0;
+ split1 = &split1;
+ dpi0 = &dpi0;
+ dsi0 = &dsi0;
+ dsi1 = &dsi1;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -285,6 +302,24 @@
#clock-cells = <1>;
};
+ mipi_tx0: mipi-dphy at 10215000 {
+ compatible = "mediatek,mt8173-mipi-tx";
+ reg = <0 0x10215000 0 0x1000>;
+ clocks = <&clk26m>;
+ clock-output-names = "mipi_tx0_pll";
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ };
+
+ mipi_tx1: mipi-dphy at 10216000 {
+ compatible = "mediatek,mt8173-mipi-tx";
+ reg = <0 0x10216000 0 0x1000>;
+ clocks = <&clk26m>;
+ clock-output-names = "mipi_tx1_pll";
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ };
+
gic: interrupt-controller at 1022 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
@@ -431,6 +466,14 @@
status = "disabled";
};
+ hdmiddc0: i2c at 11012000 {
+ compatible = "mediatek,mt8173-hdmi-ddc";
+ interrupts = ;
+ reg = <0 0x11012000 0 0x1C>;
+ clocks = <&pericfg CLK_PERI_I2C5>;
+ clock-names = "ddc-i2c";
+ };
+
i2c6: i2c at 11013000 {
compatible = "mediatek,mt8173-i2c";
reg = <0 0x11013000 0 0x70>,
@@ -525,7 +568,187 @@
mmsys: clock-controller at 1400 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
#clock-cells = <1>;
+
+ /* FIXME - remove iommus here */
+ iommus = <&iommu M4U_PORT_DISP_OVL0>,
+<&iommu M4U_PORT_DISP_OVL1>;
+ };
+
+ ovl0: ovl at 1400c000 {
+ compatible = "mediatek,mt8173-disp-ovl";
+ reg = <0 0x1400c000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ clocks = <&mmsys CLK_MM_DISP_OVL0>;
+ iommus = <&iommu M4U_PORT_DISP_OVL0>;
+ mediatek,larb = <&larb0>;
+ };
+
+ ovl1: ovl at 1400d000 {
+ compatible = "mediatek,mt8173-disp-ovl";
+ reg = <0 0x1400d000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ clocks = <&mmsys CLK_MM_DISP_OVL1>;
+ iommus = <&iommu M4U_PORT_DISP_OVL1>;
+ mediatek,larb = <&larb4>;
+ };
+
+ rdma0: rdma at 1400e000 {
+ compatible = "mediatek,mt8173-disp-rdma";
+ reg = <0 0x1400e000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ clocks = <&mmsys CLK_MM_DISP_RDMA0>;
+ iommus = <&iommu M4U_PORT_DISP_RDMA0>;
+ mediatek,larb = <&larb0>;
+ };
+
+ rdma1: rdma a
[PATCH v8 10/13] clk: mediatek: make dpi0_sel propagate rate changes
This mux is supposed to select a fitting divider after the PLL
is already set to the correct rate.
Signed-off-by: Philipp Zabel
Acked-by: James Liao
---
Changes since v7:
- The hdmi_sel mux is kept to propagate rate changes,
selecting the divider from the driver would only be necessary
for deep color modes, which are not supported.
---
drivers/clk/mediatek/clk-mt8173.c | 2 +-
drivers/clk/mediatek/clk-mtk.h| 7 +--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/drivers/clk/mediatek/clk-mt8173.c
index 227e356..682b275 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -558,7 +558,7 @@ static const struct mtk_composite top_muxes[] __initconst =
{
MUX_GATE(CLK_TOP_ATB_SEL, "atb_sel", atb_parents, 0x0090, 16, 2, 23),
MUX_GATE(CLK_TOP_VENC_LT_SEL, "venclt_sel", venc_lt_parents, 0x0090,
24, 4, 31),
/* CLK_CFG_6 */
- MUX_GATE(CLK_TOP_DPI0_SEL, "dpi0_sel", dpi0_parents, 0x00a0, 0, 3, 7),
+ MUX_GATE_FLAGS(CLK_TOP_DPI0_SEL, "dpi0_sel", dpi0_parents, 0x00a0, 0,
3, 7, 0),
MUX_GATE(CLK_TOP_IRDA_SEL, "irda_sel", irda_parents, 0x00a0, 8, 2, 15),
MUX_GATE(CLK_TOP_CCI400_SEL, "cci400_sel", cci400_parents, 0x00a0, 16,
3, 23),
MUX_GATE(CLK_TOP_AUD_1_SEL, "aud_1_sel", aud_1_parents, 0x00a0, 24, 2,
31),
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 32d2e45..b607996 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -83,7 +83,7 @@ struct mtk_composite {
signed char num_parents;
};
-#define MUX_GATE(_id, _name, _parents, _reg, _shift, _width, _gate) { \
+#define MUX_GATE_FLAGS(_id, _name, _parents, _reg, _shift, _width, _gate,
_flags) {\
.id = _id, \
.name = _name, \
.mux_reg = _reg,\
@@ -94,9 +94,12 @@ struct mtk_composite {
.divider_shift = -1,\
.parent_names = _parents, \
.num_parents = ARRAY_SIZE(_parents),\
- .flags = CLK_SET_RATE_PARENT, \
+ .flags = _flags,\
}
+#define MUX_GATE(_id, _name, _parents, _reg, _shift, _width, _gate)\
+ MUX_GATE_FLAGS(_id, _name, _parents, _reg, _shift, _width, _gate,
CLK_SET_RATE_PARENT)
+
#define MUX(_id, _name, _parents, _reg, _shift, _width) { \
.id = _id, \
.name = _name, \
--
2.6.2
[PATCH v8 09/13] arm64: dts: mt8173: Add HDMI related nodes
From: CK Hu
This patch adds the device nodes for the HDMI encoder, HDMI PHY,
and HDMI CEC modules.
Signed-off-by: CK Hu
Signed-off-by: Cawa Cheng
Signed-off-by: Jie Qiu
Signed-off-by: Daniel Kurtz
Signed-off-by: Philipp Zabel
---
Changes since v7:
- Describe HDMI PHY PLL output in the device tree. The hdmitx_dig_cts
clock is not a child of tvdpll_445p5m, but is an output of the
HDMI PHY module, which is routed back into the TOP clock module
for further divison and muxing.
- The hdmi_sel mux defaults to its 26 MHz input - switch it to the
HDMI PHY PLL output.
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 75
1 file changed, 75 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 68c1cb2..eb5210e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -198,6 +198,30 @@
,
;
+ hdmi_pin: xxx {
+
+ /*hdmi htplg pin*/
+ pins1 {
+ pinmux =
;
+ input-enable;
+ bias-pull-down;
+ };
+
+ /*hdmi flt 5v pin*/
+ pins2 {
+ pinmux =
;
+ input-enable;
+ bias-pull-up;
+ };
+
+ /*hdmi 5v pin*/
+ pins3 {
+ pinmux =
;
+ output-enable;
+ bias-pull-up;
+ };
+ };
+
i2c0_pins_a: i2c0 {
pins1 {
pinmux =
,
@@ -276,6 +300,13 @@
clock-names = "spi", "wrap";
};
+ cec: cec at 10013000 {
+ compatible = "mediatek,mt8173-cec";
+ reg = <0 0x10013000 0 0xbc>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_CEC>;
+ };
+
sysirq: intpol-controller at 10200620 {
compatible = "mediatek,mt8173-sysirq",
"mediatek,mt6577-sysirq";
@@ -302,6 +333,18 @@
#clock-cells = <1>;
};
+ hdmi_phy: hdmi-phy at 10209100 {
+ compatible = "mediatek,mt8173-hdmi-phy";
+ reg = <0 0x10209100 0 0x24>;
+ clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
+ clock-names = "pll_ref";
+ clock-output-names = "hdmitx_dig_cts";
+ mediatek,ibias = <0xa>;
+ mediatek,ibias_up = <0x1c>;
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ };
+
mipi_tx0: mipi-dphy at 10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
@@ -806,6 +849,38 @@
clock-names = "apb", "smi";
};
+ hdmi0: hdmi at 14025000 {
+ compatible = "mediatek,mt8173-hdmi";
+ reg = <0 0x14025000 0 0x400>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_HDMI_PIXEL>,
+<&mmsys CLK_MM_HDMI_PLLCK>,
+<&mmsys CLK_MM_HDMI_AUDIO>,
+<&mmsys CLK_MM_HDMI_SPDIF>;
+ clock-names = "pixel", "pll", "bclk", "spdif";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_pin>;
+ phys = <&hdmi_phy>;
+ phy-names = "hdmi";
+ mediatek,syscon-hdmi = <&mmsys 0x900>;
+ assigned-clocks = <&topckgen CLK_TOP_HDMI_SEL>;
+ assigned-clock-parents = <&hdmi_phy>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ hdmi0_in: endpoint {
+ remote-endpoint = <&dpi0_out>;
+ };
+ };
+ };
+ };
+
[PATCH v8 11/13] clk: mediatek: Add hdmi_ref HDMI PHY PLL reference clock output
The configurable hdmi_ref output of the PLL block is derived from
the tvdpll_594m clock signal via a configurable PLL post-divider.
It is used as the PLL reference input to the HDMI PHY module.
Signed-off-by: Philipp Zabel
Acked-by: James Liao
---
drivers/clk/mediatek/clk-mt8173.c | 5 +
include/dt-bindings/clock/mt8173-clk.h | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/drivers/clk/mediatek/clk-mt8173.c
index 682b275..3ae0b88 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -1091,6 +1091,11 @@ static void __init mtk_apmixedsys_init(struct
device_node *node)
clk_data->clks[cku->id] = clk;
}
+ clk = clk_register_divider(NULL, "hdmi_ref", "tvdpll_594m", 0,
+ base + 0x40, 16, 3, CLK_DIVIDER_POWER_OF_TWO,
+ NULL);
+ clk_data->clks[CLK_APMIXED_HDMI_REF] = clk;
+
r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
if (r)
pr_err("%s(): could not register clock provider: %d\n",
diff --git a/include/dt-bindings/clock/mt8173-clk.h
b/include/dt-bindings/clock/mt8173-clk.h
index 7956ba1..6094bf7 100644
--- a/include/dt-bindings/clock/mt8173-clk.h
+++ b/include/dt-bindings/clock/mt8173-clk.h
@@ -176,7 +176,8 @@
#define CLK_APMIXED_LVDSPLL13
#define CLK_APMIXED_MSDCPLL2 14
#define CLK_APMIXED_REF2USB_TX 15
-#define CLK_APMIXED_NR_CLK 16
+#define CLK_APMIXED_HDMI_REF 16
+#define CLK_APMIXED_NR_CLK 17
/* INFRA_SYS */
--
2.6.2
[PATCH v8 12/13] dt-bindings: hdmi-connector: add DDC I2C bus phandle documentation
Add an optional ddc-i2c-bus phandle property that points to an I2C master controller that handles the connector DDC pins. Signed-off-by: Philipp Zabel Acked-by: Rob Herring --- Documentation/devicetree/bindings/display/connector/hdmi-connector.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt index acd5668..508aee4 100644 --- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt +++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt @@ -8,6 +8,7 @@ Required properties: Optional properties: - label: a symbolic name for the connector - hpd-gpios: HPD GPIO number +- ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing Required nodes: - Video port for HDMI input -- 2.6.2
[PATCH v8 13/13] clk: mediatek: remove hdmitx_dig_cts from TOP clocks
The hdmitx_dig_cts clock signal is not a child of tvdpll_445p5m,
but is routed out of the HDMI PHY module.
Signed-off-by: Philipp Zabel
---
drivers/clk/mediatek/clk-mt8173.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/drivers/clk/mediatek/clk-mt8173.c
index 3ae0b88..e0d9994 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -61,7 +61,6 @@ static const struct mtk_fixed_factor top_divs[] __initconst =
{
FACTOR(CLK_TOP_CLKRTC_INT, "clkrtc_int", "clk26m", 1, 793),
FACTOR(CLK_TOP_FPC, "fpc_ck", "clk26m", 1, 1),
- FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "tvdpll_445p5m", 1, 3),
FACTOR(CLK_TOP_HDMITXPLL_D2, "hdmitxpll_d2", "hdmitx_dig_cts", 1, 2),
FACTOR(CLK_TOP_HDMITXPLL_D3, "hdmitxpll_d3", "hdmitx_dig_cts", 1, 3),
--
2.6.2
radeon framebuffer tiling
Hi, dce4_crtc_do_set_base is the only location in which EVERGREEN_GRPH_CONTROL is updated. This currently configures a non-tiled framebuffer on my SI system. This design prevents drmModePageFlip from handling a framebuffer with a different tiling configuration. Is this the intended architecture? i.e. All surfaces provided to drmModePageFlip should match the initial framebuffer layout, or should EVERGREEN_GRPH_CONTROL be updated on every page flip? -- Jay Cornwall
radeon framebuffer tiling
On Mon, Jan 4, 2016 at 12:57 PM, Jay Cornwall wrote: > Hi, > > dce4_crtc_do_set_base is the only location in which EVERGREEN_GRPH_CONTROL > is updated. This currently configures a non-tiled framebuffer on my SI > system. > > This design prevents drmModePageFlip from handling a framebuffer with a > different tiling configuration. > > Is this the intended architecture? i.e. All surfaces provided to > drmModePageFlip should match the initial framebuffer layout, or should > EVERGREEN_GRPH_CONTROL be updated on every page flip? Pageflipping is only available between surfaces of the same format (i.e., we only update the base address, not the other parameters). Alex
