[PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
Hi Doug,
On 16.09.2015 23:04, Doug Anderson wrote:
> Hi,
>
> On Sun, Aug 30, 2015 at 2:34 PM, Vladimir Zapolskiy
> wrote:
>> The change adds support of internal HDMI I2C master controller, this
>> subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
>>
>> The main purpose of this functionality is to support reading EDID from
>> an HDMI monitor on boards, which don't have an I2C bus connected to
>> DDC pins.
>>
>> The current implementation does not support "I2C Master Interface
>> Extended Read Mode" to read data addressed by non-zero segment
>> pointer, this means that if EDID has more than 1 extension blocks,
>> EDID reading operation won't succeed, in my practice all tested HDMI
>> monitors have at maximum one extension block.
>>
>> Signed-off-by: Vladimir Zapolskiy
>> ---
>> The change is based on today's v4.2, please let me know, if it should be
>> rebased.
>>
>> The change has compilation dependency on I2CM_ADDRESS register name fix,
>> see http://lists.freedesktop.org/archives/dri-devel/2015-May/082980.html
>>
>> From http://lists.freedesktop.org/archives/dri-devel/2015-May/082981.html
>> v1 of the change was
>>
>> Tested-by: Philipp Zabel
>>
>> but I hesitate to add the tag here due to multiple updates in v2.
>>
>> Changes from v2 to v3, thanks to Russell:
>> - moved register field value definitions to dw_hdmi.h
>> - made completions uninterruptible to avoid transfer retries if interrupted
>> - use one completion for both read and write transfers as in v1,
>> operation_reg is removed
>> - redundant i2c->stat = 0 is removed from dw_hdmi_i2c_read/write()
>> - struct i2c_algorithm dw_hdmi_algorithm is qualified as const
>> - dw_hdmi_i2c_adapter() does not modify struct dw_hdmi on error path
>> - dw_hdmi_i2c_irq() does not modify hdmi->i2c->stat, if interrupt is not for
>> I2CM
>> - spin lock is removed from dw_hdmi_i2c_irq()
>> - removed spin lock from dw_hdmi_i2c_xfer() around write to
>> HDMI_IH_MUTE_I2CM_STAT0 register
>> - split loop over message array in dw_hdmi_i2c_xfer() to validation and
>> transfer parts
>> - added a mutex to serialize I2C transfer requests, i2c->lock is completely
>> removed
>> - removed if(len) check from dw_hdmi_i2c_write(), hardware supports only
>> len>0 transfers
>> - described extension blocks <= 1 limitation in the commit message
>> - a number of minor clean ups
>>
>> Changes from v1 to v2:
>> - fixed a devm_kfree() signature
>> - split completions for read and write operations
>>
>> drivers/gpu/drm/bridge/dw_hdmi.c | 262
>> ++-
>> drivers/gpu/drm/bridge/dw_hdmi.h | 19 +++
>> 2 files changed, 275 insertions(+), 6 deletions(-)
>
> Not sure what the status of this patch is, but I'll make a few more
> suggestions in case they're helpful.
sure, all review comments are welcome.
I have in mind that Philipp asked to add an update to documentation, the
next version will contain the fixes.
>
>> +static void dw_hdmi_i2c_init(struct dw_hdmi *hdmi)
>> +{
>> + /* Set Fast Mode speed */
>> + hdmi_writeb(hdmi, 0x0b, HDMI_I2CM_DIV);
>
> If you're going to hardcode to something, it seems like hardcoding to
> standard mode might be better? It's likely that users will plug into
> all kinds of broken / crappy HDMI devices out there. I think you'll
> get better compatibility by using the slower mode, and EDID transfers
> really aren't too performance critical are they?
>
Accepted. I don't know what are the exact divisors of master clock for
fast and standard modes, for reference I'll make a simple performance
test and publish its results. I expect that in standard mode SCL is
about 100KHz and in fast mode SCL is about 400KHz, and, if in standard
mode SCL is less than 100KHz, it will take more than 50ms to read out
512 bytes of data, which might be not acceptable from performance
perspective.
>> +
>> + /* Software reset */
>> + hdmi_writeb(hdmi, 0x00, HDMI_I2CM_SOFTRSTZ);
>
> Unless there's a reason not to, it seems like the reset ought to be
> the first thing in this function (before setting the I2CM_DIV). Even
> if it doesn't actually reset the speed on current hardware, it just
> seems cleaner.
It makes sense for me.
>
>> +static int dw_hdmi_i2c_xfer(struct i2c_adapter *adap,
>> + struct i2c_msg *msgs, int num)
>> +{
>> + struct dw_hdmi *hdmi = i2c_get_adapdata(adap);
>> + struct dw_hdmi_i2c *i2c = hdmi->i2c;
>> + u8 addr = msgs[0].addr;
>> + int i, ret = 0;
>> +
>> + dev_dbg(hdmi->dev, "xfer: num: %d, addr: %#x\n", num, addr);
>> +
>> + for (i = 0; i < num; i++) {
>> + if (msgs[i].addr != addr) {
>> + dev_warn(hdmi->dev,
>> +"unsupported transfer, changed slave
>> address\n");
>> + return -EOPNOTSUPP;
>> + }
>> +
>> + if (msgs[i].len == 0) {
>> + dev_dbg(hdmi->dev,
>> +
[PATCH 0/3] RFC: Add a drm_aux-dev module.
On Wed, Sep 16, 2015 at 01:09:54PM -0700, Daniel Vetter wrote: > On Tue, Sep 15, 2015 at 10:03:09AM -0700, Rafael Antognolli wrote: > > On Tue, Sep 15, 2015 at 07:46:55PM +0300, Ville Syrjälä wrote: > > > On Tue, Sep 15, 2015 at 07:41:06PM +0300, Ville Syrjälä wrote: > > > > On Tue, Sep 15, 2015 at 09:34:15AM -0700, Rafael Antognolli wrote: > > > > > On Tue, Sep 15, 2015 at 10:35:19AM +0300, Ville Syrjälä wrote: > > > > > > On Mon, Sep 14, 2015 at 04:12:29PM -0700, Rafael Antognolli wrote: > > > > > > > This is a tentative implementation of a module that allows > > > > > > > reading/writing > > > > > > > arbitrary dpcd registers, following the suggestion from Daniel > > > > > > > Vetter. It > > > > > > > assumes the drm aux helpers were used by the driver. > > > > > > > > > > > > > > I tried to follow the i2c-dev implementation as close as > > > > > > > possible, but the only > > > > > > > operations that are provided on the dev node are two different > > > > > > > ioctl's, one for > > > > > > > reading a register and another one for writing it. > > > > > > > > > > > > Why would you use ioctls instead of normal read/write syscalls? > > > > > > > > > > > > > > > > For writing, that should work fine, I can easily change that if you > > > > > prefer. > > > > > > > > > > For reading, one has to first tell which register address is going to > > > > > be > > > > > read. > > > > > > > > seek() > > > > > > Sorry typo. Make that lseek(). > > > > > Oh, nice, I'll update the patch with this and remove the notifier stuff, > > thanks! > > Well there's also other modes like i2c over aux, and that would be easier > to support with an ioctl in a uniform way. So not sure how much value > there is in reusing read/write for i2c ... We already have i2c-dev for i2c. So not sure what you're after here. i2c is a bit of a mess on the protocol level. Lots of devices do interesting things with it, so it can't really make do with just read/write/lseek. Apart from i2c-over-aux, the rest is all about DPCD access, and for that read/write/lseek is all you ever need. -- Ville Syrjälä Intel OTC
[PATCH 2/3] drm: fix kernel-doc warnings in drm_crtc.h
Fix the following 'make htmldocs' warning:
.//include/drm/drm_crtc.h:929: warning: Excess struct/union/enum/typedef
member 'base' description in 'drm_bridge'
Signed-off-by: Geliang Tang
---
include/drm/drm_crtc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c0366e9..6566f72 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -911,7 +911,6 @@ struct drm_bridge_funcs {
* @next: the next bridge in the encoder chain
* @of_node: device node pointer to the bridge
* @list: to keep track of all added bridges
- * @base: base mode object
* @funcs: control functions
* @driver_private: pointer to the bridge driver's internal context
*/
--
1.9.1
[PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
On Wed, Sep 16, 2015 at 02:56:57PM -0700, Doug Anderson wrote: > Yes, I'd expect 100kHz and 400kHz. > > I agree that 50ms is non-trivial, but it's also not something you're > doing lots of. I'd expect that the EDID is read over this channel at > cable plugin time and then not used much after that. Adding an extra > 40ms (10ms vs 50ms) before we can access the TV doesn't seem terrible > for compatibility. > > Doing a quick scan for what others in mainline do: > > A few can be found with: > > $ git grep -A3 hdmiddc | grep clock-freq > arch/arm/boot/dts/stihxxx-b2120.dtsi- > clock-frequency = <10>; > arch/arm/boot/dts/tegra30-apalis.dtsi- clock-frequency = <10>; > arch/arm/boot/dts/tegra30-beaver.dts- clock-frequency = <10>; > arch/arm/boot/dts/tegra30-colibri.dtsi- clock-frequency = <10>; This is a sure way to propagate a bug. I said in a previous email that you need to check the HDMI and CEA specs. I've done this, and HDMI 1.3a specifies a maximum SCL clock rate of 100kHz. So that's settled then. 100kHz is must be. Using 400kHz is out of specification. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH 23/23] drm/i915: BDW: Pipe level degamma correction
BDW/SKL/BXT supports Degamma color correction feature, which
linearizes the non-linearity due to gamma encoded color values.
This will be applied before Color Transformation.
This patch does the following:
1. Adds the core function to program DeGamma correction values for
BDW/SKL/BXT platform
2. Adds DeGamma correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_color_manager.c | 61 ++
1 file changed, 61 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index d935fd8..46f880d 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -532,6 +532,65 @@ static int bdw_set_gamma(struct drm_device *dev, struct
drm_property_blob *blob,
return 0;
}
+static int bdw_set_degamma(struct drm_device *dev,
+ struct drm_property_blob *blob, struct drm_crtc *crtc)
+{
+ enum pipe pipe;
+ int num_samples, length;
+ int count = 0;
+ u32 index, word;
+ u32 blue, green, red;
+ u32 mode, pal_prec_index, pal_prec_data;
+ struct drm_palette *degamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_r32g32b32 *correction_values = NULL;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ degamma_data = (struct drm_palette *)blob->data;
+ if (degamma_data->version != DEGAMMA_DATA_STRUCT_VERSION) {
+ DRM_ERROR("Invalid DeGamma Data struct version\n");
+ return -EINVAL;
+ }
+
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = degamma_data->num_samples;
+ if (num_samples != BDW_SPLITGAMMA_MAX_VALS) {
+ DRM_ERROR("Invalid number of samples\n");
+ return -EINVAL;
+ }
+
+ length = num_samples * sizeof(struct drm_r32g32b32);
+ mode = I915_READ(GAMMA_MODE(pipe));
+ pal_prec_index = _PREC_PAL_INDEX(pipe);
+ pal_prec_data = _PREC_PAL_DATA(pipe);
+
+ correction_values = (struct drm_r32g32b32 *)°amma_data->lut;
+ index = I915_READ(pal_prec_index);
+ index |= BDW_INDEX_AUTO_INCREMENT | BDW_INDEX_SPLIT_MODE;
+ I915_WRITE(pal_prec_index, index);
+
+ while (count < num_samples) {
+ blue = correction_values[count].b32;
+ green = correction_values[count].g32;
+ red = correction_values[count].r32;
+
+ word = bdw_write_10bit_gamma_precision(red, green, blue);
+ I915_WRITE(pal_prec_data, word);
+ count++;
+ }
+
+ /* Enable DeGamma on Pipe */
+ mode &= ~GAMMA_MODE_MODE_MASK;
+ I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_SPLIT);
+
+ DRM_DEBUG_DRIVER("DeGamma correction enabled on Pipe %c\n",
+ pipe_name(pipe));
+
+ return 0;
+}
+
static int chv_set_gamma(struct drm_device *dev, struct drm_property_blob
*blob,
struct drm_crtc *crtc)
{
@@ -700,6 +759,8 @@ void intel_color_manager_crtc_commit(struct drm_device *dev,
/* degamma correction */
if (IS_CHERRYVIEW(dev))
ret = chv_set_degamma(dev, blob, crtc);
+ else if (IS_BROADWELL(dev) || IS_GEN9(dev))
+ ret = bdw_set_degamma(dev, blob, crtc);
if (ret)
DRM_ERROR("set degamma correction failed\n");
--
1.9.1
[PATCH 22/23] drm/i915: BDW: Load degamma correction values
I915 color manager registers pipe degamma correction as palette
correction before CTM, DRM property.
This patch adds the no of coefficients(65) for degamma correction
as "num_samples_before_ctm" parameter in device info structures,
for BDW and higher platforms.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_drv.c| 7 +++
drivers/gpu/drm/i915/intel_color_manager.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 69afed3..23ad2cc 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -303,6 +303,7 @@ static const struct intel_device_info
intel_broadwell_d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -316,6 +317,7 @@ static const struct intel_device_info
intel_broadwell_m_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -329,6 +331,7 @@ static const struct intel_device_info
intel_broadwell_gt3d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -342,6 +345,7 @@ static const struct intel_device_info
intel_broadwell_gt3m_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -368,6 +372,7 @@ static const struct intel_device_info intel_skylake_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -382,6 +387,7 @@ static const struct intel_device_info
intel_skylake_gt3_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -396,6 +402,7 @@ static const struct intel_device_info intel_broxton_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.num_pipes = 3,
.has_ddi = 1,
.has_fpga_dbg = 1,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index 17fcf3d..a428825 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -72,6 +72,8 @@
#define CHV_DEGAMMA_MSB_SHIFT 2
#define CHV_DEGAMMA_GREEN_SHIFT16
+#define BDW_DEGAMMA_MAX_VALS 512
+
/* CSC correction */
#define CSC_DATA_STRUCT_VERSION1
/*
--
1.9.1
[PATCH 21/23] drm/i915: BDW: Pipe level Gamma correction
BDW/SKL/BXT platforms support various Gamma correction modes
which are:
1. Legacy 8-bit mode
2. 10-bit mode
3. 10-bit Split Gamma mode
4. 12-bit mode
This patch does the following:
1. Adds the core function to program Gamma correction values
for BDW/SKL/BXT platforms
2. Adds Gamma correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 17 +-
drivers/gpu/drm/i915/intel_color_manager.c | 270 +
drivers/gpu/drm/i915/intel_color_manager.h | 15 ++
3 files changed, 300 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5c7759d..88f4e41 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5634,7 +5634,9 @@ enum skl_disp_power_wells {
#define _GAMMA_MODE_A 0x4a480
#define _GAMMA_MODE_B 0x4ac80
-#define GAMMA_MODE(pipe) _PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
+#define _GAMMA_MODE_C 0x4b480
+#define GAMMA_MODE(pipe) \
+ _PIPE3(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B, _GAMMA_MODE_C)
#define GAMMA_MODE_MODE_MASK (3 << 0)
#define GAMMA_MODE_MODE_8BIT (0 << 0)
#define GAMMA_MODE_MODE_10BIT (1 << 0)
@@ -8001,6 +8003,17 @@ enum skl_disp_power_wells {
#define _PIPE_CSC_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
-
+/* BDW gamma correction */
+#define PAL_PREC_INDEX_A 0x4A400
+#define PAL_PREC_INDEX_B 0x4AC00
+#define PAL_PREC_INDEX_C 0x4B400
+#define PAL_PREC_DATA_A0x4A404
+#define PAL_PREC_DATA_B0x4AC04
+#define PAL_PREC_DATA_C0x4B404
+
+#define _PREC_PAL_INDEX(pipe) \
+ (_PIPE3(pipe, PAL_PREC_INDEX_A, PAL_PREC_INDEX_B, PAL_PREC_INDEX_C))
+#define _PREC_PAL_DATA(pipe) \
+ (_PIPE3(pipe, PAL_PREC_DATA_A, PAL_PREC_DATA_B, PAL_PREC_DATA_C))
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index d33a2be..d935fd8 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -264,6 +264,274 @@ static int chv_set_degamma(struct drm_device *dev,
return ret;
}
+static u32 bdw_write_10bit_gamma_precision(u32 red, u32 green, u32 blue)
+{
+ u32 word;
+ u8 blue_int, green_int, red_int;
+ u16 blue_fract, green_fract, red_fract;
+
+ blue_int = _GAMMA_INT_PART(blue);
+ if (blue_int > GAMMA_INT_MAX)
+ blue = BDW_MAX_GAMMA;
+
+ green_int = _GAMMA_INT_PART(green);
+ if (green_int > GAMMA_INT_MAX)
+ green = BDW_MAX_GAMMA;
+
+ red_int = _GAMMA_INT_PART(red);
+ if (red_int > GAMMA_INT_MAX)
+ red = BDW_MAX_GAMMA;
+
+ blue_fract = _GAMMA_FRACT_PART(blue);
+ green_fract = _GAMMA_FRACT_PART(green);
+ red_fract = _GAMMA_FRACT_PART(red);
+
+ blue_fract >>= BDW_10BIT_GAMMA_MSB_SHIFT;
+ green_fract >>= BDW_10BIT_GAMMA_MSB_SHIFT;
+ red_fract >>= BDW_10BIT_GAMMA_MSB_SHIFT;
+
+ /* Red (29:20) Green (19:10) and Blue (9:0) */
+ word = red_fract;
+ word <<= BDW_GAMMA_SHIFT;
+ word = word | green_fract;
+ word <<= BDW_GAMMA_SHIFT;
+ word = word | blue_fract;
+
+ return word;
+}
+
+/* Apply unity gamma for gamma reset */
+static void bdw_reset_gamma(struct drm_i915_private *dev_priv,
+ enum pipe pipe)
+{
+ u16 count = 0;
+ u32 val;
+ u32 pal_prec_data = LGC_PALETTE(pipe);
+
+ DRM_DEBUG_DRIVER("\n");
+
+ /* Reset the palette for unit gamma */
+ while (count < BDW_8BIT_GAMMA_MAX_VALS) {
+ /* Red (23:16) Green (15:8) and Blue (7:0) */
+ val = (count << 16) | (count << 8) | count;
+ I915_WRITE(pal_prec_data, val);
+ pal_prec_data += 4;
+ count++;
+ }
+}
+
+static int bdw_set_gamma(struct drm_device *dev, struct drm_property_blob
*blob,
+ struct drm_crtc *crtc)
+{
+ u8 blue_int, green_int, red_int;
+ u16 blue_fract, green_fract, red_fract;
+ u16 blue_odd, green_odd, red_odd;
+ u16 blue_even, green_even, red_even;
+
+ enum pipe pipe;
+ int count, num_samples;
+ u32 blue, green, red;
+ u32 mode, pal_prec_index, pal_prec_data;
+ u32 index, word;
+ struct drm_palette *gamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_r32g32b32 *correction_values = NULL;
+
+ if (!blob) {
+ DRM_ERROR("Null Blob\n");
+ return -EINVAL;
+ }
+
+ gamma_data = (struct drm_palette *)blob->data;
+
+ if (gamma_data->version != GAMMA_DATA_STRUCT_VERSION) {
+ DRM_DEBUG_KMS("Invalid Gamma Data struct version\n");
+
[PATCH 20/23] drm/i915: BDW: Load gamma correction values
I915 color manager registers pipe gamma correction as palette
correction after CTM property.
For BDW and higher platforms, split gamma correction is the best
gamma correction. This patch adds the no of coefficients(512) for
split gamma correction as "num_samples_after_ctm" parameter in device
info structures, for all of those.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_drv.c| 7 +++
drivers/gpu/drm/i915/intel_color_manager.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 03db841..69afed3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -302,6 +302,7 @@ static const struct intel_device_info
intel_broadwell_d_info = {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -314,6 +315,7 @@ static const struct intel_device_info
intel_broadwell_m_info = {
.gen = 8, .is_mobile = 1, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -326,6 +328,7 @@ static const struct intel_device_info
intel_broadwell_gt3d_info = {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -338,6 +341,7 @@ static const struct intel_device_info
intel_broadwell_gt3m_info = {
.gen = 8, .is_mobile = 1, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -363,6 +367,7 @@ static const struct intel_device_info intel_skylake_info = {
.gen = 9, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -376,6 +381,7 @@ static const struct intel_device_info
intel_skylake_gt3_info = {
.gen = 9, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -389,6 +395,7 @@ static const struct intel_device_info intel_broxton_info = {
.gen = 9,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.num_pipes = 3,
.has_ddi = 1,
.has_fpga_dbg = 1,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index 6e5158e..3687989 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -42,6 +42,8 @@
#define CHV_10BIT_GAMMA_MSB_SHIFT 6
#define CHV_GAMMA_SHIFT_GREEN 16
+#define BDW_SPLITGAMMA_MAX_VALS512
+
/* Gamma values are u8.24 format */
#define GAMMA_INT_SHIFT24
#define GAMMA_FRACT_SHIFT 8
--
1.9.1
[PATCH 19/23] drm/i915: Attach color properties to CRTC
Function intel_attach_color_properties_to_crtc attaches a color property to its CRTC object. This patch calls this function from crtc initialization sequence. Signed-off-by: Shashank Sharma Signed-off-by: Kausal Malladi --- drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/i915/intel_drv.h | 2 ++ 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 9b9d267..8b5f266 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -13818,6 +13818,7 @@ static void intel_crtc_init(struct drm_device *dev, int pipe) intel_crtc->cursor_size = ~0; intel_crtc->wm.cxsr_allowed = true; + intel_attach_color_properties_to_crtc(dev, &intel_crtc->base.base); BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) || dev_priv->plane_to_crtc_mapping[intel_crtc->plane] != NULL); diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index f87a99d..f992345 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1478,4 +1478,6 @@ int intel_color_manager_set_pipe_csc(struct drm_device *dev, struct drm_mode_object *obj, uint32_t blob_id); void intel_color_manager_crtc_commit(struct drm_device *dev, struct drm_crtc_state *crtc_state); +void intel_attach_color_properties_to_crtc(struct drm_device *dev, + struct drm_mode_object *mode_obj); #endif /* __INTEL_DRV_H__ */ -- 1.9.1
[PATCH 18/23] drm/i915: Commit color changes to CRTC
The color correction blob values are loaded during set_property
calls. This patch adds a function to find the blob and apply the
correction values to the display registers, during the atomic
commit call.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_color_manager.c | 46 ++
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 2 ++
3 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 22b708f..d33a2be 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -406,6 +406,52 @@ int intel_color_manager_set_pipe_gamma(struct drm_device
*dev,
return 0;
}
+void intel_color_manager_crtc_commit(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state)
+{
+ struct drm_property_blob *blob;
+ struct drm_crtc *crtc = crtc_state->crtc;
+ int ret = -EINVAL;
+
+ blob = crtc_state->palette_after_ctm_blob;
+ if (blob) {
+ /* Gamma correction is platform specific */
+ if (IS_CHERRYVIEW(dev))
+ ret = chv_set_gamma(dev, blob, crtc);
+
+ if (ret)
+ DRM_ERROR("set Gamma correction failed\n");
+ else
+ DRM_DEBUG_DRIVER("Gamma correction success\n");
+ }
+
+ blob = crtc_state->palette_before_ctm_blob;
+ if (blob) {
+ /* degamma correction */
+ if (IS_CHERRYVIEW(dev))
+ ret = chv_set_degamma(dev, blob, crtc);
+
+ if (ret)
+ DRM_ERROR("set degamma correction failed\n");
+ else
+ DRM_DEBUG_DRIVER("degamma correction success\n");
+ }
+
+ blob = crtc_state->ctm_blob;
+ if (blob) {
+ /* CSC correction */
+ if (IS_CHERRYVIEW(dev))
+ ret = chv_set_csc(dev, blob, crtc);
+
+ if (ret)
+ DRM_ERROR("set CSC correction failed\n");
+ else
+ DRM_DEBUG_DRIVER("CSC correction success\n");
+ }
+
+}
+
+
int get_pipe_capabilities(struct drm_device *dev,
struct drm_palette_caps *palette_caps, struct drm_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 010acca..9b9d267 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13487,6 +13487,8 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc,
intel_update_pipe_config(intel_crtc, old_intel_state);
else if (INTEL_INFO(dev)->gen >= 9)
skl_detach_scalers(intel_crtc);
+
+ intel_color_manager_crtc_commit(dev, crtc->state);
}
static void intel_finish_crtc_commit(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 4d571a2f..f87a99d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1476,4 +1476,6 @@ int intel_color_manager_set_pipe_degamma(struct
drm_device *dev,
int intel_color_manager_set_pipe_csc(struct drm_device *dev,
struct drm_crtc_state *crtc_state,
struct drm_mode_object *obj, uint32_t blob_id);
+void intel_color_manager_crtc_commit(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state);
#endif /* __INTEL_DRV_H__ */
--
1.9.1
[PATCH 17/23] drm/i915: CHV: Pipe level CSC correction
CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.
This patch does the following:
1. Attaches CSC property to CRTC
2. Adds the core function to program CSC correction values
3. Adds CSC correction macros
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 8 +++
drivers/gpu/drm/i915/intel_color_manager.c | 99 ++
drivers/gpu/drm/i915/intel_color_manager.h | 20 ++
3 files changed, 127 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3dde6a8..5c7759d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7995,4 +7995,12 @@ enum skl_disp_power_wells {
#define _PIPE_DEGAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
+#define PIPEA_CGM_CSC (VLV_DISPLAY_BASE + 0x67900)
+#define PIPEB_CGM_CSC (VLV_DISPLAY_BASE + 0x69900)
+#define PIPEC_CGM_CSC (VLV_DISPLAY_BASE + 0x6B900)
+#define _PIPE_CSC_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
+
+
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index e2ffbdc..22b708f 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -66,6 +66,99 @@ int intel_color_manager_set_pipe_degamma(struct drm_device
*dev,
return 0;
}
+static s16 get_csc_s3_12_format(s64 csc_value)
+{
+ s32 csc_int_value;
+ u32 csc_fract_value;
+ s16 csc_s3_12_format;
+
+ if (csc_value >= 0) {
+ csc_value += CHV_CSC_FRACT_ROUNDOFF;
+ if (csc_value > CHV_CSC_COEFF_MAX)
+ csc_value = CHV_CSC_COEFF_MAX;
+ } else {
+ csc_value = -csc_value;
+ csc_value += CHV_CSC_FRACT_ROUNDOFF;
+ if (csc_value > CHV_CSC_COEFF_MAX + 1)
+ csc_value = CHV_CSC_COEFF_MAX + 1;
+ csc_value = -csc_value;
+ }
+
+ csc_int_value = csc_value >> CHV_CSC_COEFF_SHIFT;
+ csc_int_value <<= CHV_CSC_COEFF_INT_SHIFT;
+ if (csc_value < 0)
+ csc_int_value |= CSC_COEFF_SIGN;
+ csc_fract_value = csc_value;
+ csc_fract_value >>= CHV_CSC_COEFF_FRACT_SHIFT;
+ csc_s3_12_format = csc_int_value | csc_fract_value;
+
+ return csc_s3_12_format;
+}
+
+static int chv_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+ struct drm_crtc *crtc)
+{
+ struct drm_ctm *csc_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 reg;
+ enum pipe pipe;
+ s32 word, temp;
+ int count = 0;
+
+ if (!blob) {
+ DRM_ERROR("NULL Blob\n");
+ return -EINVAL;
+ }
+
+ if (blob->length != sizeof(struct drm_ctm)) {
+ DRM_ERROR("Invalid length of data received\n");
+ return -EINVAL;
+ }
+
+ csc_data = (struct drm_ctm *)blob->data;
+ if (csc_data->version != CSC_DATA_STRUCT_VERSION) {
+ DRM_ERROR("Invalid CSC Data struct version\n");
+ return -EINVAL;
+ }
+
+ pipe = to_intel_crtc(crtc)->pipe;
+
+ /* Disable CSC functionality */
+ reg = _PIPE_CGM_CONTROL(pipe);
+ I915_WRITE(reg, I915_READ(reg) & (~CGM_CSC_EN));
+
+ DRM_DEBUG_DRIVER("Disabled CSC Functionality on Pipe %c\n",
+ pipe_name(pipe));
+
+ reg = _PIPE_CSC_BASE(pipe);
+ while (count < CSC_MAX_VALS) {
+ word = get_csc_s3_12_format(csc_data->ctm_coeff[count]);
+
+ /*
+* Last value to be written in 1 register.
+* Otherwise, each pair of CSC values go
+* into 1 register
+*/
+ if (count != (CSC_MAX_VALS - 1)) {
+ count++;
+ temp = get_csc_s3_12_format(csc_data->ctm_coeff[count]);
+ word |= temp;
+ }
+ I915_WRITE(reg, word);
+ reg += 4;
+ count++;
+ }
+
+ DRM_DEBUG_DRIVER("All CSC values written to registers\n");
+
+ /* Enable CSC functionality */
+ reg = _PIPE_CGM_CONTROL(pipe);
+ I915_WRITE(reg, I915_READ(reg) | CGM_CSC_EN);
+ DRM_DEBUG_DRIVER("CSC enabled on Pipe %c\n", pipe_name(pipe));
+
+ return 0;
+}
+
static int chv_set_degamma(struct drm_device *dev,
struct drm_property_blob *blob, struct drm_crtc *crtc)
{
@@ -372,5 +465,11 @@ void intel_attach_color_properties_to_crtc(struct
drm_device *dev,
DRM_DEBUG_DRIVER("palette before CTM attached to CRTC\n");
}
+ if (config->cm_ctm_property) {
+
[PATCH 16/23] drm/i915: CHV: Pipe level degamma correction
CHV/BSW supports DeGamma color correction, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.
This patch does the following:
1. Attach deGamma property to CRTC
2. Add the core function to program DeGamma correction values for
CHV/BSW platform
2. Add DeGamma correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 6 ++
drivers/gpu/drm/i915/intel_color_manager.c | 111 +
drivers/gpu/drm/i915/intel_color_manager.h | 6 ++
3 files changed, 123 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 93aa1f9..3dde6a8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7989,4 +7989,10 @@ enum skl_disp_power_wells {
#define _PIPE_GAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
+#define PIPEA_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x66000)
+#define PIPEB_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x68000)
+#define PIPEC_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x6A000)
+#define _PIPE_DEGAMMA_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 222924d..e2ffbdc 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -66,6 +66,111 @@ int intel_color_manager_set_pipe_degamma(struct drm_device
*dev,
return 0;
}
+static int chv_set_degamma(struct drm_device *dev,
+ struct drm_property_blob *blob, struct drm_crtc *crtc)
+{
+ struct drm_palette *degamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 cgm_control_reg = 0;
+ u32 cgm_degamma_reg = 0;
+ enum pipe pipe;
+ u32 red, green, blue;
+ u8 red_int, green_int, blue_int;
+ u16 red_fract, green_fract, blue_fract;
+ u32 count = 0;
+ struct drm_r32g32b32 *correction_values = NULL;
+ u32 num_samples;
+ u32 word;
+ int ret = 0, length;
+
+ if (!blob) {
+ DRM_ERROR("NULL Blob\n");
+ return -EINVAL;
+ }
+
+ degamma_data = (struct drm_palette *)blob->data;
+
+ if (degamma_data->version != DEGAMMA_DATA_STRUCT_VERSION) {
+ DRM_ERROR("Invalid DeGamma Data struct version\n");
+ return -EINVAL;
+ }
+
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = degamma_data->num_samples;
+ length = num_samples * sizeof(struct drm_r32g32b32);
+
+ if (num_samples == 0) {
+
+ /* Disable DeGamma functionality on Pipe - CGM Block */
+ cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+ cgm_control_reg &= ~CGM_DEGAMMA_EN;
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+
+ DRM_DEBUG_DRIVER("DeGamma disabled on Pipe %c\n",
+ pipe_name(pipe));
+ ret = 0;
+ } else if (num_samples == CHV_DEGAMMA_MAX_VALS) {
+ cgm_degamma_reg = _PIPE_DEGAMMA_BASE(pipe);
+
+ count = 0;
+ correction_values = (struct drm_r32g32b32 *)°amma_data->lut;
+ while (count < CHV_DEGAMMA_MAX_VALS) {
+ blue = correction_values[count].b32;
+ green = correction_values[count].g32;
+ red = correction_values[count].r32;
+
+ blue_int = _GAMMA_INT_PART(blue);
+ if (blue_int > GAMMA_INT_MAX)
+ blue = CHV_MAX_GAMMA;
+ green_int = _GAMMA_INT_PART(green);
+ if (green_int > GAMMA_INT_MAX)
+ green = CHV_MAX_GAMMA;
+ red_int = _GAMMA_INT_PART(red);
+ if (red_int > GAMMA_INT_MAX)
+ red = CHV_MAX_GAMMA;
+
+ blue_fract = _GAMMA_FRACT_PART(blue);
+ green_fract = _GAMMA_FRACT_PART(green);
+ red_fract = _GAMMA_FRACT_PART(red);
+
+ blue_fract >>= CHV_DEGAMMA_MSB_SHIFT;
+ green_fract >>= CHV_DEGAMMA_MSB_SHIFT;
+ red_fract >>= CHV_DEGAMMA_MSB_SHIFT;
+
+ /* Green (29:16) and Blue (13:0) in DWORD1 */
+ word = green_fract;
+ word <<= CHV_DEGAMMA_GREEN_SHIFT;
+ word = word | blue;
+ I915_WRITE(cgm_degamma_reg, word);
+
+ cgm_degamma_reg += 4;
+
+ /* Red (13:0) to be written to DWORD2 */
+ word = red_fract;
+
[PATCH 15/23] drm/i915: CHV: Pipe level Gamma correction
From: Kausal Malladi
CHV/BSW platform supports two different pipe level gamma
correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit CGM (Color Gamut Mapping) mode
This patch does the following:
1. Attaches Gamma property to CRTC
3. Adds the core Gamma correction function for CHV/BSW
4. Adds Gamma correction macros
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 12 +++
drivers/gpu/drm/i915/intel_color_manager.c | 127 +
drivers/gpu/drm/i915/intel_color_manager.h | 21 +
3 files changed, 160 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 67bf205..93aa1f9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7977,4 +7977,16 @@ enum skl_disp_power_wells {
#define GEN9_VEBOX_MOCS_0 0xcb00 /* Video MOCS base register*/
#define GEN9_BLT_MOCS_00xcc00 /* Blitter MOCS base register*/
+/* Color Management */
+#define PIPEA_CGM_CONTROL (VLV_DISPLAY_BASE + 0x67A00)
+#define PIPEB_CGM_CONTROL (VLV_DISPLAY_BASE + 0x69A00)
+#define PIPEC_CGM_CONTROL (VLV_DISPLAY_BASE + 0x6BA00)
+#define PIPEA_CGM_GAMMA(VLV_DISPLAY_BASE + 0x67000)
+#define PIPEB_CGM_GAMMA(VLV_DISPLAY_BASE + 0x69000)
+#define PIPEC_CGM_GAMMA(VLV_DISPLAY_BASE + 0x6B000)
+#define _PIPE_CGM_CONTROL(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL, PIPEC_CGM_CONTROL))
+#define _PIPE_GAMMA_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 2ba3fd7..222924d 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -66,6 +66,127 @@ int intel_color_manager_set_pipe_degamma(struct drm_device
*dev,
return 0;
}
+static int chv_set_gamma(struct drm_device *dev, struct drm_property_blob
*blob,
+ struct drm_crtc *crtc)
+{
+ bool flag = false;
+ enum pipe pipe;
+ u8 red_int, blue_int, green_int;
+ u16 red_fract, green_fract, blue_fract;
+ u32 red, green, blue;
+ u32 cgm_control_reg = 0;
+ u32 cgm_gamma_reg = 0;
+ u32 count = 0, num_samples, word;
+ int ret = 0, length;
+ struct drm_r32g32b32 *correction_values = NULL;
+ struct drm_palette *gamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ gamma_data = (struct drm_palette *)blob->data;
+
+ if (gamma_data->version != GAMMA_DATA_STRUCT_VERSION) {
+ DRM_DEBUG_KMS("Invalid Gamma Data struct version\n");
+ return -EINVAL;
+ }
+
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = gamma_data->num_samples;
+ length = num_samples * sizeof(struct drm_r32g32b32);
+
+ switch (num_samples) {
+ case 0:
+
+ /* Disable Gamma functionality on Pipe - CGM Block */
+ cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+ cgm_control_reg &= ~CGM_GAMMA_EN;
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+
+ DRM_DEBUG_DRIVER("Gamma disabled on Pipe %c\n",
+ pipe_name(pipe));
+ ret = 0;
+ break;
+
+ case CHV_8BIT_GAMMA_MAX_VALS:
+ case CHV_10BIT_GAMMA_MAX_VALS:
+
+ count = 0;
+ cgm_gamma_reg = _PIPE_GAMMA_BASE(pipe);
+ correction_values = (struct drm_r32g32b32 *)&gamma_data->lut;
+
+ while (count < num_samples) {
+ blue = correction_values[count].b32;
+ green = correction_values[count].g32;
+ red = correction_values[count].r32;
+
+ blue_int = _GAMMA_INT_PART(blue);
+ if (blue_int > GAMMA_INT_MAX)
+ blue = CHV_MAX_GAMMA;
+
+ green_int = _GAMMA_INT_PART(green);
+ if (green_int > GAMMA_INT_MAX)
+ green = CHV_MAX_GAMMA;
+
+ red_int = _GAMMA_INT_PART(red);
+ if (red_int > GAMMA_INT_MAX)
+ red = CHV_MAX_GAMMA;
+
+ blue_fract = _GAMMA_FRACT_PART(blue);
+ green_fract = _GAMMA_FRACT_PART(green);
+ red_fract = _GAMMA_FRACT_PART(red);
+
+ blue_fract >>= CHV_10BIT_GAMMA_MSB_SHIFT;
+ green_fract >>= CHV_10BIT_GAMMA_MSB_SHIFT;
+ red_fract >>= CHV_10BIT_GAMMA_MSB_SHIFT;
+
+ /* Green (2
[PATCH 14/23] drm/i915: CHV: Load degamma color correction values
DRM color manager allows the driver to showcase its best color
correction capabilities using the cm_crtc_palette_capabilities_property.
This patch adds no of coefficitents for degamma color correction
modes possible in CHV, in device info structure, which is:
CGM Degamma(10 bit, CGM HW unit):- 65 coeff
These values will be loaded in cm_crtc_palette_capabilities_property
during the CRTC init section, by color manager's attach function.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_drv.c| 1 +
drivers/gpu/drm/i915/intel_color_manager.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 04a8e45..03db841 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -351,6 +351,7 @@ static const struct intel_device_info intel_cherryview_info
= {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = CHV_10BIT_GAMMA_MAX_VALS,
+ .num_samples_before_ctm = CHV_DEGAMMA_MAX_VALS,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index 99ef646..402b825 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -30,3 +30,4 @@
#define COLOR_STRUCT_VERSION 1
#define CHV_10BIT_GAMMA_MAX_VALS 257
+#define CHV_DEGAMMA_MAX_VALS 65
--
1.9.1
[PATCH 13/23] drm/i915: CHV: Load gamma color correction values
DRM color manager allows the driver to showcase its best color
correction capabilities using the cm_crtc_palette_capabilities_property.
Driver loads the no. of coefficients for various color correction
as per the platform, during the init time.
This patch adds no of coefficitents for best gamma color correction
modes possible in CHV, in device info structure, which is:
Gamma(10 bit, CGM HW unit):- 257 coeff
These values will be loaded in cm_crtc_palette_capabilities_property
during the CRTC init section, by color manager's attach function.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_drv.c| 2 ++
drivers/gpu/drm/i915/intel_color_manager.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bdec64c..04a8e45 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -34,6 +34,7 @@
#include "i915_drv.h"
#include "i915_trace.h"
#include "intel_drv.h"
+#include "intel_color_manager.h"
#include
#include
@@ -349,6 +350,7 @@ static const struct intel_device_info intel_cherryview_info
= {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = CHV_10BIT_GAMMA_MAX_VALS,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index 1a42244..99ef646 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -29,3 +29,4 @@
#include "i915_drv.h"
#define COLOR_STRUCT_VERSION 1
+#define CHV_10BIT_GAMMA_MAX_VALS 257
--
1.9.1
[PATCH 12/23] drm/i915: Add pipe CSC correction handlers
This patch adds set_property and get_property handlers for pipe
level CSC color correction for CHV/BSW platform. The set
function just attaches the CSC blob to CRTC state, that later
gets committed using atomic path.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_atomic.c| 8
drivers/gpu/drm/i915/intel_color_manager.c | 19 +++
drivers/gpu/drm/i915/intel_drv.h | 3 +++
3 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index b504b4f..57eafca 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -325,6 +325,9 @@ int intel_crtc_atomic_set_property(struct drm_crtc *crtc,
if (property == config->cm_palette_before_ctm_property)
return intel_color_manager_set_pipe_degamma(dev, state,
&crtc->base, val);
+ if (property == config->cm_ctm_property)
+ return intel_color_manager_set_pipe_csc(dev, state,
+ &crtc->base, val);
DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
return -EINVAL;
@@ -350,6 +353,11 @@ int intel_crtc_atomic_get_property(struct drm_crtc *crtc,
goto found;
}
+ if (property == config->cm_ctm_property) {
+ *val = (state->ctm_blob) ? state->ctm_blob->base.id : 0;
+ goto found;
+ }
+
DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 8890b09..2ba3fd7 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,25 @@
#include "intel_color_manager.h"
+int intel_color_manager_set_pipe_csc(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state,
+ struct drm_mode_object *obj, uint32_t blob_id)
+{
+ struct drm_property_blob *blob;
+
+ blob = drm_property_lookup_blob(dev, blob_id);
+ if (!blob) {
+ DRM_ERROR("Invalid Blob ID\n");
+ return -EINVAL;
+ }
+
+ if (crtc_state->ctm_blob)
+ drm_property_unreference_blob(crtc_state->ctm_blob);
+
+ crtc_state->ctm_blob = blob;
+ return 0;
+}
+
int intel_color_manager_set_pipe_degamma(struct drm_device *dev,
struct drm_crtc_state *crtc_state,
struct drm_mode_object *obj, uint32_t blob_id)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0298dd0..4d571a2f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1473,4 +1473,7 @@ int intel_color_manager_set_pipe_gamma(struct drm_device
*dev,
int intel_color_manager_set_pipe_degamma(struct drm_device *dev,
struct drm_crtc_state *crtc_state,
struct drm_mode_object *obj, uint32_t blob_id);
+int intel_color_manager_set_pipe_csc(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state,
+ struct drm_mode_object *obj, uint32_t blob_id);
#endif /* __INTEL_DRV_H__ */
--
1.9.1
[PATCH 11/23] drm/i915: Add pipe deGamma correction handlers
This patch adds set_property and get_property handlers for deGamma
color correction capability at Pipe level.
Set function just attaches the deGamma correction blob to CRTC state, which
will be later committed in the atomic commit path.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_atomic.c| 10 ++
drivers/gpu/drm/i915/intel_color_manager.c | 20
drivers/gpu/drm/i915/intel_drv.h | 4 +++-
3 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 0b61fef..b504b4f 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -322,6 +322,10 @@ int intel_crtc_atomic_set_property(struct drm_crtc *crtc,
return intel_color_manager_set_pipe_gamma(dev, state,
&crtc->base, val);
+ if (property == config->cm_palette_before_ctm_property)
+ return intel_color_manager_set_pipe_degamma(dev, state,
+ &crtc->base, val);
+
DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
return -EINVAL;
}
@@ -340,6 +344,12 @@ int intel_crtc_atomic_get_property(struct drm_crtc *crtc,
goto found;
}
+ if (property == config->cm_palette_before_ctm_property) {
+ *val = (state->palette_before_ctm_blob) ?
+ state->palette_before_ctm_blob->base.id : 0;
+ goto found;
+ }
+
DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 9421bb6..8890b09 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,26 @@
#include "intel_color_manager.h"
+int intel_color_manager_set_pipe_degamma(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state,
+ struct drm_mode_object *obj, uint32_t blob_id)
+{
+ struct drm_property_blob *blob;
+
+ blob = drm_property_lookup_blob(dev, blob_id);
+ if (!blob) {
+ DRM_ERROR("Invalid Blob ID\n");
+ return -EINVAL;
+ }
+
+ if (crtc_state->palette_before_ctm_blob)
+ drm_property_unreference_blob(
+ crtc_state->palette_before_ctm_blob);
+
+ crtc_state->palette_before_ctm_blob = blob;
+ return 0;
+}
+
int intel_color_manager_set_pipe_gamma(struct drm_device *dev,
struct drm_crtc_state *crtc_state,
struct drm_mode_object *obj, uint32_t blob_id)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d0193e2..0298dd0 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1470,5 +1470,7 @@ extern const struct drm_plane_helper_funcs
intel_plane_helper_funcs;
int intel_color_manager_set_pipe_gamma(struct drm_device *dev,
struct drm_crtc_state *crtc_state,
struct drm_mode_object *obj, uint32_t blob_id);
-
+int intel_color_manager_set_pipe_degamma(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state,
+ struct drm_mode_object *obj, uint32_t blob_id);
#endif /* __INTEL_DRV_H__ */
--
1.9.1
[PATCH 10/23] drm/i915: Add gamma correction handlers
I915 driver registers gamma correction as palette correction
property with DRM layer. This patch adds set_property() and get_property()
handlers for pipe level gamma correction.
The set function attaches the Gamma correction blob to CRTC state, these
values will be committed during atomic commit.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_atomic.c| 20
drivers/gpu/drm/i915/intel_color_manager.c | 21 +
drivers/gpu/drm/i915/intel_drv.h | 5 +
3 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 500d2998..0b61fef 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -315,6 +315,13 @@ int intel_crtc_atomic_set_property(struct drm_crtc *crtc,
struct drm_property *property,
uint64_t val)
{
+ struct drm_device *dev = crtc->dev;
+ struct drm_mode_config *config = &dev->mode_config;
+
+ if (property == config->cm_palette_after_ctm_property)
+ return intel_color_manager_set_pipe_gamma(dev, state,
+ &crtc->base, val);
+
DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
return -EINVAL;
}
@@ -324,6 +331,19 @@ int intel_crtc_atomic_get_property(struct drm_crtc *crtc,
struct drm_property *property,
uint64_t *val)
{
+ struct drm_device *dev = crtc->dev;
+ struct drm_mode_config *config = &dev->mode_config;
+
+ if (property == config->cm_palette_after_ctm_property) {
+ *val = (state->palette_after_ctm_blob) ?
+ state->palette_after_ctm_blob->base.id : 0;
+ goto found;
+ }
+
DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
return -EINVAL;
+
+found:
+ DRM_DEBUG_KMS("Found property %s\n", property->name);
+ return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 77f58f2..9421bb6 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,27 @@
#include "intel_color_manager.h"
+int intel_color_manager_set_pipe_gamma(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state,
+ struct drm_mode_object *obj, uint32_t blob_id)
+{
+ struct drm_property_blob *blob;
+
+ blob = drm_property_lookup_blob(dev, blob_id);
+ if (!blob) {
+ DRM_DEBUG_KMS("Invalid Blob ID\n");
+ return -EINVAL;
+ }
+
+ if (crtc_state->palette_after_ctm_blob)
+ drm_property_unreference_blob(
+ crtc_state->palette_after_ctm_blob);
+
+ /* Attach the blob to be committed in state */
+ crtc_state->palette_after_ctm_blob = blob;
+ return 0;
+}
+
int get_pipe_capabilities(struct drm_device *dev,
struct drm_palette_caps *palette_caps, struct drm_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e27e754..d0193e2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1466,4 +1466,9 @@ void intel_plane_destroy_state(struct drm_plane *plane,
struct drm_plane_state *state);
extern const struct drm_plane_helper_funcs intel_plane_helper_funcs;
+/* intel_color_manager.c */
+int intel_color_manager_set_pipe_gamma(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state,
+ struct drm_mode_object *obj, uint32_t blob_id);
+
#endif /* __INTEL_DRV_H__ */
--
1.9.1
[PATCH 09/23] drm/i915: Register pipe color capabilities
DRM color manager contains these color properties:
1. "crtc_palette_capabilities_property": to allow a
core driver to load and showcase its color correction
capabilities to user space.
2. "ctm": Color transformation matrix property, where a
color transformation matrix of 9 correction values gets
applied as correction.
3. "palette_before_ctm": for corrections which get applied
beore color transformation matrix correction.
4. "palette_after_ctm": for corrections which get applied
after color transformation matrix correction.
Intel color manager registers:
1. Gamma correction property as "palette_after_ctm" property
2. Degamma correction capability as "palette_bafore_ctm" property
capability as "palette_after_ctm" DRM color property hook.
3. CSC as "ctm" property.
This patch does the following:
1. Add a function which loads the platform's color correction
capabilities in the cm_crtc_palette_capabilities_property structure.
2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
getting initiaized.
3. Adds two new parameters "num_samples_after_ctm" and
"num_samples_before_ctm" in intel_device_info as gamma and
degamma coefficients vary per platform basis.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_drv.h| 2 ++
drivers/gpu/drm/i915/intel_color_manager.c | 45 ++
drivers/gpu/drm/i915/intel_color_manager.h | 2 ++
3 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3bf8a9b..22de2cb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -798,6 +798,8 @@ struct intel_device_info {
u8 num_sprites[I915_MAX_PIPES];
u8 gen;
u8 ring_mask; /* Rings supported by the HW */
+ u16 num_samples_after_ctm;
+ u16 num_samples_before_ctm;
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
/* Register offsets for the various display pipes and transcoders */
int pipe_offsets[I915_MAX_TRANSCODERS];
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 7357d99..77f58f2 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,7 +27,52 @@
#include "intel_color_manager.h"
+int get_pipe_capabilities(struct drm_device *dev,
+ struct drm_palette_caps *palette_caps, struct drm_crtc *crtc)
+{
+ struct drm_property_blob *blob;
+
+ /*
+* This function loads best capability for gamma correction
+* For example:
+* CHV best Gamma correction (CGM unit, 10 bit)
+* has 257 entries, best degamma is 65 entries
+*/
+ palette_caps->version = COLOR_STRUCT_VERSION;
+ palette_caps->num_samples_after_ctm =
+ INTEL_INFO(dev)->num_samples_after_ctm;
+ palette_caps->num_samples_before_ctm =
+ INTEL_INFO(dev)->num_samples_before_ctm;
+ blob = drm_property_create_blob(dev, sizeof(struct drm_palette_caps),
+ (const void *) palette_caps);
+ if (IS_ERR_OR_NULL(blob)) {
+ DRM_ERROR("Create blob for capabilities failed\n");
+ return PTR_ERR(blob);
+ }
+
+ return blob->base.id;
+}
+
void intel_attach_color_properties_to_crtc(struct drm_device *dev,
struct drm_mode_object *mode_obj)
{
+ struct drm_mode_config *config = &dev->mode_config;
+ struct drm_palette_caps *palette_caps;
+ struct drm_crtc *crtc;
+ int capabilities_blob_id;
+
+ crtc = obj_to_crtc(mode_obj);
+ palette_caps = kzalloc(sizeof(struct drm_palette_caps),
+ GFP_KERNEL);
+ capabilities_blob_id = get_pipe_capabilities(dev,
+ palette_caps, crtc);
+
+ if (config->cm_crtc_palette_capabilities_property) {
+ drm_object_attach_property(mode_obj,
+ config->cm_crtc_palette_capabilities_property,
+ capabilities_blob_id);
+ DRM_DEBUG_DRIVER("Capabilities attached to CRTC\n");
+ }
+
+ kfree(palette_caps);
}
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index 04c921d..1a42244 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -27,3 +27,5 @@
#include
#include
#include "i915_drv.h"
+
+#define COLOR_STRUCT_VERSION 1
--
1.9.1
[PATCH 08/23] drm/i915: Create color management files
From: Kausal Malladi
This patch create new files intel_color_manager.c which
will contain the core color correction code for I915 driver
and its header intel_color_manager.h
The per color property patches coming up in this patch series
will fill the appropriate functions in this file.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/Makefile | 3 ++-
drivers/gpu/drm/i915/intel_color_manager.c | 33 ++
drivers/gpu/drm/i915/intel_color_manager.h | 29 ++
3 files changed, 64 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 44d290a..56caf9e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -64,7 +64,8 @@ i915-y += intel_audio.o \
intel_overlay.o \
intel_psr.o \
intel_sideband.o \
- intel_sprite.o
+ intel_sprite.o \
+ intel_color_manager.o
i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
new file mode 100644
index 000..7357d99
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -0,0 +1,33 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma
+ * Kausal Malladi
+ */
+
+#include "intel_color_manager.h"
+
+void intel_attach_color_properties_to_crtc(struct drm_device *dev,
+ struct drm_mode_object *mode_obj)
+{
+}
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
new file mode 100644
index 000..04c921d
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma
+ * Kausal Malladi
+ */
+#include
+#include
+#include "i915_drv.h"
--
1.9.1
[PATCH 07/23] drm/i915: Add atomic get property interface for CRTC
From: Kausal Malladi
This patch adds atomic get property interface for Intel CRTC. This
interface will be used for get operation on any non-core DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_atomic.c | 9 +
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 4
3 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index d5b7eb1..500d2998 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -318,3 +318,12 @@ int intel_crtc_atomic_set_property(struct drm_crtc *crtc,
DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
return -EINVAL;
}
+
+int intel_crtc_atomic_get_property(struct drm_crtc *crtc,
+ const struct drm_crtc_state *state,
+ struct drm_property *property,
+ uint64_t *val)
+{
+ DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
+ return -EINVAL;
+}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 444ea30..010acca 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13194,6 +13194,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.page_flip = intel_crtc_page_flip,
.set_property = drm_atomic_helper_crtc_set_property,
.atomic_set_property = intel_crtc_atomic_set_property,
+ .atomic_get_property = intel_crtc_atomic_get_property,
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
};
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 510f559..e27e754 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1454,6 +1454,10 @@ int intel_crtc_atomic_set_property(struct drm_crtc
*plane,
struct drm_crtc_state *state,
struct drm_property *property,
uint64_t val);
+int intel_crtc_atomic_get_property(struct drm_crtc *plane,
+ const struct drm_crtc_state *state,
+ struct drm_property *property,
+ uint64_t *val);
/* intel_atomic_plane.c */
struct intel_plane_state *intel_create_plane_state(struct drm_plane *plane);
--
1.9.1
[PATCH 06/23] drm/i915: Add atomic set property interface for CRTC
From: Kausal Malladi
This patch adds atomic set property interface for Intel CRTC. This
interface will be used for set operation on any DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_atomic.c | 9 +
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 4
3 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index f1975f2..d5b7eb1 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -309,3 +309,12 @@ void intel_atomic_state_clear(struct drm_atomic_state *s)
drm_atomic_state_default_clear(&state->base);
state->dpll_set = false;
}
+
+int intel_crtc_atomic_set_property(struct drm_crtc *crtc,
+ struct drm_crtc_state *state,
+ struct drm_property *property,
+ uint64_t val)
+{
+ DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
+ return -EINVAL;
+}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fc00867..444ea30 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13192,6 +13192,8 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.destroy = intel_crtc_destroy,
.page_flip = intel_crtc_page_flip,
+ .set_property = drm_atomic_helper_crtc_set_property,
+ .atomic_set_property = intel_crtc_atomic_set_property,
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
};
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 02a755a..510f559 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1450,6 +1450,10 @@ intel_atomic_get_crtc_state(struct drm_atomic_state
*state,
int intel_atomic_setup_scalers(struct drm_device *dev,
struct intel_crtc *intel_crtc,
struct intel_crtc_state *crtc_state);
+int intel_crtc_atomic_set_property(struct drm_crtc *plane,
+ struct drm_crtc_state *state,
+ struct drm_property *property,
+ uint64_t val);
/* intel_atomic_plane.c */
struct intel_plane_state *intel_create_plane_state(struct drm_plane *plane);
--
1.9.1
[PATCH 05/23] drm: Add structure to set/get a CTM color property
From: Kausal Malladi
Color Manager framework defines a color correction property for color
space transformation and Gamut mapping. This property is called CTM (Color
Transformation Matrix).
This patch adds a new structure in DRM layer for CTM.
This structure can be used by all user space agents to
configure CTM coefficients for color correction.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index f72b916..9580772 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -867,6 +867,18 @@ struct drm_palette {
struct drm_r32g32b32 lut[0];
};
+struct drm_ctm {
+ /* Structure version. Should be 1 currently */
+ __u32 version;
+ /*
+* Each value is in S31.32 format.
+* This is 3x3 matrix in row major format.
+* Integer part will be clipped to nearest
+* max/min boundary as supported by the HW platform.
+*/
+ __s64 ctm_coeff[9];
+};
+
/* typedef area */
#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.9.1
[PATCH 04/23] drm: Add drm structures for palette color property
From: Kausal Malladi
This patch adds new structures in DRM layer for Palette color
correction.These structures will be used by user space agents
to configure appropriate number of samples and Palette LUT for
a platform.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index e3c642f..f72b916 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -840,6 +840,33 @@ struct drm_palette_caps {
__u32 num_samples_after_ctm;
};
+struct drm_r32g32b32 {
+ /*
+* Data is in U8.24 fixed point format.
+* All platforms support values within [0, 1.0] range,
+* for Red, Green and Blue colors.
+*/
+ __u32 r32;
+ __u32 g32;
+ __u32 b32;
+};
+
+struct drm_palette {
+ /* Structure version. Should be 1 currently */
+ __u32 version;
+ /*
+* This has to be a supported value during get call.
+* Feature will be disabled if this is 0 while set
+*/
+ __u32 num_samples;
+ /*
+* Starting of palette LUT in R32G32B32 format.
+* Each of RGB value is in U8.24 fixed point format.
+* Actual number of samples will depend upon num_samples
+*/
+ struct drm_r32g32b32 lut[0];
+};
+
/* typedef area */
#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.9.1
[PATCH 03/23] drm: Add color correction blobs in CRTC state
From: Kausal Malladi
This patch adds new variables in CRTC state, to hold respective color
correction blobs. These blobs will be required during the atomic commit
for writing the color correction values in correction registers.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/drm_atomic_helper.c | 12
include/drm/drm_crtc.h | 5 +
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 94d6c8e..1fe91ee 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2168,6 +2168,12 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
if (state->mode_blob)
drm_property_reference_blob(state->mode_blob);
+ if (state->ctm_blob)
+ drm_property_reference_blob(state->ctm_blob);
+ if (state->palette_after_ctm_blob)
+ drm_property_reference_blob(state->palette_after_ctm_blob);
+ if (state->palette_before_ctm_blob)
+ drm_property_reference_blob(state->palette_before_ctm_blob);
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -2213,6 +2219,12 @@ void __drm_atomic_helper_crtc_destroy_state(struct
drm_crtc *crtc,
{
if (state->mode_blob)
drm_property_unreference_blob(state->mode_blob);
+ if (state->ctm_blob)
+ drm_property_unreference_blob(state->ctm_blob);
+ if (state->palette_after_ctm_blob)
+ drm_property_unreference_blob(state->palette_after_ctm_blob);
+ if (state->palette_before_ctm_blob)
+ drm_property_unreference_blob(state->palette_before_ctm_blob);
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c35531e..fcbe682 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -302,6 +302,11 @@ struct drm_crtc_state {
/* blob property to expose current mode to atomic userspace */
struct drm_property_blob *mode_blob;
+ /* blob properties to hold the color properties' blobs */
+ struct drm_property_blob *palette_before_ctm_blob;
+ struct drm_property_blob *palette_after_ctm_blob;
+ struct drm_property_blob *ctm_blob;
+
struct drm_pending_vblank_event *event;
struct drm_atomic_state *state;
--
1.9.1
[PATCH 02/23] drm: Add structure for querying palette color capabilities
From: Kausal Malladi
The DRM color management framework is targeting various hardware
platforms and drivers. Different platforms can have different color
correction and enhancement capabilities.
A commom user space application can query these capabilities using the
DRM property interface. Each driver can fill this property with its
platform's palette color capabilities.
This patch adds new structure in DRM layer for querying palette color
capabilities. This structure will be used by all user space
agents to configure appropriate color configurations.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..e3c642f 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -829,6 +829,17 @@ struct drm_event_vblank {
__u32 reserved;
};
+struct drm_palette_caps {
+ /* Structure version. Should be 1 currently */
+ __u32 version;
+ /* For padding and future use */
+ __u32 reserved;
+ /* This may be 0 if not supported. e.g. plane palette or VLV pipe */
+ __u32 num_samples_before_ctm;
+ /* This will be non-zero for pipe. May be zero for planes on some HW */
+ __u32 num_samples_after_ctm;
+};
+
/* typedef area */
#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.9.1
[PATCH 01/23] drm: Create Color Management DRM properties
From: Kausal Malladi
Color Management is an extension to Kernel display framework. It allows
abstraction of hardware color correction and enhancement capabilities by
virtue of DRM properties.
This patch initializes color management framework by :
1. Introducing new pointers in DRM mode_config structure to
carry CTM and Palette color correction properties.
2. Creating these DRM properties in DRM standard properties creation
sequence.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/drm_crtc.c | 26 ++
include/drm/drm_crtc.h | 6 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9b9c4b4..d809c67 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1472,6 +1472,32 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_mode_id = prop;
+ /* Color Management properties */
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB | DRM_MODE_PROP_IMMUTABLE,
+ "CRTC_PALETTE_CAPABILITIES", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_crtc_palette_capabilities_property = prop;
+
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB, "PALETTE_AFTER_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_palette_after_ctm_property = prop;
+
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB, "PALETTE_BEFORE_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_palette_before_ctm_property = prop;
+
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB, "CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_ctm_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c0366e9..c35531e 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1153,6 +1153,12 @@ struct drm_mode_config {
struct drm_property *suggested_x_property;
struct drm_property *suggested_y_property;
+ /* Color Management Properties */
+ struct drm_property *cm_crtc_palette_capabilities_property;
+ struct drm_property *cm_palette_before_ctm_property;
+ struct drm_property *cm_palette_after_ctm_property;
+ struct drm_property *cm_ctm_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
--
1.9.1
[PATCH 00/23] Color Management for DRM
This patch set adds Color Manager implementation in DRM layer. Color Manager is an extension in DRM framework to support color correction/enhancement. Various Hardware platforms can support several color correction capabilities. Color Manager provides abstraction of these capabilities and allows a user space UI agent to correct/enhance the display using the DRM property interface. How is this going to work? == 1. This patch series adds a few new properties in DRM framework. These properties are: a. color_capabilities property (type blob) b. Color Transformation Matrix property for corrections like CSC (called CTM, type blob) c. Palette correction properties for corrections like gamma fixup (called palette_correction, type blob) 2. Also, this patch series adds few structures to indicate specifications of a property like size, no_of_samples for correction etc. 3. These properties are present in mode_config. 4. When the platform's display driver loads, it fills up the values of color_capabilities property using the standard structures (added in step 2). For example, Intel's I915 driver adds following color correction capabilities: a. gamma correction capability as palette correction property, with 257 correction coefficients and a max/min value b. csc correction capability as CTM correction property, with 3x3 transformation matrix values and max/min values 5. Now when userspace comes up, it queries the platform's color capabilities by doing a get_property() on color_capabilities DRM property 6. Reading the blob, the userspace understands the color capabilities of the platform. For example, userspace will understand it can support: a. palette_correction with 257 coefficients b. CSC correction with 3x3 = 9 values 7. To set color correction values, userspace: a. creates a blob using the create_blob_ioctl in standard palette_correction structure format, with the correction values b. calls the set_property_ioctl with the blob_id as value for the property 8. Driver refers to the blob, gets the correction values and applies the correction in HW. 9. To get currently applied color correction values, userspace: a. calls a get_property_ioctl on that color property b. gets the blob_id for the currently applied correction from DRM infrastructure c. gets the blob using get_blob_ioctl and hence the currently applied values That's all! :) About the patch series: === The patch series first adds the color management support in DRM layer. Then it adds the color management framework in I915 layer. After that, it implements platform specific core color correction functios. Intel color manager registers color correction with DRM color manager in this way: - CSC transformation is registered as CTM DRM property - Gamma correction is registered as palette_after_ctm DRM property - Degamma correction is registered as palette_before_ctm DRM property Our thanks to all the reviewers who have given valuable comments in terms of design and implementation to our previous sets of patches. Special mention of thanks should go to Matt Roper for all his inputs/suggestions in implementation of this module, using DRM atomic CRTC commit path. V2: Worked on review comments from Matt, Jim, Thierry, Rob. V3: Worked on review comments from Matt, Jim, Rob: - Jim, Rob: Re-arranged the whole patch series in the sequence of features, currently: First 5 patches add color management support in DRM layer Next 7 patches add Intel color management framework in I915 driver Next 5 patches add color correction for CHV (gamma, degamma and CSC) Next 2 patches enable color management, by attaching the properties to CRTC(Matt) Next 4 patches add color correction for BDW (gamma, degamma) - Matt: = Patch 3: Added refernce/unreference for blob Patch 7: return -EINVAL and added debug message Patch 8: check for valid blob, from create blob moved call to intel_crtc_attach_color_prop in the end of full implementation (CHV) Patch 9: DRM_ERROR->DRM_DEBUG for NULL blob case Patch 13: Added static for internal functions Patch 20-24: renamed gen9_* functions to bdw_* Added new variables in device_info structure num_samples_after_ctm and num_samples_before_ctm Added new function in patch 8 to load capabilities based on device_info across all platforms Shashank Sharma (23): drm: Create Color Management DRM properties drm: Add structure for querying palette color capabilities drm: Add color correction blobs in CRTC state drm: Add drm structures for palette color property drm: Add structure to set/get a CTM color property drm/i915: Add atomic set property interface for CRTC drm/i915: Add atomic get property interface for CRTC drm/i915: Create color management files drm/i915: Register pipe color capabilities drm
[PATCH v3] pci: Handle 5-bit and 8-bit tag field
If the hardware supports extended tag field (8-bit ones), then enabled it. This
is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
In case extended tag field is not supported, 5-bit tag field is used which
limits the possible values to 32. Apparently bits 7:0 of 0x8841c stores some
number of outstanding requests, so cap it to 32 if extended tag is unsupported.
Fixes: fdo#86537
v2: Restrict changes to chipsets >= 0x84
v3:
* Add nvkm_pci_mask to pci.h
* Mask bit 8 before setting it
Signed-off-by: Pierre Moreau
---
drm/nouveau/include/nvkm/subdev/pci.h | 1 +
drm/nouveau/nvkm/subdev/pci/base.c| 25 +
2 files changed, 26 insertions(+)
diff --git a/drm/nouveau/include/nvkm/subdev/pci.h
b/drm/nouveau/include/nvkm/subdev/pci.h
index 5b3c054..774ca66 100644
--- a/drm/nouveau/include/nvkm/subdev/pci.h
+++ b/drm/nouveau/include/nvkm/subdev/pci.h
@@ -24,6 +24,7 @@ struct nvkm_pci {
u32 nvkm_pci_rd32(struct nvkm_pci *, u16 addr);
void nvkm_pci_wr08(struct nvkm_pci *, u16 addr, u8 data);
void nvkm_pci_wr32(struct nvkm_pci *, u16 addr, u32 data);
+u32 nvkm_pci_mask(struct nvkm_pci *, u16 addr, u32 mask, u32 add);
void nvkm_pci_rom_shadow(struct nvkm_pci *, bool shadow);
int nv04_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
diff --git a/drm/nouveau/nvkm/subdev/pci/base.c
b/drm/nouveau/nvkm/subdev/pci/base.c
index d1c148e..cb2835b 100644
--- a/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drm/nouveau/nvkm/subdev/pci/base.c
@@ -46,6 +46,14 @@ nvkm_pci_wr32(struct nvkm_pci *pci, u16 addr, u32 data)
pci->func->wr32(pci, addr, data);
}
+u32
+nvkm_pci_mask(struct nvkm_pci *pci, u16 addr, u32 mask, u32 add)
+{
+ u32 data = pci->func->rd32(pci, addr);
+ pci->func->wr32(pci, addr, (data & ~mask) | add);
+ return data;
+}
+
void
nvkm_pci_rom_shadow(struct nvkm_pci *pci, bool shadow)
{
@@ -115,6 +123,23 @@ nvkm_pci_init(struct nvkm_subdev *subdev)
if (ret)
return ret;
+ if (pci_is_pcie(pdev) && subdev->device->chipset >= 0x84) {
+ /* Tag field is 8-bit long, regardless of EXT_TAG.
+* However, if EXT_TAG is disabled, only the lower 5 bits of
the tag
+* field should be used, limiting the number of request to 32.
+*
+* Apparently, 0x041c stores some limit on the number of
requests
+* possible, so if EXT_TAG is disabled, limit that requests
number to
+* 32
+*
+* Fixes fdo#86537
+*/
+ if (nvkm_pci_rd32(pci, 0x007c) & 0x0020)
+ nvkm_pci_mask(pci, 0x0080, 0x0100, 0x0100);
+ else
+ nvkm_pci_mask(pci, 0x041c, 0x0060, 0x);
+ }
+
pci->irq = pdev->irq;
return ret;
}
--
2.5.2
[PATCH v2] pci: Handle 5-bit and 8-bit tag field
If the hardware supports extended tag field (8-bit ones), then enabled it. This
is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
In case extended tag field is not supported, 5-bit tag field is used which
limits the possible values to 32. Apparently bits 7:0 of 0x8841c stores some
number of outstanding requests, so cap it to 32 if extended tag is unsupported.
Fixes: fdo#86537
v2: Restrict changes to chipsets >= 0x84
Signed-off-by: Pierre Moreau
---
drm/nouveau/nvkm/subdev/pci/base.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drm/nouveau/nvkm/subdev/pci/base.c
b/drm/nouveau/nvkm/subdev/pci/base.c
index d1c148e..bbad29d 100644
--- a/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drm/nouveau/nvkm/subdev/pci/base.c
@@ -46,6 +46,14 @@ nvkm_pci_wr32(struct nvkm_pci *pci, u16 addr, u32 data)
pci->func->wr32(pci, addr, data);
}
+u32
+nvkm_pci_mask(struct nvkm_pci *pci, u16 addr, u32 mask, u32 add)
+{
+ u32 data = pci->func->rd32(pci, addr);
+ pci->func->wr32(pci, addr, (data & ~mask) | add);
+ return data;
+}
+
void
nvkm_pci_rom_shadow(struct nvkm_pci *pci, bool shadow)
{
@@ -115,6 +123,23 @@ nvkm_pci_init(struct nvkm_subdev *subdev)
if (ret)
return ret;
+ if (pci_is_pcie(pdev) && subdev->device->chipset >= 0x84) {
+ /* Tag field is 8-bit long, regardless of EXT_TAG.
+* However, if EXT_TAG is disabled, only the lower 5 bits of
the tag
+* field should be used, limiting the number of request to 32.
+*
+* Apparently, 0x041c stores some limit on the number of
requests
+* possible, so if EXT_TAG is disabled, limit that requests
number to
+* 32
+*
+* Fixes fdo#86537
+*/
+ if (nvkm_pci_rd32(pci, 0x007c) & 0x0020)
+ nvkm_pci_mask(pci, 0x0080, 0x, 0x0100);
+ else
+ nvkm_pci_mask(pci, 0x041c, 0x0060, 0x);
+ }
+
pci->irq = pdev->irq;
return ret;
}
--
2.5.2
[PATCH] drm: Allow also control clients to check the drm version
Hi On Wed, Sep 16, 2015 at 5:03 PM, Thomas Hellstrom wrote: > Hi, David, > > On 09/16/2015 04:35 PM, David Herrmann wrote: >> Hi >> >> On Tue, Sep 15, 2015 at 10:11 AM, Thomas Hellstrom >> wrote: >>> This should be harmless. >>> Vmware will, due to old infrastructure reasons, be using a privileged >>> control client to supply GUI layout information rather than obtaining >>> it from the device. That control client will be needing access to DRM >>> version information. >> I didn't add it to render-nodes as I wasn't aware of any driver still >> using the version-information. > > In fact you did add it to render nodes (commit 3d3b78c), but this is for > control nodes. Sorry, my bad. For control nodes is also fine. Thanks David
[PATCH 12/31] drm/amdgpu: use kmemdup rather than duplicating its implementation
On 16.09.2015 11:56, Andrzej Hajda wrote: > Ping. > > Regards > Andrzej > > On 08/07/2015 09:59 AM, Andrzej Hajda wrote: >> The patch was generated using fixed coccinelle semantic patch >> scripts/coccinelle/api/memdup.cocci [1]. >> >> [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320 >> >> Signed-off-by: Andrzej Hajda Somehow missed that. Patch is Reviewed-by: Christian König . Regards, Christian. >> --- >> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >> index 8da6424..94bd992 100644 >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >> @@ -549,12 +549,10 @@ int amdgpu_bo_set_metadata (struct amdgpu_bo *bo, void >> *metadata, >> if (metadata == NULL) >> return -EINVAL; >> >> -buffer = kzalloc(metadata_size, GFP_KERNEL); >> +buffer = kmemdup(metadata, metadata_size, GFP_KERNEL); >> if (buffer == NULL) >> return -ENOMEM; >> >> -memcpy(buffer, metadata, metadata_size); >> - >> kfree(bo->metadata); >> bo->metadata_flags = flags; >> bo->metadata = buffer; > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [rfc] drm/mst: split connector registration into two parts
From: Dave Airlie
In order to cache the EDID properly for tiled displays, we
need to retrieve it before we register the connector with
userspace, otherwise userspace can call get resources
and try and get the edid before we've even cached it.
This fixes some problems when hotplugging mst monitors,
with X/mutter running.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 1 +
drivers/gpu/drm/i915/intel_dp_mst.c| 9 -
drivers/gpu/drm/radeon/radeon_dp_mst.c | 10 +-
include/drm/drm_dp_mst_helper.h| 1 +
4 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index f6acb57..1b0ca1f 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1129,6 +1129,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
*mstb,
if (port->port_num >= 8) {
port->cached_edid = drm_get_edid(port->connector,
&port->aux.ddc);
}
+ (*mstb->mgr->cbs->register_connector)(port->connector);
}
out:
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3e4be5a..6ade068 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -462,11 +462,17 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
drm_object_attach_property(&connector->base,
dev->mode_config.tile_property, 0);
drm_mode_connector_set_path_property(connector, pathprop);
+ return connector;
+}
+
+static void intel_dp_register_mst_connector(struct drm_connector *connector)
+{
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct drm_device *dev = connector->dev;
drm_modeset_lock_all(dev);
intel_connector_add_to_fbdev(intel_connector);
drm_modeset_unlock_all(dev);
drm_connector_register(&intel_connector->base);
- return connector;
}
static void intel_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
@@ -512,6 +518,7 @@ static void intel_dp_mst_hotplug(struct
drm_dp_mst_topology_mgr *mgr)
static 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,
.hotplug = intel_dp_mst_hotplug,
};
diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
b/drivers/gpu/drm/radeon/radeon_dp_mst.c
index 5e09c06..9a9193b 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
@@ -286,12 +286,19 @@ static struct drm_connector
*radeon_dp_add_mst_connector(struct drm_dp_mst_topol
drm_object_attach_property(&connector->base,
dev->mode_config.path_property, 0);
drm_mode_connector_set_path_property(connector, pathprop);
+ return connector;
+}
+
+static void radeon_dp_register_mst_connector(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct radeon_device *rdev = dev->dev_private;
+
drm_modeset_lock_all(dev);
radeon_fb_add_connector(rdev, connector);
drm_modeset_unlock_all(dev);
drm_connector_register(connector);
- return connector;
}
static void radeon_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
@@ -324,6 +331,7 @@ static void radeon_dp_mst_hotplug(struct
drm_dp_mst_topology_mgr *mgr)
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,
.hotplug = radeon_dp_mst_hotplug,
};
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 86d0b25..0f408b0 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -374,6 +374,7 @@ struct drm_dp_mst_topology_mgr;
struct drm_dp_mst_topology_cbs {
/* create a connector for a port */
struct drm_connector *(*add_connector)(struct drm_dp_mst_topology_mgr
*mgr, struct drm_dp_mst_port *port, const char *path);
+ void (*register_connector)(struct drm_connector *connector);
void (*destroy_connector)(struct drm_dp_mst_topology_mgr *mgr,
struct drm_connector *connector);
void (*hotplug)(struct drm_dp_mst_topology_mgr *mgr);
--
2.5.0
[PATCH RFCv2 3/4] staging: etnaviv: add drm driver
On Wed, Sep 16, 2015 at 11:05:11AM -0400, Eric Anholt wrote:
> Lucas Stach writes:
>
> > From: Christian Gmeiner
>
> > +static bool etnaviv_validate_load_state(struct etnaviv_gpu *gpu, u32 *buf,
> > + unsigned int state, unsigned int num)
> > +{
> > + return true;
...
> > +}
>
> I was browsing the code, and noticed that it looks like you've got a
> debugging early return in your validation function here.
That's because it's not quite ready to be enabled yet - the code as
it stands in my tree doesn't have the infrastructure to validate that
a LOADSTATE which touches an address register (or similar) has a
relocation appropriately marked, due to the way things happen.
Hopefully, when the user/kernel API is sorted, this can be resolved.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
[PATCH RFC 6/8] drm: hisilicon: Add support for fbdev
On 16 September 2015 at 02:25, Rob Herring wrote: Hi Rob, thanks a lot for reply:-) On 09/15/2015 04:37 AM, Xinwei Kong wrote: > > If you config DRM_HISI_FBDEV optional, this patch will only support fbdev > > mode while also supporting double buffer. > > This is a lot of duplicated code from CMA fbdev. Is double buffering the > only reason why CMA fbdev can't be used or are there some other > constraints? Yes, double buffering is the main reason we rewrite our own fbdev. CMA fbdev only create one buffer. But we need at least double buffer for running Android with fbdev. Double buffering in fbdev has always been a hack, so I'm > guessing that is not a feature that should be added here. > > If so, I think it is hard to be accepted for my cma fbdev patch to support multi buffer. This early week, I have sent a cma fbdev patch for supporting this. The subject is "[PATCH] drm/cma-helper: Add multi buffer support for cma fbdev". We do have a strong will to support this feature. I described the reason in the patch. Please take a look for me. Thank you very much. -Xinliang Rob > > > Signed-off-by: Xinliang Liu > > Signed-off-by: Xinwei Kong > > Signed-off-by: Andy Green > > Signed-off-by: Jiwen Qi > > Signed-off-by: Yu Gong > > --- > > drivers/gpu/drm/hisilicon/Kconfig | 13 + > > drivers/gpu/drm/hisilicon/Makefile | 3 +- > > drivers/gpu/drm/hisilicon/hisi_drm_connector.c | 4 + > > drivers/gpu/drm/hisilicon/hisi_drm_drv.c | 9 + > > drivers/gpu/drm/hisilicon/hisi_drm_dsi.c | 15 + > > drivers/gpu/drm/hisilicon/hisi_drm_fb.h| 5 + > > drivers/gpu/drm/hisilicon/hisi_drm_fbdev.c | 395 > + > > drivers/gpu/drm/hisilicon/hisi_drm_fbdev.h | 24 ++ > > 8 files changed, 467 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_fbdev.c > > create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_fbdev.h > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150916/2b0517ac/attachment.html>
[PATCH] drm/i915: fix kernel-doc warnings in i915_gem_gtt.c
On Tue, 15 Sep 2015, Geliang Tang wrote: > Fix the following 'make htmldocs' warnings: > > .//drivers/gpu/drm/i915/i915_gem_gtt.c:758: warning: No description found > for parameter 'length' > .//drivers/gpu/drm/i915/i915_gem_gtt.c:818: warning: No description found > for parameter 'length' > .//drivers/gpu/drm/i915/i915_gem_gtt.c:818: warning: No description found > for parameter 'new_pds' > .//drivers/gpu/drm/i915/i915_gem_gtt.c:758: warning: No description found > for parameter 'length' > .//drivers/gpu/drm/i915/i915_gem_gtt.c:818: warning: No description found > for parameter 'length' > .//drivers/gpu/drm/i915/i915_gem_gtt.c:818: warning: No description found > for parameter 'new_pds' These are already fixed by commit d4ec9da0e17cb6a86c0b76c5b254981601d25031 Author: Michel Thierry Date: Thu Jul 30 11:02:03 2015 +0100 drm/i915/gen8: Abstract PDP usage Thanks, Jani. > > Signed-off-by: Geliang Tang > --- > drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > b/drivers/gpu/drm/i915/i915_gem_gtt.c > index 96054a5..c070a1f 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > @@ -737,7 +737,7 @@ static void gen8_ppgtt_cleanup(struct i915_address_space > *vm) > * @ppgtt: Master ppgtt structure. > * @pd: Page directory for this address range. > * @start: Starting virtual address to begin allocations. > - * @length Size of the allocations. > + * @length: Size of the allocations. > * @new_pts: Bitmap set by function with new allocations. Likely used by the > * caller to free on error. > * > @@ -792,8 +792,8 @@ unwind_out: > * @ppgtt: Master ppgtt structure. > * @pdp: Page directory pointer for this address range. > * @start: Starting virtual address to begin allocations. > - * @length Size of the allocations. > - * @new_pds Bitmap set by function with new allocations. Likely used by the > + * @length: Size of the allocations. > + * @new_pds: Bitmap set by function with new allocations. Likely used by the > * caller to free on error. > * > * Allocate the required number of page directories starting at the pde > index of > -- > 1.9.1 > > -- Jani Nikula, Intel Open Source Technology Center
[PATCH] drm/i915: fix kernel-doc warnings in intel_lrc.c
On Tue, 15 Sep 2015, Geliang Tang wrote: > Fix the following 'make htmldocs' warnings: > > .//drivers/gpu/drm/i915/intel_lrc.c:780: warning: No description found for > parameter 'req' > .//drivers/gpu/drm/i915/intel_lrc.c:780: warning: Excess function parameter > 'request' description in 'intel_logical_ring_begin' > .//drivers/gpu/drm/i915/intel_lrc.c:780: warning: Excess function parameter > 'ctx' description in 'intel_logical_ring_begin' This is already fixed by commit 374887bae861be2e691381f704b3d6068a54457c Author: Masanari Iida Date: Sun Sep 13 21:08:31 2015 +0900 drm/i915: Fix warnings while make xmldocs caused by intel_lrc.c Thanks, Jani. > > Signed-off-by: Geliang Tang > --- > drivers/gpu/drm/i915/intel_lrc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index 72e0edd..963992a 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -765,8 +765,7 @@ static int logical_ring_prepare(struct > drm_i915_gem_request *req, int bytes) > /** > * intel_logical_ring_begin() - prepare the logical ringbuffer to accept > some commands > * > - * @request: The request to start some new work for > - * @ctx: Logical ring context whose ringbuffer is being prepared. > + * @req: The request to start some new work for > * @num_dwords: number of DWORDs that we plan to write to the ringbuffer. > * > * The ringbuffer might not be ready to accept the commands right away > (maybe it needs to > -- > 1.9.1 > > -- Jani Nikula, Intel Open Source Technology Center
[PATCH] drm: Allow also control clients to check the drm version
Hi, David,
On 09/16/2015 04:35 PM, David Herrmann wrote:
> Hi
>
> On Tue, Sep 15, 2015 at 10:11 AM, Thomas Hellstrom
> wrote:
>> This should be harmless.
>> Vmware will, due to old infrastructure reasons, be using a privileged
>> control client to supply GUI layout information rather than obtaining
>> it from the device. That control client will be needing access to DRM
>> version information.
> I didn't add it to render-nodes as I wasn't aware of any driver still
> using the version-information.
In fact you did add it to render nodes (commit 3d3b78c), but this is for
control nodes.
> I'm not a big fan on relying on magic
> numbers, as it doesn't work well with (stable) backports, but if you
> need it for backwards-compat on vmwgfx, I'm fine with it. But I
> certainly don't want to encourage new driver authors to use it.
We view the driver version information as user-space api version
information, which I can't see changing
with stable backports (except perhaps in very unlikely situations).
Of course, there are other ways to signal feature availability, but
we've traditionally been checking version minor.
>
>> Signed-off-by: Thomas Hellstrom
>> Reviewed-by: Brian Paul
>> Reviewed-by: Sinclair Yeh
>> ---
>> drivers/gpu/drm/drm_ioctl.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
>> index 9a860ca..d93e737 100644
>> --- a/drivers/gpu/drm/drm_ioctl.c
>> +++ b/drivers/gpu/drm/drm_ioctl.c
>> @@ -520,7 +520,8 @@ EXPORT_SYMBOL(drm_ioctl_permit);
>>
>> /** Ioctl table */
>> static const struct drm_ioctl_desc drm_ioctls[] = {
>> - DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version,
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version,
>> + DRM_UNLOCKED|DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW),
> Why the line-break? None of the other ioctl definitions cares for the
> 80ch limit. I'd prefer keeping this uniform.
OK, I'll fix that up.
>
> Acked-by: David Herrmann
>
> Thanks
> David
Thanks,
Thomas
>
>> DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
>> DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, 0),
>> DRM_IOCTL_DEF(DRM_IOCTL_IRQ_BUSID, drm_irq_by_busid,
>> DRM_MASTER|DRM_ROOT_ONLY),
>> --
>> 2.1.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=BQIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=-dqJN9pZD2sav6M76SFMIM359ZWmPz3fLT0oU30MVRw&s=ICMYbx449lJwRcYDljH6Z8Zp9SQO6mX71E9Y9OgL_SA&e=
>>
[PATCH] drm: Allow also control clients to check the drm version
Hi
On Tue, Sep 15, 2015 at 10:11 AM, Thomas Hellstrom
wrote:
> This should be harmless.
> Vmware will, due to old infrastructure reasons, be using a privileged
> control client to supply GUI layout information rather than obtaining
> it from the device. That control client will be needing access to DRM
> version information.
I didn't add it to render-nodes as I wasn't aware of any driver still
using the version-information. I'm not a big fan on relying on magic
numbers, as it doesn't work well with (stable) backports, but if you
need it for backwards-compat on vmwgfx, I'm fine with it. But I
certainly don't want to encourage new driver authors to use it.
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Brian Paul
> Reviewed-by: Sinclair Yeh
> ---
> drivers/gpu/drm/drm_ioctl.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 9a860ca..d93e737 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -520,7 +520,8 @@ EXPORT_SYMBOL(drm_ioctl_permit);
>
> /** Ioctl table */
> static const struct drm_ioctl_desc drm_ioctls[] = {
> - DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version,
> + DRM_UNLOCKED|DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW),
Why the line-break? None of the other ioctl definitions cares for the
80ch limit. I'd prefer keeping this uniform.
Acked-by: David Herrmann
Thanks
David
> DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
> DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, 0),
> DRM_IOCTL_DEF(DRM_IOCTL_IRQ_BUSID, drm_irq_by_busid,
> DRM_MASTER|DRM_ROOT_ONLY),
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 1/8] dt-bindings: Document the hi6220 bindings for DRM driver
hi architt On 2015/9/16 2:11, Rob Herring wrote: > On 09/15/2015 04:37 AM, Xinwei Kong wrote: >> This adds documentation of device tree bindings for the >> Graphics Processing Unit of hi6220 SOC. >> >> Signed-off-by: Xinliang Liu >> Signed-off-by: Xinwei Kong >> Signed-off-by: Andy Green >> Signed-off-by: Jiwen Qi >> Signed-off-by: Yu Gong >> --- >> .../devicetree/bindings/gpu/hisilicon,hi6220.txt | 69 >> ++ >> 1 file changed, 69 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/gpu/hisilicon,hi6220.txt >> >> diff --git a/Documentation/devicetree/bindings/gpu/hisilicon,hi6220.txt >> b/Documentation/devicetree/bindings/gpu/hisilicon,hi6220.txt >> new file mode 100644 >> index 000..173ac63 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/gpu/hisilicon,hi6220.txt >> @@ -0,0 +1,69 @@ >> + * Hisilicon hi6220 Graphics Processing Unit for HiKey board >> + >> + ** display-subsystem: Master device for binding DRM sub-components > > DRM is a Linuxism that doesn't belong in the binding. > >> +This master device is parent node and it will be responsible to bind all >> +sub-components devices node. > > Are these nodes a single block in the h/w? If not, you should describe > the connection of sub-nodes with of-graph instead. > >> +- Required properties : >> + - compatible: "hisilicon,display-subsystem". >> + - #address-cells, #size-cells: Must be present if the device has >> sub-nodes. >> + - ranges: to allow probing of subdevices. >> + - dma-coherent: Present if dma operations are coherent. >> + >> + ** ade: Graphic overlay, Graphic post-processing, display timing control. >> +This device is child node of display-subsystem >> +- Required properties : >> + - compatible: "hisilicon,hi6220-ade". >> + - reg: physical base address of the ADE register and length of memory >> +region. >> + - reg-names: Should contain the reg names "ade_base" and "media_base". >> + - interrupt: The interrupt number to the cpu. Defines the interrupt >> +by ADE. >> + - clocks: The clocks needed by the ADE module. >> + - clock-names: the name of the clocks. >> + >> + ** dsi: support mipi dsi interface >> +This device is child node of display-subsystem >> +- Required properties : >> + - compatible: "hisilicon,hi6220-dsi". >> + - reg: physical base address of the DSI register and length of memory >> +region. >> + - clocks: The clocks needed by the DSI module. >> + - clock-names: the name of the clocks. >> + - encoder-slave: phandles to a 'encoder-slave' subnode which DSI >> connect >> +ADV7533 in order to support hdmi display. > > What the ADV7533 binding looks like is still being discussed. > "encoder-slave" is certainly DRM specific and not how it should be done. > Most likely, this needs to use the of-graph ports. > I dont how to implement the encoder bridge stuff in upstream, you think that I will how to handle this part? Thank you xinwei > Also, the ADV7533 connection is specific to HiKey. This binding should > just generically describe how any bridge or panel is connected. > > Rob > > . >
[PATCH RFC 0/8] Add New DRM Driver for Hisilicon's Hi6220 SoC
Hi Xinwei, Thanks for this contribution! We look forward to seeing support for these devices. This isn't an exhaustive review, but two very high-level comments which should result in a lot of changes ... On 15 September 2015 at 10:37, Xinwei Kong wrote: > 1. Hardware Detail > The display subsystem of Hi6220 SoC is shown as bellow: > +-+ +--+ +-+ +-+ > | | | | | | | | > | FB |-->| ADE|>| DSI |>| External| > | | | | | | | HDMI | > +-+ +--+ +-+ +-+ > > - ADE(Advanced Display Engine) is the display controller. It contains 7 > channels or pipes, 3 overlay and a LDI. > - A channel/pipe looks like: DMA-->clip-->scale-->ctrans/csc. > - Overlay is response to compose planes which come from 7 channels and > pass composed image to LDI. This terminology is backwards from what we usually use in DRM, where an overlay is a special case of DRM planes, and pipes are DRM CRTCs. > - LDI is response to generate timings and RGB data stream. > - DSI converts the RGB data stream from ADE to DSI packets. > - External HDMI module is connected with DSI bus. Now Hikey use a ADI's > ADV7533 external HDMI chip. So this is basically just an implementation detail of DSI? > 2. Software Detail > About the software organization and implementation detail: > We have a main drm platform driver (hisi_drm_drv.c), ade platform driver > (hisi_ade.c) and a dsi platform driver (hisi_drm_dsi.c). Ade driver > implements the plane and crtc driver interfaces and dsi implements the > encoder and connector driver interfaces. We take advantage of component > framework to initialize each driver. > In order to support multi coming Hisilicon's SoCs, we plan to separate > common driver code and SoC specific implemented code as possiple as we can. > We abstract an ops for each component(crtc, plane, encoder and connector) > to reuse the common interface implementation logic (FIXME: Not sure if we > can achieve this target and if it is good or not). Thus, we put these > common driver code into hisi_drm_drv/crtc/plane/encoder/connector.c files. Please do not do this; in general, the abstraction layers cause more problems than they create. We have only just finished removing all the abstraction layers from drivers/gpu/drm/exynos/, which started off with exactly the same idea, but only created problems. The issue is that every time the DRM core interface changes, you have to make the exact same changes in your copies of the interface. In general, there seems to be no benefit to having these here: you can just assign the DRM functions directly according to generation. See current Exynos for an example of this. The biggest issue though, is that this driver should become an atomic modesetting driver. Atomic modesetting, rather than sending small individual commands (enable CRTC, change plane position, etc) is based on validating and passing around complete sets of hardware state. Daniel Vetter's blog has an article on how to convert your driver: http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html In addition, there are some drivers converted already that you can look at: tegra (very simple), exynos (reasonably simple), fsl-dcu (moderate), msm (quite complex), i915 (incredibly complex), rcar-du (???). Once your driver is converted to atomic and the abstraction layers removed, then it will be much easier to review the submission in detail. Thanks very much! Cheers, Daniel
[PATCH v3 RESEND 0/5] Remaining part of kill off set_irq_flags usage
On Wed, 16 Sep 2015, Rob Herring wrote: > On 08/29/2015 06:01 PM, Rob Herring wrote: > > Thomas, > > > > As requested, here are the remaining patches for killing off > > set_irq_flags which have not been picked up. The rest of the > > series has been picked up and are in -next. > > Thomas, are you going to pick up these remaining patches? Yes. I'm going to push them out later today.
[Nouveau] [PATCH v2] pci: Handle 5-bit and 8-bit tag field
On Wed, Sep 16, 2015 at 3:52 PM, Pierre Moreau wrote:
> If the hardware supports extended tag field (8-bit ones), then enabled it.
> This
> is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
> In case extended tag field is not supported, 5-bit tag field is used which
> limits the possible values to 32. Apparently bits 7:0 of 0x8841c stores some
> number of outstanding requests, so cap it to 32 if extended tag is
> unsupported.
>
> Fixes: fdo#86537
>
> v2: Restrict changes to chipsets >= 0x84
>
> Signed-off-by: Pierre Moreau
> ---
> drm/nouveau/nvkm/subdev/pci/base.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drm/nouveau/nvkm/subdev/pci/base.c
> b/drm/nouveau/nvkm/subdev/pci/base.c
> index d1c148e..bbad29d 100644
> --- a/drm/nouveau/nvkm/subdev/pci/base.c
> +++ b/drm/nouveau/nvkm/subdev/pci/base.c
> @@ -46,6 +46,14 @@ nvkm_pci_wr32(struct nvkm_pci *pci, u16 addr, u32 data)
> pci->func->wr32(pci, addr, data);
> }
>
> +u32
> +nvkm_pci_mask(struct nvkm_pci *pci, u16 addr, u32 mask, u32 add)
Either add this to the header or make it static. I have a mild
preference for the latter.
> +{
> + u32 data = pci->func->rd32(pci, addr);
> + pci->func->wr32(pci, addr, (data & ~mask) | add);
> + return data;
> +}
> +
> void
> nvkm_pci_rom_shadow(struct nvkm_pci *pci, bool shadow)
> {
> @@ -115,6 +123,23 @@ nvkm_pci_init(struct nvkm_subdev *subdev)
> if (ret)
> return ret;
>
> + if (pci_is_pcie(pdev) && subdev->device->chipset >= 0x84) {
> + /* Tag field is 8-bit long, regardless of EXT_TAG.
> +* However, if EXT_TAG is disabled, only the lower 5 bits of
> the tag
> +* field should be used, limiting the number of request to 32.
> +*
> +* Apparently, 0x041c stores some limit on the number of
> requests
> +* possible, so if EXT_TAG is disabled, limit that requests
> number to
> +* 32
> +*
> +* Fixes fdo#86537
> +*/
> + if (nvkm_pci_rd32(pci, 0x007c) & 0x0020)
> + nvkm_pci_mask(pci, 0x0080, 0x, 0x0100);
Normally this is done as 0x100, 0x100, although your way works.
However a future change might mask out any unwanted bits from the
value as well...
> + else
> + nvkm_pci_mask(pci, 0x041c, 0x0060, 0x);
> + }
> +
> pci->irq = pdev->irq;
> return ret;
> }
> --
> 2.5.2
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
[Intel-gfx] [PATCH 02/11] drm: Move timestamping constants into drm_vblank_crtc
Op 14-09-15 om 21:43 schreef ville.syrjala at linux.intel.com: > From: Ville Syrjälä > > Collect the timestamping constants alongside the rest of the relevant > stuff under drm_vblank_crtc. > > We can now get rid of the 'refcrtc' parameter to > drm_calc_vbltimestamp_from_scanoutpos(). > > Signed-off-by: Ville Syrjälä > That's a much better place. :-) I reviewed the whole series and didn't find anything obvious wrong, but didn't compile or runtime test it. For the whole series: Acked-by: Maarten Lankhorst
[PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
Hi,
On Wed, Sep 16, 2015 at 2:16 PM, Vladimir Zapolskiy
wrote:
> Hi Doug,
>
> On 03.09.2015 02:19, Doug Anderson wrote:
>> Russell,
>>
>> On Wed, Sep 2, 2015 at 4:04 PM, Russell King - ARM Linux
>> wrote:
> Also, is it appropriate to hook non-DDC devices to a DDC bus? I suspect
> that's asking for trouble.
I doubt it's appropriate. Why do you ask?
>>>
>>> To find out why you want to "specify the I2C bus".
>>>
>>> Surely if we're talking about the DDC bus, we either want to use a
>>> separate I2C bus (in which case the HDMI DT description needs to
>>> specify which I2C bus to use) or we want to use the HDMI-internal
>>> I2C bus, which being part of the HDMI driver, the HDMI driver will
>>> know how to find it itself - there should be no need to put an
>>> explicit ddc-i2c-bus self-reference there in that case.
>>
>> Overall it comes down to bus numbering. Possibly that's a stupid
>> reason, but it is my reason nevertheless.
>
> this is a known issue regarding I2C bus numbering.
>
>> Specifically it significantly helps my brain process kernel log
>> messages if the i2c bus that's referred to "bus 5" in my SoC's user
>> manual shows up consistently as "i2c5" in kernel log messages. It's
>> helpful it it shows up as "i2c5" even if "i2c0" - "i2c4" aren't
>> enabled.
>>
>> That's all totally possible by using this type of syntax, like in
>> rk3288.dtsi:
>>
>> aliases {
>> i2c0 = &i2c0;
>> i2c1 = &i2c1;
>> i2c2 = &i2c2;
>> i2c3 = &i2c3;
>> i2c4 = &i2c4;
>> i2c5 = &i2c5;
>>
>> Similarly, I'd like "bus 0" to show up as i2c0, which will happen as
>> you can see in the above.
>>
>> The problem is that if another bus registers itself before the SoC's
>> i2c0 registers itself and that bus doesn't give a number to itself
>> then the i2c subsystem will chose "I2C 0". ...and then when the main
>> SoC i2c bus registers itself it will fail because i2c0 is already
>> taken.
>>
>> By having a of_node for the hdmi i2c bus, we can assign a number to it like:
>> i2c15 = &hdmi;
>>
>> This is all described in the two links I referenced in my original reply.
>>
>>
>> A possible other option is to have the i2c subsystem try to start
>> numbering at a larger base for all automatically numbered busses
>> (those that didn't specify a number). Then it's more likely (though
>> still not guaranteed) to conflict with another bus...
>
> Could you please check if commit 03bde7c31a3 serves you?
I'm 99.9% certain that it's the right fix. Sorry I wasn't aware of it. :(
Personally I still think that it is correct to add "adap->dev.of_node
= hdmi->dev->of_node;", but I won't yell if you don't. ;) While
Russell's concerns are valid, my reading of his email was "there's no
actual bug caused by doing this, but it's a bad idea in general to
copy of_node". From my research into all other i2c busses, it appears
that it is the convention to copy the of_node in the case of creating
an i2c device. ...so since there is no actual bug, following
convention seems like the right move. When someone fixes all the i2c
busses because they have a patch making this work better then we
should fix your i2c bus too.
...anyway, maybe that's too pragmatic of an opinion, but it is my
opinion nonetheless. ;)
-Doug
[PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
Vladimir,
On Wed, Sep 16, 2015 at 1:58 PM, Vladimir Zapolskiy
wrote:
>>> +static void dw_hdmi_i2c_init(struct dw_hdmi *hdmi)
>>> +{
>>> + /* Set Fast Mode speed */
>>> + hdmi_writeb(hdmi, 0x0b, HDMI_I2CM_DIV);
>>
>> If you're going to hardcode to something, it seems like hardcoding to
>> standard mode might be better? It's likely that users will plug into
>> all kinds of broken / crappy HDMI devices out there. I think you'll
>> get better compatibility by using the slower mode, and EDID transfers
>> really aren't too performance critical are they?
>>
>
> Accepted. I don't know what are the exact divisors of master clock for
> fast and standard modes, for reference I'll make a simple performance
> test and publish its results. I expect that in standard mode SCL is
> about 100KHz and in fast mode SCL is about 400KHz, and, if in standard
> mode SCL is less than 100KHz, it will take more than 50ms to read out
> 512 bytes of data, which might be not acceptable from performance
> perspective.
Yes, I'd expect 100kHz and 400kHz.
I agree that 50ms is non-trivial, but it's also not something you're
doing lots of. I'd expect that the EDID is read over this channel at
cable plugin time and then not used much after that. Adding an extra
40ms (10ms vs 50ms) before we can access the TV doesn't seem terrible
for compatibility.
Doing a quick scan for what others in mainline do:
A few can be found with:
$ git grep -A3 hdmiddc | grep clock-freq
arch/arm/boot/dts/stihxxx-b2120.dtsi-
clock-frequency = <10>;
arch/arm/boot/dts/tegra30-apalis.dtsi- clock-frequency = <10>;
arch/arm/boot/dts/tegra30-beaver.dts- clock-frequency = <10>;
arch/arm/boot/dts/tegra30-colibri.dtsi- clock-frequency = <10>;
A few more done by hand (picked arbitrarily; note that unspecified
clock freq means 10 on rk3288):
arch/arm/boot/dts/omap3-beagle.dts: ddc-i2c-bus = <&i2c3>;
arch/arm/boot/dts/omap3-beagle.dts:&i2c3 {
arch/arm/boot/dts/omap3-beagle.dts- clock-frequency = <10>;
arch/arm/boot/dts/omap3-beagle.dts-};
arch/arm/boot/dts/omap3-beagle-xm.dts: ddc-i2c-bus = <&i2c3>;
arch/arm/boot/dts/omap3-beagle-xm.dts:&i2c3 {
arch/arm/boot/dts/omap3-beagle-xm.dts- clock-frequency = <10>;
arch/arm/boot/dts/omap3-beagle-xm.dts-};
arch/arm/boot/dts/rk3288-evb.dtsi: ddc-i2c-bus = <&i2c5>;
arch/arm/boot/dts/rk3288-evb.dtsi:&i2c5 {
arch/arm/boot/dts/rk3288-evb.dtsi- status = "okay";
arch/arm/boot/dts/rk3288-evb.dtsi-};
arch/arm/boot/dts/rk3288-firefly.dtsi: ddc-i2c-bus = <&i2c5>;
arch/arm/boot/dts/rk3288-firefly.dtsi:&i2c5 {
arch/arm/boot/dts/rk3288-firefly.dtsi- status = "okay";
arch/arm/boot/dts/rk3288-firefly.dtsi-};
arch/arm/boot/dts/rk3288-popmetal.dts: ddc-i2c-bus = <&i2c5>;
arch/arm/boot/dts/rk3288-popmetal.dts:&i2c5 {
arch/arm/boot/dts/rk3288-popmetal.dts- status = "okay";
arch/arm/boot/dts/rk3288-popmetal.dts-};
arch/arm/boot/dts/imx6q-gk802.dts: ddc-i2c-bus = <&i2c3>;
arch/arm/boot/dts/imx6q-gk802.dts:&i2c3 {
arch/arm/boot/dts/imx6q-gk802.dts- pinctrl-names = "default";
arch/arm/boot/dts/imx6q-gk802.dts: pinctrl-0 = <&pinctrl_i2c3>;
arch/arm/boot/dts/imx6q-gk802.dts- clock-frequency = <10>;
arch/arm/boot/dts/imx6q-gw5400-a.dts: ddc-i2c-bus = <&i2c3>;
arch/arm/boot/dts/imx6q-gw5400-a.dts:&i2c3 {
arch/arm/boot/dts/imx6q-gw5400-a.dts- clock-frequency = <10>;
arch/arm/boot/dts/imx6qdl-apf6dev.dtsi: ddc-i2c-bus = <&i2c3>;
arch/arm/boot/dts/imx6qdl-apf6dev.dtsi:&i2c3 {
arch/arm/boot/dts/imx6qdl-apf6dev.dtsi- clock-frequency = <40>;
...ah ha! Found one at 400kHz. ...but it sure looks like most people
have decided that 100kHz is wiser...
>>> +static int dw_hdmi_i2c_xfer(struct i2c_adapter *adap,
>>> + struct i2c_msg *msgs, int num)
>>> +{
>>> + struct dw_hdmi *hdmi = i2c_get_adapdata(adap);
>>> + struct dw_hdmi_i2c *i2c = hdmi->i2c;
>>> + u8 addr = msgs[0].addr;
>>> + int i, ret = 0;
>>> +
>>> + dev_dbg(hdmi->dev, "xfer: num: %d, addr: %#x\n", num, addr);
>>> +
>>> + for (i = 0; i < num; i++) {
>>> + if (msgs[i].addr != addr) {
>>> + dev_warn(hdmi->dev,
>>> +"unsupported transfer, changed slave
>>> address\n");
>>> + return -EOPNOTSUPP;
>>> + }
>>> +
>>> + if (msgs[i].len == 0) {
>>> + dev_dbg(hdmi->dev,
>>> + "unsupported transfer %d/%d, no data\n",
>>> + i + 1, num);
>>> + return -EOPNOTSUPP;
>>> + }
>>> + }
>>> +
>>> + mutex_lock(&i2c->lock);
>>> +
>>
>> If I may make a suggestion, it's worth considering putting
>> dw_hdmi_i2c_init() here and removing it from the dw_hdmi_bind()
>> function. There isn't any state kept between i2c transfers (each one
>> is independent), so re-initting each time
[PATCH RFCv2 3/4] staging: etnaviv: add drm driver
Russell King - ARM Linux writes:
> On Wed, Sep 16, 2015 at 11:05:11AM -0400, Eric Anholt wrote:
>> Lucas Stach writes:
>>
>> > From: Christian Gmeiner
>>
>> > +static bool etnaviv_validate_load_state(struct etnaviv_gpu *gpu, u32 *buf,
>> > + unsigned int state, unsigned int num)
>> > +{
>> > + return true;
> ...
>> > +}
>>
>> I was browsing the code, and noticed that it looks like you've got a
>> debugging early return in your validation function here.
>
> That's because it's not quite ready to be enabled yet - the code as
> it stands in my tree doesn't have the infrastructure to validate that
> a LOADSTATE which touches an address register (or similar) has a
> relocation appropriately marked, due to the way things happen.
> Hopefully, when the user/kernel API is sorted, this can be resolved.
OK. Validation code is painful to write, so I was just browsing what
was in here to see if I could pick up anything useful.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150916/ee6b5b12/attachment.sig>
[PATCH] drm/exynos: get event time from ktime
On 09/16/2015 02:31 PM, Joonyoung Shim wrote:
> G2D and IPP drivers get event time from do_gettimeofday(), but drm
> vblank event gets it from ktime. Use ktime for consistency.
Oops, this causes build errors, please ignore, i will retry.
Thanks.
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 4 +++-
> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 +++-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 3734c34..fa8817c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -880,6 +880,7 @@ static void g2d_finish_event(struct g2d_data *g2d, u32
> cmdlist_no)
> struct g2d_runqueue_node *runqueue_node = g2d->runqueue_node;
> struct drm_exynos_pending_g2d_event *e;
> struct timeval now;
> + ktime_t now_ktime;
> unsigned long flags;
>
> if (list_empty(&runqueue_node->event_list))
> @@ -888,7 +889,8 @@ static void g2d_finish_event(struct g2d_data *g2d, u32
> cmdlist_no)
> e = list_first_entry(&runqueue_node->event_list,
>struct drm_exynos_pending_g2d_event, base.link);
>
> - do_gettimeofday(&now);
> + now_ktime = drm_timestamp_monotonic ? ktime_get() : ktime_get_real();
> + now = ktime_to_timeval(now_ktime);
> e->event.tv_sec = now.tv_sec;
> e->event.tv_usec = now.tv_usec;
> e->event.cmdlist_no = cmdlist_no;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 67d2423..74076d0 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -1412,6 +1412,7 @@ static int ipp_send_event(struct exynos_drm_ippdrv
> *ippdrv,
> struct drm_exynos_ipp_send_event *e;
> struct list_head *head;
> struct timeval now;
> + ktime_t now_ktime;
> unsigned long flags;
> u32 tbuf_id[EXYNOS_DRM_OPS_MAX] = {0, };
> int ret, i;
> @@ -1515,7 +1516,8 @@ static int ipp_send_event(struct exynos_drm_ippdrv
> *ippdrv,
> e = list_first_entry(&c_node->event_list,
> struct drm_exynos_ipp_send_event, base.link);
>
> - do_gettimeofday(&now);
> + now_ktime = drm_timestamp_monotonic ? ktime_get() : ktime_get_real();
> + now = ktime_to_timeval(now_ktime);
> DRM_DEBUG_KMS("tv_sec[%ld]tv_usec[%ld]\n", now.tv_sec, now.tv_usec);
> e->event.tv_sec = now.tv_sec;
> e->event.tv_usec = now.tv_usec;
>
[PATCH RFC 1/8] dt-bindings: Document the hi6220 bindings for DRM driver
Hi, On 09/16/2015 02:04 PM, Xinwei Kong wrote: > hi architt > > On 2015/9/16 2:11, Rob Herring wrote: >> On 09/15/2015 04:37 AM, Xinwei Kong wrote: >>> This adds documentation of device tree bindings for the >>> Graphics Processing Unit of hi6220 SOC. >>> >>> Signed-off-by: Xinliang Liu >>> Signed-off-by: Xinwei Kong >>> Signed-off-by: Andy Green >>> Signed-off-by: Jiwen Qi >>> Signed-off-by: Yu Gong >>> --- >>> .../devicetree/bindings/gpu/hisilicon,hi6220.txt | 69 >>> ++ >>> 1 file changed, 69 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/gpu/hisilicon,hi6220.txt >>> >>> diff --git a/Documentation/devicetree/bindings/gpu/hisilicon,hi6220.txt >>> b/Documentation/devicetree/bindings/gpu/hisilicon,hi6220.txt >>> new file mode 100644 >>> index 000..173ac63 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/gpu/hisilicon,hi6220.txt >>> @@ -0,0 +1,69 @@ >>> + * Hisilicon hi6220 Graphics Processing Unit for HiKey board >>> + >>> + ** display-subsystem: Master device for binding DRM sub-components >> >> DRM is a Linuxism that doesn't belong in the binding. >> >>> +This master device is parent node and it will be responsible to bind >>> all >>> +sub-components devices node. >> >> Are these nodes a single block in the h/w? If not, you should describe >> the connection of sub-nodes with of-graph instead. >> >>> +- Required properties : >>> + - compatible: "hisilicon,display-subsystem". >>> + - #address-cells, #size-cells: Must be present if the device has >>> sub-nodes. >>> + - ranges: to allow probing of subdevices. >>> + - dma-coherent: Present if dma operations are coherent. >>> + >>> + ** ade: Graphic overlay, Graphic post-processing, display timing control. >>> +This device is child node of display-subsystem >>> +- Required properties : >>> + - compatible: "hisilicon,hi6220-ade". >>> + - reg: physical base address of the ADE register and length of memory >>> + region. >>> + - reg-names: Should contain the reg names "ade_base" and >>> "media_base". >>> + - interrupt: The interrupt number to the cpu. Defines the interrupt >>> +by ADE. >>> + - clocks: The clocks needed by the ADE module. >>> + - clock-names: the name of the clocks. >>> + >>> + ** dsi: support mipi dsi interface >>> +This device is child node of display-subsystem >>> +- Required properties : >>> + - compatible: "hisilicon,hi6220-dsi". >>> + - reg: physical base address of the DSI register and length of memory >>> + region. >>> + - clocks: The clocks needed by the DSI module. >>> + - clock-names: the name of the clocks. >>> + -encoder-slave: phandles to a 'encoder-slave' subnode which DSI >>> connect >>> +ADV7533 in order to support hdmi display. >> >> What the ADV7533 binding looks like is still being discussed. >> "encoder-slave" is certainly DRM specific and not how it should be done. >> Most likely, this needs to use the of-graph ports. >> > I dont how to implement the encoder bridge stuff in upstream, > you think that I will how to handle this part? You can use of-graph ports to link the dsi output with the adv7533 bridge. An example of the binding looks like: Documentation/devicetree/bindings/drm/msm/dsi.txt The implementation of this on the dsi host side of drm/msm can be found in dsi_host_parse_dt, in: drivers/gpu/drm/msm/dsi/dsi_host.c You can get to know more about of-graph parsing here: Documentation/devicetree/bindings/graph.txt I'd started going through the drm/hisil patches. I'll share more comments there. Thanks, Archit > > Thank you > xinwei > >> Also, the ADV7533 connection is specific to HiKey. This binding should >> just generically describe how any bridge or panel is connected. >> >> Rob >> >> . >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH] drm/exynos: get event time from ktime
G2D and IPP drivers get event time from do_gettimeofday(), but drm
vblank event gets it from ktime. Use ktime for consistency.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 4 +++-
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 3734c34..fa8817c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -880,6 +880,7 @@ static void g2d_finish_event(struct g2d_data *g2d, u32
cmdlist_no)
struct g2d_runqueue_node *runqueue_node = g2d->runqueue_node;
struct drm_exynos_pending_g2d_event *e;
struct timeval now;
+ ktime_t now_ktime;
unsigned long flags;
if (list_empty(&runqueue_node->event_list))
@@ -888,7 +889,8 @@ static void g2d_finish_event(struct g2d_data *g2d, u32
cmdlist_no)
e = list_first_entry(&runqueue_node->event_list,
struct drm_exynos_pending_g2d_event, base.link);
- do_gettimeofday(&now);
+ now_ktime = drm_timestamp_monotonic ? ktime_get() : ktime_get_real();
+ now = ktime_to_timeval(now_ktime);
e->event.tv_sec = now.tv_sec;
e->event.tv_usec = now.tv_usec;
e->event.cmdlist_no = cmdlist_no;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 67d2423..74076d0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1412,6 +1412,7 @@ static int ipp_send_event(struct exynos_drm_ippdrv
*ippdrv,
struct drm_exynos_ipp_send_event *e;
struct list_head *head;
struct timeval now;
+ ktime_t now_ktime;
unsigned long flags;
u32 tbuf_id[EXYNOS_DRM_OPS_MAX] = {0, };
int ret, i;
@@ -1515,7 +1516,8 @@ static int ipp_send_event(struct exynos_drm_ippdrv
*ippdrv,
e = list_first_entry(&c_node->event_list,
struct drm_exynos_ipp_send_event, base.link);
- do_gettimeofday(&now);
+ now_ktime = drm_timestamp_monotonic ? ktime_get() : ktime_get_real();
+ now = ktime_to_timeval(now_ktime);
DRM_DEBUG_KMS("tv_sec[%ld]tv_usec[%ld]\n", now.tv_sec, now.tv_usec);
e->event.tv_sec = now.tv_sec;
e->event.tv_usec = now.tv_usec;
--
1.9.1
[PATCH 4/4] drm/exynos: cleanup line feed in exynos_drm_gem_get_ioctl
The beginning of statement in function is next line of a brace.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 5bc0fc3..31c5b64 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -331,7 +331,8 @@ int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj
*exynos_gem_obj,
int exynos_drm_gem_get_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
-{ struct exynos_drm_gem_obj *exynos_gem_obj;
+{
+ struct exynos_drm_gem_obj *exynos_gem_obj;
struct drm_exynos_gem_info *args = data;
struct drm_gem_object *obj;
--
1.9.1
[PATCH 3/4] drm/exynos: cleanup function calling written twice
By if statment, some function callings are written twice. It needs
several line feed by indentation in if statment. Make to one function
calling from outside if statment.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 56 ++---
1 file changed, 23 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index fcb6a2c..5bc0fc3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -56,24 +56,25 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem_obj
*obj)
nr_pages = obj->size >> PAGE_SHIFT;
if (!is_drm_iommu_supported(dev)) {
- dma_addr_t start_addr;
- unsigned int i = 0;
-
obj->pages = drm_calloc_large(nr_pages, sizeof(struct page *));
if (!obj->pages) {
DRM_ERROR("failed to allocate pages.\n");
return -ENOMEM;
}
+ }
- obj->cookie = dma_alloc_attrs(dev->dev,
- obj->size,
- &obj->dma_addr, GFP_KERNEL,
- &obj->dma_attrs);
- if (!obj->cookie) {
- DRM_ERROR("failed to allocate buffer.\n");
+ obj->cookie = dma_alloc_attrs(dev->dev, obj->size, &obj->dma_addr,
+ GFP_KERNEL, &obj->dma_attrs);
+ if (!obj->cookie) {
+ DRM_ERROR("failed to allocate buffer.\n");
+ if (obj->pages)
drm_free_large(obj->pages);
- return -ENOMEM;
- }
+ return -ENOMEM;
+ }
+
+ if (obj->pages) {
+ dma_addr_t start_addr;
+ unsigned int i = 0;
start_addr = obj->dma_addr;
while (i < nr_pages) {
@@ -82,13 +83,7 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem_obj
*obj)
i++;
}
} else {
- obj->pages = dma_alloc_attrs(dev->dev, obj->size,
- &obj->dma_addr, GFP_KERNEL,
- &obj->dma_attrs);
- if (!obj->pages) {
- DRM_ERROR("failed to allocate buffer.\n");
- return -ENOMEM;
- }
+ obj->pages = obj->cookie;
}
DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
@@ -110,13 +105,11 @@ static void exynos_drm_free_buf(struct exynos_drm_gem_obj
*obj)
DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)obj->dma_addr, obj->size);
- if (!is_drm_iommu_supported(dev)) {
- dma_free_attrs(dev->dev, obj->size, obj->cookie,
- (dma_addr_t)obj->dma_addr, &obj->dma_attrs);
+ dma_free_attrs(dev->dev, obj->size, obj->cookie,
+ (dma_addr_t)obj->dma_addr, &obj->dma_attrs);
+
+ if (!is_drm_iommu_supported(dev))
drm_free_large(obj->pages);
- } else
- dma_free_attrs(dev->dev, obj->size, obj->pages,
- (dma_addr_t)obj->dma_addr, &obj->dma_attrs);
}
static int exynos_drm_gem_handle_create(struct drm_gem_object *obj,
@@ -398,6 +391,7 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
struct drm_mode_create_dumb *args)
{
struct exynos_drm_gem_obj *exynos_gem_obj;
+ unsigned int flags;
int ret;
/*
@@ -409,16 +403,12 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
args->pitch = args->width * ((args->bpp + 7) / 8);
args->size = args->pitch * args->height;
- if (is_drm_iommu_supported(dev)) {
- exynos_gem_obj = exynos_drm_gem_create(dev,
- EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC,
- args->size);
- } else {
- exynos_gem_obj = exynos_drm_gem_create(dev,
- EXYNOS_BO_CONTIG | EXYNOS_BO_WC,
- args->size);
- }
+ if (is_drm_iommu_supported(dev))
+ flags = EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC;
+ else
+ flags = EXYNOS_BO_CONTIG | EXYNOS_BO_WC;
+ exynos_gem_obj = exynos_drm_gem_create(dev, flags, args->size);
if (IS_ERR(exynos_gem_obj)) {
dev_warn(dev->dev, "FB allocation failed.\n");
return PTR_ERR(exynos_gem_obj);
--
1.9.1
[PATCH 2/4] drm/exynos: staticize exynos_drm_gem_init()
The exynos_drm_gem_init() is used only in exynos_drm_gem.c file. Make it
static and don't export it.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 +--
drivers/gpu/drm/exynos/exynos_drm_gem.h | 4
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 8dce40d..fcb6a2c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -187,8 +187,7 @@ unsigned long exynos_drm_gem_get_size(struct drm_device
*dev,
return exynos_gem_obj->size;
}
-
-struct exynos_drm_gem_obj *exynos_drm_gem_init(struct drm_device *dev,
+static struct exynos_drm_gem_obj *exynos_drm_gem_init(struct drm_device *dev,
unsigned long size)
{
struct exynos_drm_gem_obj *exynos_gem_obj;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index cd62f84..610ccad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -59,10 +59,6 @@ struct page **exynos_gem_get_pages(struct drm_gem_object
*obj, gfp_t gfpmask);
/* destroy a buffer with gem object */
void exynos_drm_gem_destroy(struct exynos_drm_gem_obj *exynos_gem_obj);
-/* create a private gem object and initialize it. */
-struct exynos_drm_gem_obj *exynos_drm_gem_init(struct drm_device *dev,
- unsigned long size);
-
/* create a new buffer with gem object */
struct exynos_drm_gem_obj *exynos_drm_gem_create(struct drm_device *dev,
unsigned int flags,
--
1.9.1
[PATCH 1/4] drm/exynos: remove unnecessary NULL assignment
They will be freed right or was freed already, so NULL assignment is unnecessary. Signed-off-by: Joonyoung Shim --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c index f12fbc3..8dce40d 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c @@ -117,8 +117,6 @@ static void exynos_drm_free_buf(struct exynos_drm_gem_obj *obj) } else dma_free_attrs(dev->dev, obj->size, obj->pages, (dma_addr_t)obj->dma_addr, &obj->dma_attrs); - - obj->dma_addr = (dma_addr_t)NULL; } static int exynos_drm_gem_handle_create(struct drm_gem_object *obj, @@ -167,7 +165,6 @@ out: drm_gem_object_release(obj); kfree(exynos_gem_obj); - exynos_gem_obj = NULL; } unsigned long exynos_drm_gem_get_size(struct drm_device *dev, -- 1.9.1
[PATCH 0/4] drm/exynos: small cleanup for exynos_drm_gem
Hi, This patchset is small cleanup about exynos_drm_gem codes of exynos-drm driver. This removes unnecessary and redundant codes, and staticize a local function. Thanks. Joonyoung Shim (4): drm/exynos: remove unnecessary NULL assignment drm/exynos: staticize exynos_drm_gem_init() drm/exynos: cleanup function calling written twice drm/exynos: cleanup line feed in exynos_drm_gem_get_ioctl drivers/gpu/drm/exynos/exynos_drm_gem.c | 65 + drivers/gpu/drm/exynos/exynos_drm_gem.h | 4 -- 2 files changed, 26 insertions(+), 43 deletions(-)
[PATCH] drm/exynos: fix layering violation of address
There is no guarantee that DMA addresses are the same as physical
addresses, but dma_to_pfn() knows how to convert a dma_addr_t to a PFN
which can then be converted to a struct page.
Suggested-by: Russell King
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index f12fbc3..a4fb78e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -77,7 +77,8 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem_obj
*obj)
start_addr = obj->dma_addr;
while (i < nr_pages) {
- obj->pages[i] = phys_to_page(start_addr);
+ obj->pages[i] = pfn_to_page(dma_to_pfn(dev->dev,
+ start_addr));
start_addr += PAGE_SIZE;
i++;
}
--
1.9.1
[PATCH] drm/exynos: fix missed calling of drm_prime_gem_destroy()
When obj->import_attach is existed, code calling drm_prime_gem_destroy()
was removed from commit 67e93c808b48 ("drm/exynos: stop copying sg
table"), and it's a fault.
The drm_prime_gem_destroy() is cleanup function which GEM drivers need
to call when they use drm_gem_prime_import() to import dma-bufs, so
exynos-drm driver using drm_gem_prime_import() needs calling
drm_prime_gem_destroy().
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 ++
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index a4fb78e..ce05f13 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -157,11 +157,10 @@ void exynos_drm_gem_destroy(struct exynos_drm_gem_obj
*exynos_gem_obj)
* once dmabuf's refcount becomes 0.
*/
if (obj->import_attach)
- goto out;
-
- exynos_drm_free_buf(exynos_gem_obj);
+ drm_prime_gem_destroy(obj, exynos_gem_obj->sgt);
+ else
+ exynos_drm_free_buf(exynos_gem_obj);
-out:
drm_gem_free_mmap_offset(obj);
/* release file pointer to gem object. */
@@ -589,6 +588,8 @@ exynos_drm_gem_prime_import_sg_table(struct drm_device *dev,
if (ret < 0)
goto err_free_large;
+ exynos_gem_obj->sgt = sgt;
+
if (sgt->nents == 1) {
/* always physically continuous memory if sgt->nents is 1. */
exynos_gem_obj->flags |= EXYNOS_BO_CONTIG;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index cd62f84..97bb48b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -39,6 +39,7 @@
* - this address could be physical address without IOMMU and
* device address with IOMMU.
* @pages: Array of backing pages.
+ * @sgt: Imported sg_table.
*
* P.S. this object would be transferred to user as kms_bo.handle so
* user can access the buffer through kms_bo.handle.
@@ -52,6 +53,7 @@ struct exynos_drm_gem_obj {
dma_addr_t dma_addr;
struct dma_attrsdma_attrs;
struct page **pages;
+ struct sg_table *sgt;
};
struct page **exynos_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask);
--
1.9.1
[PATCH 4/4] drm/msm: Use exynos's model for handling component driver matching.
This eliminates the need for the "connectors" and "gpus" nodes in the
devicetree, which we were doing nothing connector- or gpu-specific
with.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/msm_drv.c | 65 +--
include/drm/drmP.h| 2 +-
2 files changed, 27 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index a9b0573..4e1263b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1039,34 +1039,7 @@ static const struct dev_pm_ops msm_pm_ops = {
* Componentized driver support:
*/
-#ifdef CONFIG_OF
-/* NOTE: the CONFIG_OF case duplicates the same code as exynos or imx
- * (or probably any other).. so probably some room for some helpers
- */
-static int compare_of(struct device *dev, void *data)
-{
- return dev->of_node == data;
-}
-
-static int add_components(struct device *dev, struct component_match
**matchptr,
- const char *name)
-{
- struct device_node *np = dev->of_node;
- unsigned i;
-
- for (i = 0; ; i++) {
- struct device_node *node;
-
- node = of_parse_phandle(np, name, i);
- if (!node)
- break;
-
- component_match_add(dev, matchptr, compare_of, node);
- }
-
- return 0;
-}
-#else
+#ifndef CONFIG_OF
static int compare_dev(struct device *dev, void *data)
{
return dev == data;
@@ -1088,6 +1061,20 @@ static const struct component_master_ops msm_drm_ops = {
.unbind = msm_drm_unbind,
};
+static struct platform_driver *const noncomponent_drivers[] = {
+#if IS_ENABLED(CONFIG_DRM_MSM_DSI)
+ &msm_dsi_phy_driver,
+#endif
+};
+
+static struct platform_driver *const component_drivers[] = {
+#if IS_ENABLED(CONFIG_DRM_MSM_DSI)
+ &msm_dsi_driver,
+#endif
+ &msm_hdmi_driver,
+ &adreno_driver,
+};
+
/*
* Platform driver:
*/
@@ -1096,8 +1083,9 @@ static int msm_pdev_probe(struct platform_device *pdev)
{
struct component_match *match = NULL;
#ifdef CONFIG_OF
- add_components(&pdev->dev, &match, "connectors");
- add_components(&pdev->dev, &match, "gpus");
+ drm_platform_component_match_add_drivers(&pdev->dev, &match,
+component_drivers,
+ARRAY_SIZE(component_drivers));
#else
/* For non-DT case, it kinda sucks. We don't actually have a way
* to know whether or not we are waiting for certain devices (or if
@@ -1159,20 +1147,17 @@ static struct platform_driver msm_platform_driver = {
.id_table = msm_id,
};
-static struct platform_driver *const component_drivers[] = {
-#if IS_ENABLED(CONFIG_DRM_MSM_DSI)
- &msm_dsi_phy_driver,
- &msm_dsi_driver,
-#endif
- &msm_hdmi_driver,
- &adreno_driver,
-};
-
static int __init msm_drm_register(void)
{
int ret;
DBG("init");
+
+ ret = drm_platform_register_drivers(noncomponent_drivers,
+ ARRAY_SIZE(noncomponent_drivers));
+ if (ret)
+ return ret;
+
ret = drm_platform_register_drivers(component_drivers,
ARRAY_SIZE(component_drivers));
if (ret)
@@ -1187,6 +1172,8 @@ static void __exit msm_drm_unregister(void)
platform_driver_unregister(&msm_platform_driver);
drm_platform_unregister_drivers(component_drivers,
ARRAY_SIZE(component_drivers));
+ drm_platform_unregister_drivers(noncomponent_drivers,
+ ARRAY_SIZE(noncomponent_drivers));
}
module_init(msm_drm_register);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index b65d886..0da8599 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1094,7 +1094,7 @@ void drm_platform_unregister_drivers(struct
platform_driver *const *drv,
int count);
void drm_platform_component_match_add_drivers(struct device *dev,
struct component_match **match,
- struct platform_driver **drivers,
+ struct platform_driver *const
*drivers,
int count);
/* returns true if currently okay to sleep */
--
2.1.4
[PATCH 3/4] drm: Move exynos "match_add all devices matching my drivers" to core.
This is a really nice way to handle the component setup. The
subsystem driver knows that it's got a bunch of component drivers, and
for any devices that matched its component drivers, it wants all of
those to bind to it as master.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_platform_helpers.c | 33 +
drivers/gpu/drm/exynos/exynos_drm_drv.c | 37 +++--
include/drm/drmP.h | 5 +
3 files changed, 45 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/drm_platform_helpers.c
b/drivers/gpu/drm/drm_platform_helpers.c
index a54c3e3..0819c49 100644
--- a/drivers/gpu/drm/drm_platform_helpers.c
+++ b/drivers/gpu/drm/drm_platform_helpers.c
@@ -7,6 +7,7 @@
* option) any later version.
*/
+#include
#include
/**
@@ -43,3 +44,35 @@ void drm_platform_unregister_drivers(struct platform_driver
*const *drv,
platform_driver_unregister(drv[count]);
}
EXPORT_SYMBOL_GPL(drm_platform_unregister_drivers);
+
+static int compare_dev(struct device *dev, void *data)
+{
+ return dev == (struct device *)data;
+}
+
+/**
+ * drm_platform_component_match_add_drivers - For each driver passed
+ * in, finds each device that matched to it and adds it as a component
+ * driver to the match list.
+ */
+void drm_platform_component_match_add_drivers(struct device *dev,
+ struct component_match **match,
+ struct platform_driver *const
*drivers,
+ int count)
+{
+ int i;
+
+ for (i = 0; i < count; i++) {
+ struct device_driver *drv = &drivers[i]->driver;
+ struct device *p = NULL, *d;
+
+ while ((d = bus_find_device(&platform_bus_type, p, drv,
+ (void *)platform_bus_type.match))) {
+ put_device(p);
+ component_match_add(dev, match, compare_dev, d);
+ p = d;
+ }
+ put_device(p);
+ }
+}
+EXPORT_SYMBOL_GPL(drm_platform_component_match_add_drivers);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 83f829b..9151304 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -412,32 +412,6 @@ static struct platform_driver *const
exynos_drm_drv_with_simple_dev[] = {
};
#define PDEV_COUNT ARRAY_SIZE(exynos_drm_drv_with_simple_dev)
-static int compare_dev(struct device *dev, void *data)
-{
- return dev == (struct device *)data;
-}
-
-static struct component_match *exynos_drm_match_add(struct device *dev)
-{
- struct component_match *match = NULL;
- int i;
-
- for (i = 0; i < ARRAY_SIZE(exynos_drm_kms_drivers); ++i) {
- struct device_driver *drv = &exynos_drm_kms_drivers[i]->driver;
- struct device *p = NULL, *d;
-
- while ((d = bus_find_device(&platform_bus_type, p, drv,
- (void *)platform_bus_type.match))) {
- put_device(p);
- component_match_add(dev, &match, compare_dev, d);
- p = d;
- }
- put_device(p);
- }
-
- return match ?: ERR_PTR(-ENODEV);
-}
-
static int exynos_drm_bind(struct device *dev)
{
return drm_platform_init(&exynos_drm_driver, to_platform_device(dev));
@@ -455,14 +429,17 @@ static const struct component_master_ops exynos_drm_ops =
{
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
- struct component_match *match;
+ struct component_match *match = NULL;
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
- match = exynos_drm_match_add(&pdev->dev);
- if (IS_ERR(match))
- return PTR_ERR(match);
+ drm_platform_component_match_add_drivers(&pdev->dev, &match,
+exynos_drm_kms_drivers,
+
ARRAY_SIZE(exynos_drm_kms_drivers));
+
+ if (!match)
+ return -ENODEV;
return component_master_add_with_match(&pdev->dev, &exynos_drm_ops,
match);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index a774574..b65d886 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -88,6 +88,7 @@ struct device_node;
struct videomode;
struct reservation_object;
struct dma_buf_attachment;
+struct component_match;
/*
* 4 debug categories are defined:
@@ -1091,6 +1092,10 @@ int drm_platform_register_drivers(struct platform_driver
*const *drv,
int count);
void drm_platform_unregister_drivers(struct platform_driver *const *drv,
[PATCH 2/4] drm/msm: Use drm_platform_register/unregister_drivers().
This matches how exynos handles the registration of its component
drivers.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 12 +---
drivers/gpu/drm/msm/dsi/dsi.c | 16 +---
drivers/gpu/drm/msm/dsi/dsi.h | 2 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 12 +---
drivers/gpu/drm/msm/edp/edp.c | 14 +-
drivers/gpu/drm/msm/hdmi/hdmi.c| 12 +---
drivers/gpu/drm/msm/msm_drv.c | 26 ++
drivers/gpu/drm/msm/msm_drv.h | 16
drivers/gpu/drm/msm/msm_gpu.h | 3 +--
9 files changed, 28 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 1ea2df5..8b0eb95 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -286,7 +286,7 @@ static const struct of_device_id dt_match[] = {
{}
};
-static struct platform_driver adreno_driver = {
+struct platform_driver adreno_driver = {
.probe = adreno_probe,
.remove = adreno_remove,
.driver = {
@@ -294,13 +294,3 @@ static struct platform_driver adreno_driver = {
.of_match_table = dt_match,
},
};
-
-void __init adreno_register(void)
-{
- platform_driver_register(&adreno_driver);
-}
-
-void __exit adreno_unregister(void)
-{
- platform_driver_unregister(&adreno_driver);
-}
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 6edcd6f..41cfbd5 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -163,7 +163,7 @@ static const struct of_device_id dt_match[] = {
{}
};
-static struct platform_driver dsi_driver = {
+struct platform_driver msm_dsi_driver = {
.probe = dsi_dev_probe,
.remove = dsi_dev_remove,
.driver = {
@@ -172,20 +172,6 @@ static struct platform_driver dsi_driver = {
},
};
-void __init msm_dsi_register(void)
-{
- DBG("");
- msm_dsi_phy_driver_register();
- platform_driver_register(&dsi_driver);
-}
-
-void __exit msm_dsi_unregister(void)
-{
- DBG("");
- msm_dsi_phy_driver_unregister();
- platform_driver_unregister(&dsi_driver);
-}
-
int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct drm_device *dev,
struct drm_encoder *encoders[MSM_DSI_ENCODER_NUM])
{
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 5f5a373..08fff5c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -164,8 +164,6 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi);
/* dsi phy */
struct msm_dsi_phy;
-void msm_dsi_phy_driver_register(void);
-void msm_dsi_phy_driver_unregister(void);
int msm_dsi_phy_enable(struct msm_dsi_phy *phy, int src_pll_id,
const unsigned long bit_rate, const unsigned long esc_rate);
void msm_dsi_phy_disable(struct msm_dsi_phy *phy);
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 401ff58..f918b56 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -375,7 +375,7 @@ static int dsi_phy_driver_remove(struct platform_device
*pdev)
return 0;
}
-static struct platform_driver dsi_phy_platform_driver = {
+struct platform_driver msm_dsi_phy_driver = {
.probe = dsi_phy_driver_probe,
.remove = dsi_phy_driver_remove,
.driver = {
@@ -384,16 +384,6 @@ static struct platform_driver dsi_phy_platform_driver = {
},
};
-void __init msm_dsi_phy_driver_register(void)
-{
- platform_driver_register(&dsi_phy_platform_driver);
-}
-
-void __exit msm_dsi_phy_driver_unregister(void)
-{
- platform_driver_unregister(&dsi_phy_platform_driver);
-}
-
int msm_dsi_phy_enable(struct msm_dsi_phy *phy, int src_pll_id,
const unsigned long bit_rate, const unsigned long esc_rate)
{
diff --git a/drivers/gpu/drm/msm/edp/edp.c b/drivers/gpu/drm/msm/edp/edp.c
index 0940e84..0bf75b0 100644
--- a/drivers/gpu/drm/msm/edp/edp.c
+++ b/drivers/gpu/drm/msm/edp/edp.c
@@ -122,7 +122,7 @@ static const struct of_device_id dt_match[] = {
{}
};
-static struct platform_driver edp_driver = {
+struct platform_driver msm_edp_driver = {
.probe = edp_dev_probe,
.remove = edp_dev_remove,
.driver = {
@@ -131,18 +131,6 @@ static struct platform_driver edp_driver = {
},
};
-void __init msm_edp_register(void)
-{
- DBG("");
- platform_driver_register(&edp_driver);
-}
-
-void __exit msm_edp_unregister(void)
-{
- DBG("");
- platform_driver_unregister(&edp_driver);
-}
-
/* Second part of initialization, the drm/kms level modeset_init */
int msm_edp_modeset_init(struct msm_edp *edp, struct drm_device *dev,
struct drm_encoder *encoder)
diff --git a/d
[PATCH 1/4] drm: Put platform driver registration/unregistration loops in core.
This is mostly just a move of the code from exynos, with a slight
reformat. I wanted to do a similar thing for vc4, and msm looks like
a good candidate as well.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/Makefile| 3 ++-
drivers/gpu/drm/drm_platform_helpers.c | 45 +
drivers/gpu/drm/exynos/exynos_drm_drv.c | 38 +---
include/drm/drmP.h | 4 +++
4 files changed, 57 insertions(+), 33 deletions(-)
create mode 100644 drivers/gpu/drm/drm_platform_helpers.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 45e7719..266d199 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -7,7 +7,8 @@ drm-y := drm_auth.o drm_bufs.o drm_cache.o \
drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
drm_agpsupport.o drm_scatter.o drm_pci.o \
- drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
+ drm_platform.o drm_platform_helpers.o \
+ drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
diff --git a/drivers/gpu/drm/drm_platform_helpers.c
b/drivers/gpu/drm/drm_platform_helpers.c
new file mode 100644
index 000..a54c3e3
--- /dev/null
+++ b/drivers/gpu/drm/drm_platform_helpers.c
@@ -0,0 +1,45 @@
+/*
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+
+/**
+ * drm_platform_register_drivers - Helper to register an array of
+ * struct platform_drivers.
+ */
+int drm_platform_register_drivers(struct platform_driver *const *drv,
+ int count)
+{
+ int i, ret;
+
+ for (i = 0; i < count; ++i) {
+ ret = platform_driver_register(drv[i]);
+ if (ret) {
+ while (--i >= 0)
+ platform_driver_unregister(drv[i]);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(drm_platform_register_drivers);
+
+/**
+ * drm_platform_unregister_drivers - Helper to unregister an array of
+ * struct platform_drivers (in the opposite order they would have been
+ * registered by drm_platform_register_drivers()).
+ */
+void drm_platform_unregister_drivers(struct platform_driver *const *drv,
+int count)
+{
+ while (--count >= 0)
+ platform_driver_unregister(drv[count]);
+}
+EXPORT_SYMBOL_GPL(drm_platform_unregister_drivers);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index fa5194c..83f829b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -520,53 +520,27 @@ static int exynos_drm_register_devices(void)
return 0;
}
-static void exynos_drm_unregister_drivers(struct platform_driver * const *drv,
- int count)
-{
- while (--count >= 0)
- platform_driver_unregister(drv[count]);
-}
-
-static int exynos_drm_register_drivers(struct platform_driver * const *drv,
- int count)
-{
- int i, ret;
-
- for (i = 0; i < count; ++i) {
- ret = platform_driver_register(drv[i]);
- if (!ret)
- continue;
-
- while (--i >= 0)
- platform_driver_unregister(drv[i]);
-
- return ret;
- }
-
- return 0;
-}
-
static inline int exynos_drm_register_kms_drivers(void)
{
- return exynos_drm_register_drivers(exynos_drm_kms_drivers,
- ARRAY_SIZE(exynos_drm_kms_drivers));
+ return drm_platform_register_drivers(exynos_drm_kms_drivers,
+
ARRAY_SIZE(exynos_drm_kms_drivers));
}
static inline int exynos_drm_register_non_kms_drivers(void)
{
- return exynos_drm_register_drivers(exynos_drm_non_kms_drivers,
- ARRAY_SIZE(exynos_drm_non_kms_drivers));
+ return drm_platform_register_drivers(exynos_drm_non_kms_drivers,
+
ARRAY_SIZE(exynos_drm_non_kms_drivers));
}
static inline void exynos_drm_unregister_kms_drivers(void)
{
- exynos_drm_unregister_drivers(exynos_drm_kms_drivers,
+ drm_platform_unregister_drivers(exynos_drm_kms_drivers,
ARRAY_SIZE(exynos_drm_kms_drivers));
}
static inline void exy
drm: Platform helpers for exynos-style component registration.
I had previously modeled vc4 off of msm's component driver registration, but on further investigation exynos has an even cleaner way of doing it. Here's a series to turn exynos's style into core helpers, and use it from msm. The patches are build tested, but I don't have either of the platforms to test on.
[PATCH 0/3] RFC: Add a drm_aux-dev module.
On Wed, Sep 16, 2015 at 11:47:21PM +0300, Ville Syrjälä wrote: > On Wed, Sep 16, 2015 at 01:09:54PM -0700, Daniel Vetter wrote: > > On Tue, Sep 15, 2015 at 10:03:09AM -0700, Rafael Antognolli wrote: > > > On Tue, Sep 15, 2015 at 07:46:55PM +0300, Ville Syrjälä wrote: > > > > On Tue, Sep 15, 2015 at 07:41:06PM +0300, Ville Syrjälä wrote: > > > > > On Tue, Sep 15, 2015 at 09:34:15AM -0700, Rafael Antognolli wrote: > > > > > > On Tue, Sep 15, 2015 at 10:35:19AM +0300, Ville Syrjälä wrote: > > > > > > > On Mon, Sep 14, 2015 at 04:12:29PM -0700, Rafael Antognolli wrote: > > > > > > > > This is a tentative implementation of a module that allows > > > > > > > > reading/writing > > > > > > > > arbitrary dpcd registers, following the suggestion from Daniel > > > > > > > > Vetter. It > > > > > > > > assumes the drm aux helpers were used by the driver. > > > > > > > > > > > > > > > > I tried to follow the i2c-dev implementation as close as > > > > > > > > possible, but the only > > > > > > > > operations that are provided on the dev node are two different > > > > > > > > ioctl's, one for > > > > > > > > reading a register and another one for writing it. > > > > > > > > > > > > > > Why would you use ioctls instead of normal read/write syscalls? > > > > > > > > > > > > > > > > > > > For writing, that should work fine, I can easily change that if you > > > > > > prefer. > > > > > > > > > > > > For reading, one has to first tell which register address is going > > > > > > to be > > > > > > read. > > > > > > > > > > seek() > > > > > > > > Sorry typo. Make that lseek(). > > > > > > > Oh, nice, I'll update the patch with this and remove the notifier stuff, > > > thanks! > > > > Well there's also other modes like i2c over aux, and that would be easier > > to support with an ioctl in a uniform way. So not sure how much value > > there is in reusing read/write for i2c ... > > We already have i2c-dev for i2c. So not sure what you're after here. > > i2c is a bit of a mess on the protocol level. Lots of devices do > interesting things with it, so it can't really make do with just > read/write/lseek. Apart from i2c-over-aux, the rest is all about > DPCD access, and for that read/write/lseek is all you ever need. I just noticed that I forgot to cc you guys, but yesterday I sent an updated version of the patch set to this list: http://lists.freedesktop.org/archives/dri-devel/2015-September/090366.html I also don't have a strong opinion about ioctl vs read/write/lseek, but at least my second implementation did get a little cleaner. Thanks, Rafael
[PATCH] CHROMIUM: drm: bridge/dw_hdmi: Eliminate unused cable_plugin
There's a member in 'struct dw_hdmi' called cable_plugin. It's never
set to anything anywhere so thus is always false. There's a bit of code
checking it, but since it's always false this must be dead code.
Eliminate it.
Note: if someone wants to figure out the intention of the original code
and implement whatever feature / fix was needed then we can drop this
patch. The 'cable_plugin' member has been unused since the code was
first added in (9aaf880 imx-drm: Add mx6 hdmi transmitter support).
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/bridge/dw_hdmi.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 0083d4e..ba90885 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -115,7 +115,6 @@ struct dw_hdmi {
int vic;
u8 edid[HDMI_EDID_LEN];
- bool cable_plugin;
bool phy_enabled;
struct drm_display_mode previous_mode;
@@ -1203,12 +1202,6 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
hdmi_writeb(hdmi, val, HDMI_FC_INVIDCONF);
}
-static void hdmi_enable_overflow_interrupts(struct dw_hdmi *hdmi)
-{
- hdmi_writeb(hdmi, 0, HDMI_FC_MASK2);
- hdmi_writeb(hdmi, 0, HDMI_IH_MUTE_FC_STAT2);
-}
-
static void hdmi_disable_overflow_interrupts(struct dw_hdmi *hdmi)
{
hdmi_writeb(hdmi, HDMI_IH_MUTE_FC_STAT2_OVERFLOW_MASK,
@@ -1285,8 +1278,6 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct
drm_display_mode *mode)
hdmi_tx_hdcp_config(hdmi);
dw_hdmi_clear_overflow(hdmi);
- if (hdmi->cable_plugin && hdmi->sink_is_hdmi)
- hdmi_enable_overflow_interrupts(hdmi);
return 0;
}
--
2.6.0.rc0.131.gf624c3d
[Intel-gfx] Contribute to DRM
On Tue, 15 Sep 2015, Lucas Tanure wrote: > Hi, > > I would like to start to contribute to drm part of kernel. I tried a few > things: > > - Compiled linux-next tree using C=1 (sparse) to find things to improve. > But couldn't find any problem or issue. > - I looked in "www.x.org/wiki/DRMJanitors/" for stuff to do, but seems that > most of them are already done when I checked the code. > > - Compiled and run the linux-next tree to test the code. And for this I got > the warning below. > I tried to compile a few older versions of linux-next in order to find the > offending commit. But I didn't succeed, many commits don't boot at all, and > is difficult to get more information about the status of the warning for > that version. I think especially for getting started linux-next is too volatile. I'd go for Linus' git master first. After that, I'd still recommend driver specific trees rather than linux-next. drm/i915 branches are at http://cgit.freedesktop.org/drm-intel > So, I would like some tips about how to debug DRM code, how to test, how to > get more information about issues. > What I do is : > - Compile and run > - Restart to a good kernel > - "journalctl --boot=-1" to see if I got any warning on previous kernel > > Also, if any developer needs/wants some help and it's ok to guide a new guy > in DRM code, I would like to get help about tasks to do, things to > clean/improve. > I'm reading https://www.kernel.org/doc/htmldocs/drm/ to start, and I have > done a few courses from linux foundation. It's pretty hard to give generic advise; what works for me doesn't necessarily work for you. With that out of the way, try focusing on some detail and figure out how it works. Or find an itch and scratch it, maybe a bug you experience. Or a bug someone else has and you can reproduce it (product "DRI" at https://bugs.freedesktop.org/, you'll probably need to narrow the search down). Expand on related details, etc. Based on the warn you seem to have an Intel GPU, so you might find https://01.org/linuxgraphics/documentation helful. You might also get faster replies on IRC at #dri-devel and #intel-gfx on freenode, as long as you don't bug people too much. ;) HTH, Jani. -- Jani Nikula, Intel Open Source Technology Center
[PATCH RFC 0/8] Add New DRM Driver for Hisilicon's Hi6220 SoC
On Wed, Sep 16, 2015 at 04:23:35PM +0100, Daniel Stone wrote: > The biggest issue though, is that this driver should become an atomic > modesetting driver. Atomic modesetting, rather than sending small > individual commands (enable CRTC, change plane position, etc) is based > on validating and passing around complete sets of hardware state. > Daniel Vetter's blog has an article on how to convert your driver: > http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html Yeah, any new driver should really be built on top of atomic - it's a lot more flexible than the old thing and it's also what you want long-term. I've also just done a presenation about atomic for drivers: http://people.freedesktop.org/~danvet/presentations/xdc-2015.pdf Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 0/3] RFC: Add a drm_aux-dev module.
On Tue, Sep 15, 2015 at 10:03:09AM -0700, Rafael Antognolli wrote: > On Tue, Sep 15, 2015 at 07:46:55PM +0300, Ville Syrjälä wrote: > > On Tue, Sep 15, 2015 at 07:41:06PM +0300, Ville Syrjälä wrote: > > > On Tue, Sep 15, 2015 at 09:34:15AM -0700, Rafael Antognolli wrote: > > > > On Tue, Sep 15, 2015 at 10:35:19AM +0300, Ville Syrjälä wrote: > > > > > On Mon, Sep 14, 2015 at 04:12:29PM -0700, Rafael Antognolli wrote: > > > > > > This is a tentative implementation of a module that allows > > > > > > reading/writing > > > > > > arbitrary dpcd registers, following the suggestion from Daniel > > > > > > Vetter. It > > > > > > assumes the drm aux helpers were used by the driver. > > > > > > > > > > > > I tried to follow the i2c-dev implementation as close as possible, > > > > > > but the only > > > > > > operations that are provided on the dev node are two different > > > > > > ioctl's, one for > > > > > > reading a register and another one for writing it. > > > > > > > > > > Why would you use ioctls instead of normal read/write syscalls? > > > > > > > > > > > > > For writing, that should work fine, I can easily change that if you > > > > prefer. > > > > > > > > For reading, one has to first tell which register address is going to be > > > > read. > > > > > > seek() > > > > Sorry typo. Make that lseek(). > > > Oh, nice, I'll update the patch with this and remove the notifier stuff, > thanks! Well there's also other modes like i2c over aux, and that would be easier to support with an ioctl in a uniform way. So not sure how much value there is in reusing read/write for i2c ... But I really don't have a strong opinion about this. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 1/3] drm/dp: Keep a list of drm_dp_aux helper.
On Tue, Sep 15, 2015 at 07:57:19PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 15, 2015 at 09:27:27AM -0700, Rafael Antognolli wrote:
> > On Tue, Sep 15, 2015 at 10:46:43AM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 14, 2015 at 04:12:30PM -0700, Rafael Antognolli wrote:
> > > > This list will be used to get the aux channels registered through the
> > > > helpers. Two functions are provided to register/unregister notifier
> > > > listeners on the list, and another functiont to iterate over the list of
> > > > aux channels.
> > > >
> > > > Signed-off-by: Rafael Antognolli
> > > > ---
> > > > drivers/gpu/drm/drm_dp_helper.c | 71
> > > > +
> > > > include/drm/drm_dp_helper.h | 6
> > > > 2 files changed, 77 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > index 291734e..01a1489 100644
> > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > @@ -710,6 +710,54 @@ static const struct i2c_algorithm drm_dp_i2c_algo
> > > > = {
> > > > .master_xfer = drm_dp_i2c_xfer,
> > > > };
> > > >
> > > > +struct drm_dp_aux_node {
> > > > + struct klist_node list;
> > > > + struct drm_dp_aux *aux;
> > > > +};
> > > > +
> > > > +static DEFINE_KLIST(drm_dp_aux_list, NULL, NULL);
> > > > +
> > > > +static BLOCKING_NOTIFIER_HEAD(aux_notifier);
> > > > +
> > > > +int drm_dp_aux_register_notifier(struct notifier_block *nb)
> > > > +{
> > > > + return blocking_notifier_chain_register(&aux_notifier, nb);
> > > > +}
> > > > +EXPORT_SYMBOL(drm_dp_aux_register_notifier);
> > >
> > > Why is this notifier stuff needed? Why not just register/unregister the
> > > aux-dev directly?
> > >
> >
> > I am not sure it's needed, I was just looking for the best way of
> > informing aux-dev that a new aux channel was added.
> >
> > By register/unregister the aux-dev directly, do you mean making this
> > drm_dp_helper aware of the aux dev, when it's registered, and directly
> > calling some callback to inform that new aux channels were added?
>
> That was my thought, yes. It would mean the auxdev module can't be
> unloaded like i2c-dev, but I'm not sure that's a use case worth
> worrying about.
Yeah imo notifiers are evil because of locking inversion issues that
usually grop up, and having a use-case to unload dp_aux-dev seems
unlikely. Maybe we can do a Kconfig knob or something like that if some
people want to make the dev nodes optional.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
Hi,
On Sun, Aug 30, 2015 at 2:34 PM, Vladimir Zapolskiy
wrote:
> The change adds support of internal HDMI I2C master controller, this
> subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
>
> The main purpose of this functionality is to support reading EDID from
> an HDMI monitor on boards, which don't have an I2C bus connected to
> DDC pins.
>
> The current implementation does not support "I2C Master Interface
> Extended Read Mode" to read data addressed by non-zero segment
> pointer, this means that if EDID has more than 1 extension blocks,
> EDID reading operation won't succeed, in my practice all tested HDMI
> monitors have at maximum one extension block.
>
> Signed-off-by: Vladimir Zapolskiy
> ---
> The change is based on today's v4.2, please let me know, if it should be
> rebased.
>
> The change has compilation dependency on I2CM_ADDRESS register name fix,
> see http://lists.freedesktop.org/archives/dri-devel/2015-May/082980.html
>
> From http://lists.freedesktop.org/archives/dri-devel/2015-May/082981.html
> v1 of the change was
>
> Tested-by: Philipp Zabel
>
> but I hesitate to add the tag here due to multiple updates in v2.
>
> Changes from v2 to v3, thanks to Russell:
> - moved register field value definitions to dw_hdmi.h
> - made completions uninterruptible to avoid transfer retries if interrupted
> - use one completion for both read and write transfers as in v1,
> operation_reg is removed
> - redundant i2c->stat = 0 is removed from dw_hdmi_i2c_read/write()
> - struct i2c_algorithm dw_hdmi_algorithm is qualified as const
> - dw_hdmi_i2c_adapter() does not modify struct dw_hdmi on error path
> - dw_hdmi_i2c_irq() does not modify hdmi->i2c->stat, if interrupt is not for
> I2CM
> - spin lock is removed from dw_hdmi_i2c_irq()
> - removed spin lock from dw_hdmi_i2c_xfer() around write to
> HDMI_IH_MUTE_I2CM_STAT0 register
> - split loop over message array in dw_hdmi_i2c_xfer() to validation and
> transfer parts
> - added a mutex to serialize I2C transfer requests, i2c->lock is completely
> removed
> - removed if(len) check from dw_hdmi_i2c_write(), hardware supports only
> len>0 transfers
> - described extension blocks <= 1 limitation in the commit message
> - a number of minor clean ups
>
> Changes from v1 to v2:
> - fixed a devm_kfree() signature
> - split completions for read and write operations
>
> drivers/gpu/drm/bridge/dw_hdmi.c | 262
> ++-
> drivers/gpu/drm/bridge/dw_hdmi.h | 19 +++
> 2 files changed, 275 insertions(+), 6 deletions(-)
Not sure what the status of this patch is, but I'll make a few more
suggestions in case they're helpful.
> +static void dw_hdmi_i2c_init(struct dw_hdmi *hdmi)
> +{
> + /* Set Fast Mode speed */
> + hdmi_writeb(hdmi, 0x0b, HDMI_I2CM_DIV);
If you're going to hardcode to something, it seems like hardcoding to
standard mode might be better? It's likely that users will plug into
all kinds of broken / crappy HDMI devices out there. I think you'll
get better compatibility by using the slower mode, and EDID transfers
really aren't too performance critical are they?
> +
> + /* Software reset */
> + hdmi_writeb(hdmi, 0x00, HDMI_I2CM_SOFTRSTZ);
Unless there's a reason not to, it seems like the reset ought to be
the first thing in this function (before setting the I2CM_DIV). Even
if it doesn't actually reset the speed on current hardware, it just
seems cleaner.
> +static int dw_hdmi_i2c_xfer(struct i2c_adapter *adap,
> + struct i2c_msg *msgs, int num)
> +{
> + struct dw_hdmi *hdmi = i2c_get_adapdata(adap);
> + struct dw_hdmi_i2c *i2c = hdmi->i2c;
> + u8 addr = msgs[0].addr;
> + int i, ret = 0;
> +
> + dev_dbg(hdmi->dev, "xfer: num: %d, addr: %#x\n", num, addr);
> +
> + for (i = 0; i < num; i++) {
> + if (msgs[i].addr != addr) {
> + dev_warn(hdmi->dev,
> +"unsupported transfer, changed slave
> address\n");
> + return -EOPNOTSUPP;
> + }
> +
> + if (msgs[i].len == 0) {
> + dev_dbg(hdmi->dev,
> + "unsupported transfer %d/%d, no data\n",
> + i + 1, num);
> + return -EOPNOTSUPP;
> + }
> + }
> +
> + mutex_lock(&i2c->lock);
> +
If I may make a suggestion, it's worth considering putting
dw_hdmi_i2c_init() here and removing it from the dw_hdmi_bind()
function. There isn't any state kept between i2c transfers (each one
is independent), so re-initting each time won't hurt. ...and doing so
has the potential to fix some things.
On rk3288 there's at least one case where the i2c controller can get
wedged and just totally stops working. Although this particular wedge
isn't fixed by calling dw_hdmi_i2c_init() (it needs a full controller
reset to fix), it's possible that ther
[PATCH RFCv2 3/4] staging: etnaviv: add drm driver
2015-09-16 10:04 GMT+02:00 Russell King - ARM Linux : > On Fri, Sep 11, 2015 at 04:10:13PM +0200, Lucas Stach wrote: >> From: Christian Gmeiner >> >> This is a squashed commit of the complete etnaviv DRM driver in order >> to make it easy for people to review the code by seeing the driver as a >> whole and is not intended for merging in this form. >> >> If you are interested in the history of individual commits: >> git://git.pengutronix.de/git/lst/linux.git etnaviv-for-upstream >> >> Signed-off-by: Christian Gmeiner >> Signed-off-by: Russell King >> Signed-off-by: Lucas Stach > > Lucas, > > I know that the previous round, people said that they didn't like the > individual patches posted, but squashing everything together into one > patch is also not good. > > It would make more sense (at least for me) if you squashed the work > that has already been done into one patch, and then post your updates > as individual patches. That way, Christian and myself can see what > the changes are against some known without having to dig through your > git tree, and those who complained about all the patches last time > have fewer patches to look at. > > Expecting those in the project to page through thousands of lines that > they already know about, hoping to spot the changes you've made is > really very unreasonable and error prone. I will _NOT_ be wasting my > time reviewing this mega-patch exactly because of that. > Yep it quite hard to review it that way - I only had a look at the user space <-> kernel space api/abi. greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner
[PATCH 1/4] drm: Put platform driver registration/unregistration loops in core.
On Wed, Sep 16, 2015 at 11:14 AM, Eric Anholt wrote:
> This is mostly just a move of the code from exynos, with a slight
> reformat. I wanted to do a similar thing for vc4, and msm looks like
> a good candidate as well.
>
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/Makefile| 3 ++-
> drivers/gpu/drm/drm_platform_helpers.c | 45
> +
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 38 +---
> include/drm/drmP.h | 4 +++
> 4 files changed, 57 insertions(+), 33 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_platform_helpers.c
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 45e7719..266d199 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -7,7 +7,8 @@ drm-y := drm_auth.o drm_bufs.o drm_cache.o \
> drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
> drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
> drm_agpsupport.o drm_scatter.o drm_pci.o \
> - drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
> + drm_platform.o drm_platform_helpers.o \
> + drm_sysfs.o drm_hashtab.o drm_mm.o \
Imo it'd would be good to have a separate module for helpers like
these (maybe even put them into the kms helpers). At least that
explicit split on the modeset side seems to help with a clean split
between mandatory core bits and helper code.
> drm_crtc.o drm_modes.o drm_edid.o \
> drm_info.o drm_debugfs.o drm_encoder_slave.o \
> drm_trace_points.o drm_global.o drm_prime.o \
> diff --git a/drivers/gpu/drm/drm_platform_helpers.c
> b/drivers/gpu/drm/drm_platform_helpers.c
> new file mode 100644
> index 000..a54c3e3
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_platform_helpers.c
> @@ -0,0 +1,45 @@
> +/*
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include
> +
> +/**
> + * drm_platform_register_drivers - Helper to register an array of
> + * struct platform_drivers.
> + */
Please add a new section to Documentation/DocBook/drm.tmpl so that
these kerneldoc comments are included. Without that 0day won't catch
mismatches in kerneldoc and hopefully including it will also make it a
bit more discoverable. And with the new markdown stuff in
drm-intel-nightly you could even include an example snippet for how to
use it, but that's kinda overkilla ;-) If you do that kerneldoc will
complain about the missing parameter helpers. Also I recommend to
point at other functions which should be used together with this one
(like _unregister), in 4.3 the htmldocs will actually insert
hyperlinks for that.
Thanks, Daniel
> +int drm_platform_register_drivers(struct platform_driver *const *drv,
> + int count)
> +{
> + int i, ret;
> +
> + for (i = 0; i < count; ++i) {
> + ret = platform_driver_register(drv[i]);
> + if (ret) {
> + while (--i >= 0)
> + platform_driver_unregister(drv[i]);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(drm_platform_register_drivers);
> +
> +/**
> + * drm_platform_unregister_drivers - Helper to unregister an array of
> + * struct platform_drivers (in the opposite order they would have been
> + * registered by drm_platform_register_drivers()).
> + */
> +void drm_platform_unregister_drivers(struct platform_driver *const *drv,
> +int count)
> +{
> + while (--count >= 0)
> + platform_driver_unregister(drv[count]);
> +}
> +EXPORT_SYMBOL_GPL(drm_platform_unregister_drivers);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index fa5194c..83f829b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -520,53 +520,27 @@ static int exynos_drm_register_devices(void)
> return 0;
> }
>
> -static void exynos_drm_unregister_drivers(struct platform_driver * const
> *drv,
> - int count)
> -{
> - while (--count >= 0)
> - platform_driver_unregister(drv[count]);
> -}
> -
> -static int exynos_drm_register_drivers(struct platform_driver * const *drv,
> - int count)
> -{
> - int i, ret;
> -
> - for (i = 0; i < count; ++i) {
> - ret = platform_driver_register(drv[i]);
> - if (!ret)
> - continue;
> -
> - while (--i >= 0)
> -
[PATCH 0/4] drm: atomic fb-helper support
On Tue, Aug 25, 2015 at 12:35 PM, Rob Clark wrote: > Convert fb-helper, or at least the two code-paths which potentially > trigger more than a single update, to use atomic API if the driver > supports it. > > The first patch is slightly unrelated, but I needed to add kerneldoc > for 'struct drm_fb_helper' before I could add kerneldoc for the new > atomic field. Danvet tricked me into writing some kerneldoc that > way. > > In theory, after this, we can re-introduce the ww_acquire_fini() > call. > > Rob Clark (4): > drm/fb-helper: add headerdoc for drm_fb_helper > drm/fb-helper: atomic restore_fbdev_mode().. > drm/fb-helper: atomic pan_display().. > drm/i915: enable atomic fb-helper Ok I applied the small comment bikesheds to patch 2 and merged all four to drm-misc. Thanks, Daniel > drivers/gpu/drm/drm_atomic_helper.c | 131 > +--- > drivers/gpu/drm/drm_fb_helper.c | 131 > > drivers/gpu/drm/i915/intel_fbdev.c | 2 + > include/drm/drm_atomic_helper.h | 6 ++ > include/drm/drm_fb_helper.h | 22 ++ > 5 files changed, 239 insertions(+), 53 deletions(-) > > -- > 2.4.3 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 12/31] drm/amdgpu: use kmemdup rather than duplicating its implementation
Ping. Regards Andrzej On 08/07/2015 09:59 AM, Andrzej Hajda wrote: > The patch was generated using fixed coccinelle semantic patch > scripts/coccinelle/api/memdup.cocci [1]. > > [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320 > > Signed-off-by: Andrzej Hajda > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > index 8da6424..94bd992 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > @@ -549,12 +549,10 @@ int amdgpu_bo_set_metadata (struct amdgpu_bo *bo, void > *metadata, > if (metadata == NULL) > return -EINVAL; > > - buffer = kzalloc(metadata_size, GFP_KERNEL); > + buffer = kmemdup(metadata, metadata_size, GFP_KERNEL); > if (buffer == NULL) > return -ENOMEM; > > - memcpy(buffer, metadata, metadata_size); > - > kfree(bo->metadata); > bo->metadata_flags = flags; > bo->metadata = buffer;
[PATCH] drm/mgag200: Fix calling drm_fb_helper_fini() twice
* Archit Taneja wrote: > From: Archit Taneja > Date: Mon, 14 Sep 2015 20:11:43 +0530 > Subject: [PATCH] drm/mgag200: Prevent calling drm_fb_helper_fini twice > > mgag200_fbdev_init's error handling path calls drm_fb_helper_fini before > bailing out. The error handling path of mgag200_driver_load also ends > up calling drm_fb_helper_fini. > > This results in drm_fb_helper_fini being called twice if the driver load > drm op fails somewhere in between. > > Make only mgag200_driver_unload call drm_fb_helper_fini, remove the call > from mgag200_fbdev_init. > > Signed-off-by: Archit Taneja > --- > drivers/gpu/drm/mgag200/mgag200_fb.c | 8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c > b/drivers/gpu/drm/mgag200/mgag200_fb.c > index 87de15e..6259b0a 100644 > --- a/drivers/gpu/drm/mgag200/mgag200_fb.c > +++ b/drivers/gpu/drm/mgag200/mgag200_fb.c > @@ -280,20 +280,16 @@ int mgag200_fbdev_init(struct mga_device *mdev) > > ret = drm_fb_helper_single_add_all_connectors(&mfbdev->helper); > if (ret) > - goto fini; > + return ret; > > /* disable all the possible outputs/crtcs before entering KMS mode */ > drm_helper_disable_unused_functions(mdev->dev); > > ret = drm_fb_helper_initial_config(&mfbdev->helper, bpp_sel); > if (ret) > - goto fini; > + return ret; > > return 0; > - > -fini: > - drm_fb_helper_fini(&mfbdev->helper); > - return ret; > } > > void mgag200_fbdev_fini(struct mga_device *mdev) So this patch was whitespace damaged - I applied it by hand and made the commit below. This has solved the crash, thanks Archit! And yes, you are right that my config probably crashed with older kernels too. Ingo => >From 60d733a3ec19dc72372e12207a0a86293cd40cf5 Mon Sep 17 00:00:00 2001 From: Archit Taneja Date: Mon, 14 Sep 2015 20:53:57 +0530 Subject: [PATCH] drm/mgag200: Fix calling drm_fb_helper_fini() twice mgag200_fbdev_init()'s error handling path calls drm_fb_helper_fini() before bailing out. The error handling path of mgag200_driver_load() also ends up calling drm_fb_helper_fini(). This results in drm_fb_helper_fini() being called twice if the driver load drm op fails somewhere in between. Make only mgag200_driver_unload() call drm_fb_helper_fini(), remove the call from mgag200_fbdev_init(). Reported-by: Ingo Molnar Signed-off-by: Archit Taneja Cc: Archit Taneja Cc: Daniel Vetter Cc: Dave Airlie Cc: David Airlie Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Sudip Mukherjee Cc: Thomas Gleixner Cc: dri-devel Link: http://lkml.kernel.org/r/55F6E68D.8070800 at codeaurora.org Signed-off-by: Ingo Molnar --- drivers/gpu/drm/mgag200/mgag200_fb.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c b/drivers/gpu/drm/mgag200/mgag200_fb.c index 87de15ea1f93..6259b0a5fc38 100644 --- a/drivers/gpu/drm/mgag200/mgag200_fb.c +++ b/drivers/gpu/drm/mgag200/mgag200_fb.c @@ -280,20 +280,16 @@ int mgag200_fbdev_init(struct mga_device *mdev) ret = drm_fb_helper_single_add_all_connectors(&mfbdev->helper); if (ret) - goto fini; + return ret; /* disable all the possible outputs/crtcs before entering KMS mode */ drm_helper_disable_unused_functions(mdev->dev); ret = drm_fb_helper_initial_config(&mfbdev->helper, bpp_sel); if (ret) - goto fini; + return ret; return 0; - -fini: - drm_fb_helper_fini(&mfbdev->helper); - return ret; } void mgag200_fbdev_fini(struct mga_device *mdev)
[PATCH RFCv2 3/4] staging: etnaviv: add drm driver
Am Mittwoch, den 16.09.2015, 09:04 +0100 schrieb Russell King - ARM Linux: > On Fri, Sep 11, 2015 at 04:10:13PM +0200, Lucas Stach wrote: > > From: Christian Gmeiner > > > > This is a squashed commit of the complete etnaviv DRM driver in > > order > > to make it easy for people to review the code by seeing the driver > > as a > > whole and is not intended for merging in this form. > > > > If you are interested in the history of individual commits: > > git://git.pengutronix.de/git/lst/linux.git etnaviv-for-upstream > > > > Signed-off-by: Christian Gmeiner > > Signed-off-by: Russell King > > Signed-off-by: Lucas Stach > > Lucas, > > I know that the previous round, people said that they didn't like the > individual patches posted, but squashing everything together into one > patch is also not good. > I still think it's useful for those that haven't looked at that code yet. > It would make more sense (at least for me) if you squashed the work > that has already been done into one patch, and then post your updates > as individual patches. That way, Christian and myself can see what > the changes are against some known without having to dig through your > git tree, and those who complained about all the patches last time > have fewer patches to look at. > > Expecting those in the project to page through thousands of lines > that > they already know about, hoping to spot the changes you've made is > really very unreasonable and error prone. I will _NOT_ be wasting my > time reviewing this mega-patch exactly because of that. > Sure, I will follow up with a partially squashed version to get you the changes from RFCv1. If you have any comments before that I'm totally fine with you posting them out of context. I'll take care of mapping them back to patches. Regards, Lucas
[PATCH RFC 6/8] drm: hisilicon: Add support for fbdev
hi rob On 2015/9/16 2:25, Rob Herring wrote: > On 09/15/2015 04:37 AM, Xinwei Kong wrote: >> If you config DRM_HISI_FBDEV optional, this patch will only support fbdev >> mode while also supporting double buffer. > > This is a lot of duplicated code from CMA fbdev. Is double buffering the > only reason why CMA fbdev can't be used or are there some other > constraints? Double buffering in fbdev has always been a hack, so I'm > guessing that is not a feature that should be added here. > I will drop it. xinwei > Rob > >> Signed-off-by: Xinliang Liu >> Signed-off-by: Xinwei Kong >> Signed-off-by: Andy Green >> Signed-off-by: Jiwen Qi >> Signed-off-by: Yu Gong >> --- >> drivers/gpu/drm/hisilicon/Kconfig | 13 + >> drivers/gpu/drm/hisilicon/Makefile | 3 +- >> drivers/gpu/drm/hisilicon/hisi_drm_connector.c | 4 + >> drivers/gpu/drm/hisilicon/hisi_drm_drv.c | 9 + >> drivers/gpu/drm/hisilicon/hisi_drm_dsi.c | 15 + >> drivers/gpu/drm/hisilicon/hisi_drm_fb.h| 5 + >> drivers/gpu/drm/hisilicon/hisi_drm_fbdev.c | 395 >> + >> drivers/gpu/drm/hisilicon/hisi_drm_fbdev.h | 24 ++ >> 8 files changed, 467 insertions(+), 1 deletion(-) >> create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_fbdev.c >> create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_fbdev.h > > > . >
[PATCH RFCv2 3/4] staging: etnaviv: add drm driver
Am Mittwoch, den 16.09.2015, 08:11 +0200 schrieb Christian Gmeiner:
> Hi Lucas
>
>
> 2015-09-11 16:10 GMT+02:00 Lucas Stach :
> > From: Christian Gmeiner
> >
> > This is a squashed commit of the complete etnaviv DRM driver in
> > order
> > to make it easy for people to review the code by seeing the driver
> > as a
> > whole and is not intended for merging in this form.
> >
> > If you are interested in the history of individual commits:
> > git://git.pengutronix.de/git/lst/linux.git etnaviv-for-upstream
> >
> > Signed-off-by: Christian Gmeiner
> > Signed-off-by: Russell King
> > Signed-off-by: Lucas Stach
> > ---
[...]
> > +/*
> > + * Cmdstream Submission:
> > + */
> > +
> > +/* The value written into the cmdstream is logically:
> > + * relocbuf->gpuaddr + reloc_offset
> > + *
> > + * NOTE that reloc's must be sorted by order of increasing
> > submit_offset,
> > + * otherwise EINVAL.
> > + */
> > +struct drm_etnaviv_gem_submit_reloc {
> > + __u32 submit_offset; /* in, offset from submit_bo */
> > + __u32 reloc_idx; /* in, index of reloc_bo buffer */
> > + __u64 reloc_offset; /* in, offset from start of reloc_bo
> > */
> > +};
> > +
> > +/* Each buffer referenced elsewhere in the cmdstream submit (ie.
> > the
> > + * cmdstream buffer(s) themselves or reloc entries) has one (and
> > only
> > + * one) entry in the submit->bos[] table.
> > + *
> > + * As a optimization, the current buffer (gpu virtual address) can
> > be
> > + * passed back through the 'presumed' field. If on a subsequent
> > reloc,
> > + * userspace passes back a 'presumed' address that is still valid,
> > + * then patching the cmdstream for this entry is skipped. This
> > can
> > + * avoid kernel needing to map/access the cmdstream bo in the
> > common
> > + * case.
> > + */
> > +#define ETNA_SUBMIT_BO_READ 0x0001
> > +#define ETNA_SUBMIT_BO_WRITE0x0002
> > +struct drm_etnaviv_gem_submit_bo {
> > + __u32 flags; /* in, mask of ETNA_SUBMIT_BO_x */
> > + __u32 handle; /* in, GEM handle */
> > + __u64 presumed; /* in/out, presumed buffer address */
> > +};
> > +=
>
> As presumed never gets used in the driver itself and I am not a big
> fan of it,
> can we remove it? Do you see any usecase for it?
>
I think it could be useful to skip cmdstream patching on MMUv2. But to
be honest I don't know how much of a difference this will make, now
that we are operating on cached memory for the command stream as long
as possible. I'll try to get some performance profile, but at this
point I think it makes sense to get rid of it.
Regards
Lucas
[PATCH 2/2] drm/dp/mst: fixup handling hotplug on port removal.
From: Dave Airlie
output ports should always have a connector, unless
in the rare case connector allocation fails in the
driver.
In this case we only need to teardown the pdt,
and free the struct, and there is no need to
send a hotplug msg.
In the case were we add the port to the destroy
list we need to send a hotplug if we destroy
any connectors, so userspace knows to reprobe
stuff.
this patch also handles port->connector allocation
failing which should be a rare event, but makes
the code consistent.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 36 +--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 87112d3..d11052c 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -863,29 +863,33 @@ static void drm_dp_destroy_port(struct kref *kref)
{
struct drm_dp_mst_port *port = container_of(kref, struct
drm_dp_mst_port, kref);
struct drm_dp_mst_topology_mgr *mgr = port->mgr;
+
if (!port->input) {
port->vcpi.num_slots = 0;
kfree(port->cached_edid);
- /* we can't destroy the connector here, as
- we might be holding the mode_config.mutex
- from an EDID retrieval */
+ /*
+* The only time we don't have a connector
+* on an output port is if the connector init
+* fails.
+*/
if (port->connector) {
+ /* we can't destroy the connector here, as
+* we might be holding the mode_config.mutex
+* from an EDID retrieval */
+
mutex_lock(&mgr->destroy_connector_lock);
list_add(&port->next, &mgr->destroy_connector_list);
mutex_unlock(&mgr->destroy_connector_lock);
schedule_work(&mgr->destroy_connector_work);
return;
}
+ /* no need to clean up vcpi
+* as if we have no connector we never setup a vcpi */
drm_dp_port_teardown_pdt(port, port->pdt);
-
- if (!port->input && port->vcpi.vcpi > 0)
- drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi);
}
kfree(port);
-
- (*mgr->cbs->hotplug)(mgr);
}
static void drm_dp_put_port(struct drm_dp_mst_port *port)
@@ -1116,12 +1120,21 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
*mstb,
build_mst_prop_path(mstb, port->port_num, proppath,
sizeof(proppath));
port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr,
port, proppath);
-
+ if (!port->connector) {
+ /* remove it from the port list */
+ mutex_lock(&mstb->mgr->lock);
+ list_del(&port->next);
+ mutex_unlock(&mstb->mgr->lock);
+ /* drop port list reference */
+ drm_dp_put_port(port);
+ goto out;
+ }
if (port->port_num >= 8) {
port->cached_edid = drm_get_edid(port->connector,
&port->aux.ddc);
}
}
+out:
/* put reference to this port */
drm_dp_put_port(port);
}
@@ -2672,7 +2685,7 @@ static void drm_dp_destroy_connector_work(struct
work_struct *work)
{
struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct
drm_dp_mst_topology_mgr, destroy_connector_work);
struct drm_dp_mst_port *port;
-
+ bool send_hotplug = false;
/*
* Not a regular list traverse as we have to drop the destroy
* connector lock before destroying the connector, to avoid AB->BA
@@ -2695,7 +2708,10 @@ static void drm_dp_destroy_connector_work(struct
work_struct *work)
if (!port->input && port->vcpi.vcpi > 0)
drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi);
kfree(port);
+ send_hotplug = true;
}
+ if (send_hotplug)
+ (*mgr->cbs->hotplug)(mgr);
}
/**
--
2.4.3
[PATCH 1/2] drm/dp/mst: don't pass port into the path builder function
From: Dave Airlie
This is unnecessary and it makes it easier to see what is needed
from port.
also add blank line to make things nicer.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index e23df5f..87112d3 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1027,8 +1027,8 @@ static void drm_dp_check_port_guid(struct
drm_dp_mst_branch *mstb,
}
}
-static void build_mst_prop_path(struct drm_dp_mst_port *port,
- struct drm_dp_mst_branch *mstb,
+static void build_mst_prop_path(const struct drm_dp_mst_branch *mstb,
+ int pnum,
char *proppath,
size_t proppath_size)
{
@@ -1041,7 +1041,7 @@ static void build_mst_prop_path(struct drm_dp_mst_port
*port,
snprintf(temp, sizeof(temp), "-%d", port_num);
strlcat(proppath, temp, proppath_size);
}
- snprintf(temp, sizeof(temp), "-%d", port->port_num);
+ snprintf(temp, sizeof(temp), "-%d", pnum);
strlcat(proppath, temp, proppath_size);
}
@@ -1113,7 +1113,8 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
*mstb,
if (created && !port->input) {
char proppath[255];
- build_mst_prop_path(port, mstb, proppath, sizeof(proppath));
+
+ build_mst_prop_path(mstb, port->port_num, proppath,
sizeof(proppath));
port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr,
port, proppath);
if (port->port_num >= 8) {
--
2.4.3
[PATCH RFCv2 3/4] staging: etnaviv: add drm driver
Lucas Stach writes:
> From: Christian Gmeiner
> +static bool etnaviv_validate_load_state(struct etnaviv_gpu *gpu, u32 *buf,
> + unsigned int state, unsigned int num)
> +{
> + return true;
> + if (0x1200 - state < num * 4)
> + return false;
> + if (0x1228 - state < num * 4)
> + return false;
> + if (0x1238 - state < num * 4)
> + return false;
> + if (0x1284 - state < num * 4)
> + return false;
> + if (0x128c - state < num * 4)
> + return false;
> + if (0x1304 - state < num * 4)
> + return false;
> + if (0x1310 - state < num * 4)
> + return false;
> + if (0x1318 - state < num * 4)
> + return false;
> + if (0x1280c - state < num * 4 + 0x0c)
> + return false;
> + if (0x128ac - state < num * 4 + 0x0c)
> + return false;
> + if (0x128cc - state < num * 4 + 0x0c)
> + return false;
> + if (0x1297c - state < num * 4 + 0x0c)
> + return false;
> + return true;
> +}
I was browsing the code, and noticed that it looks like you've got a
debugging early return in your validation function here.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150916/e05ca0b4/attachment-0001.sig>
[PATCH 02/23] drm: Add structure for querying palette color capabilities
On Wed, Sep 16, 2015 at 11:06:59PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi
>
> The DRM color management framework is targeting various hardware
> platforms and drivers. Different platforms can have different color
> correction and enhancement capabilities.
>
> A commom user space application can query these capabilities using the
> DRM property interface. Each driver can fill this property with its
> platform's palette color capabilities.
>
> This patch adds new structure in DRM layer for querying palette color
> capabilities. This structure will be used by all user space
> agents to configure appropriate color configurations.
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
I think you provided an explanation on a previous code review cycle, but
I forget the details now...what's the benefit to using a blob for caps
rather than having these be individual properties? Individual
properties seems more natural to me, but I think you had a justification
for blobbing them together; that reasoning would be good to include in
the commit message.
Matt
> ---
> include/uapi/drm/drm.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 3801584..e3c642f 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -829,6 +829,17 @@ struct drm_event_vblank {
> __u32 reserved;
> };
>
> +struct drm_palette_caps {
> + /* Structure version. Should be 1 currently */
> + __u32 version;
> + /* For padding and future use */
> + __u32 reserved;
> + /* This may be 0 if not supported. e.g. plane palette or VLV pipe */
> + __u32 num_samples_before_ctm;
> + /* This will be non-zero for pipe. May be zero for planes on some HW */
> + __u32 num_samples_after_ctm;
> +};
> +
> /* typedef area */
> #ifndef __KERNEL__
> typedef struct drm_clip_rect drm_clip_rect_t;
> --
> 1.9.1
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
[PATCH 01/23] drm: Create Color Management DRM properties
On Wed, Sep 16, 2015 at 11:06:58PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi
>
> Color Management is an extension to Kernel display framework. It allows
> abstraction of hardware color correction and enhancement capabilities by
> virtue of DRM properties.
>
> This patch initializes color management framework by :
> 1. Introducing new pointers in DRM mode_config structure to
>carry CTM and Palette color correction properties.
> 2. Creating these DRM properties in DRM standard properties creation
>sequence.
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
We should probably update the property section of
Documentation/DocBook/drm.tmpl with this patch as well to include these
new properties in the table (that docbook ultimately generates
documentation that looks like
https://kernel.org/doc/htmldocs/drm/drm-kms-properties.html ).
One minor note: people not involved in color management probably won't
immediately figure out what "CTM" stands for, so you might want to just
add a comment somewhere that spells out the full "color transformation
matrix" term.
Matt
> ---
> drivers/gpu/drm/drm_crtc.c | 26 ++
> include/drm/drm_crtc.h | 6 ++
> 2 files changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 9b9c4b4..d809c67 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1472,6 +1472,32 @@ static int drm_mode_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.prop_mode_id = prop;
>
> + /* Color Management properties */
> + prop = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB | DRM_MODE_PROP_IMMUTABLE,
> + "CRTC_PALETTE_CAPABILITIES", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.cm_crtc_palette_capabilities_property = prop;
> +
> + prop = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB, "PALETTE_AFTER_CTM", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.cm_palette_after_ctm_property = prop;
> +
> + prop = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB, "PALETTE_BEFORE_CTM", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.cm_palette_before_ctm_property = prop;
> +
> + prop = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB, "CTM", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.cm_ctm_property = prop;
> +
> return 0;
> }
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index c0366e9..c35531e 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1153,6 +1153,12 @@ struct drm_mode_config {
> struct drm_property *suggested_x_property;
> struct drm_property *suggested_y_property;
>
> + /* Color Management Properties */
> + struct drm_property *cm_crtc_palette_capabilities_property;
> + struct drm_property *cm_palette_before_ctm_property;
> + struct drm_property *cm_palette_after_ctm_property;
> + struct drm_property *cm_ctm_property;
> +
> /* dumb ioctl parameters */
> uint32_t preferred_depth, prefer_shadow;
>
> --
> 1.9.1
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
[PATCH] drm/dp_mst: don't send hotplug if input ports change.
From: Dave Airlie
I suspect we might need to rethink when we send hotplug callback
but this at least stops us from sending them when we defintely
don't need to.
DP input port state changes aren't necessary to report.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index e23df5f..cfb0b96 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -863,7 +863,8 @@ static void drm_dp_destroy_port(struct kref *kref)
{
struct drm_dp_mst_port *port = container_of(kref, struct
drm_dp_mst_port, kref);
struct drm_dp_mst_topology_mgr *mgr = port->mgr;
- if (!port->input) {
+ bool is_input = port->input;
+ if (!is_input) {
port->vcpi.num_slots = 0;
kfree(port->cached_edid);
@@ -885,7 +886,10 @@ static void drm_dp_destroy_port(struct kref *kref)
}
kfree(port);
- (*mgr->cbs->hotplug)(mgr);
+ /* we should only cause a hotplug if an output port changes
+* input ports shouldn't. */
+ if (!is_input)
+ (*mgr->cbs->hotplug)(mgr);
}
static void drm_dp_put_port(struct drm_dp_mst_port *port)
--
2.4.3
[PATCH 1/1] signals: kill block_all_signals() and unblock_all_signals()
On 16 September 2015 at 02:41, Oleg Nesterov wrote: > ping ;) > > Andrew, should I re-send this patch? It was acked by Daniel and Dave > doesn't object. > > Dave, I'll appreciate it if you ack it explicitly. > > > On 08/27, Oleg Nesterov wrote: >> >> It is hardly possible to enumerate all problems with block_all_signals() >> and unblock_all_signals(). Just for example, >> >> 1. block_all_signals(SIGSTOP/etc) simply can't help if the caller is >>multithreaded. Another thread can dequeue the signal and force the >>group stop. >> >> 2. Even is the caller is single-threaded, it will "stop" anyway. It >>will not sleep, but it will spin in kernel space until SIGCONT or >>SIGKILL. >> >> And a lot more. In short, this interface doesn't work at all, at least >> the last 10+ years. >> >> Signed-off-by: Oleg Nesterov Acked-by: Dave Airlie Probably best to go via Andrew alright. Dave.
[PATCH v3 RESEND 0/5] Remaining part of kill off set_irq_flags usage
On 08/29/2015 06:01 PM, Rob Herring wrote: > Thomas, > > As requested, here are the remaining patches for killing off > set_irq_flags which have not been picked up. The rest of the > series has been picked up and are in -next. Thomas, are you going to pick up these remaining patches? Rob > > Rob > > Rob Herring (5): > gpu/drm: kill off set_irq_flags usage > irqchip: kill off set_irq_flags usage > sh: kill off set_irq_flags usage > ARM: remove ununsed set_irq_flags > arm64: remove ununsed set_irq_flags > > arch/arm/include/asm/hw_irq.h | 6 -- > arch/arm/kernel/irq.c | 20 > arch/arm64/include/asm/hardirq.h | 5 - > drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 1 - > drivers/gpu/ipu-v3/ipu-common.c | 3 +-- > drivers/irqchip/exynos-combiner.c | 2 +- > drivers/irqchip/irq-armada-370-xp.c | 3 +-- > drivers/irqchip/irq-bcm2835.c | 2 +- > drivers/irqchip/irq-clps711x.c| 6 +++--- > drivers/irqchip/irq-gic-v3.c | 5 ++--- > drivers/irqchip/irq-gic.c | 4 ++-- > drivers/irqchip/irq-hip04.c | 4 ++-- > drivers/irqchip/irq-keystone.c| 2 +- > drivers/irqchip/irq-mmp.c | 3 --- > drivers/irqchip/irq-mxs.c | 1 - > drivers/irqchip/irq-renesas-intc-irqpin.c | 1 - > drivers/irqchip/irq-renesas-irqc.c| 1 - > drivers/irqchip/irq-s3c24xx.c | 14 ++ > drivers/irqchip/irq-sun4i.c | 2 +- > drivers/irqchip/irq-versatile-fpga.c | 2 +- > drivers/irqchip/irq-vic.c | 2 +- > drivers/irqchip/irq-vt8500.c | 1 - > drivers/irqchip/spear-shirq.c | 1 - > drivers/sh/intc/internals.h | 10 +- > 24 files changed, 20 insertions(+), 81 deletions(-) >
[PATCH RFCv2 3/4] staging: etnaviv: add drm driver
On Fri, Sep 11, 2015 at 04:10:13PM +0200, Lucas Stach wrote: > From: Christian Gmeiner > > This is a squashed commit of the complete etnaviv DRM driver in order > to make it easy for people to review the code by seeing the driver as a > whole and is not intended for merging in this form. > > If you are interested in the history of individual commits: > git://git.pengutronix.de/git/lst/linux.git etnaviv-for-upstream > > Signed-off-by: Christian Gmeiner > Signed-off-by: Russell King > Signed-off-by: Lucas Stach Lucas, I know that the previous round, people said that they didn't like the individual patches posted, but squashing everything together into one patch is also not good. It would make more sense (at least for me) if you squashed the work that has already been done into one patch, and then post your updates as individual patches. That way, Christian and myself can see what the changes are against some known without having to dig through your git tree, and those who complained about all the patches last time have fewer patches to look at. Expecting those in the project to page through thousands of lines that they already know about, hoping to spot the changes you've made is really very unreasonable and error prone. I will _NOT_ be wasting my time reviewing this mega-patch exactly because of that. I _might_, if I get time, pull a copy of your git tree to look at the individual patches, but I'm not going to reply quoting bits of this patch - I may reply with comments but without any context. Sorry. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH RFCv2 3/4] staging: etnaviv: add drm driver
On Mon, Sep 14, 2015 at 09:16:01AM -0400, Rob Clark wrote: > On Fri, Sep 11, 2015 at 10:10 AM, Lucas Stach > wrote: > > From: Christian Gmeiner > > > > This is a squashed commit of the complete etnaviv DRM driver in order > > to make it easy for people to review the code by seeing the driver as a > > whole and is not intended for merging in this form. > > > > If you are interested in the history of individual commits: > > git://git.pengutronix.de/git/lst/linux.git etnaviv-for-upstream > > > > Signed-off-by: Christian Gmeiner > > Signed-off-by: Russell King > > Signed-off-by: Lucas Stach > > --- > > drivers/staging/Kconfig |2 + > > drivers/staging/Makefile |1 + > > drivers/staging/etnaviv/Kconfig | 20 + > > drivers/staging/etnaviv/Makefile | 18 + > > drivers/staging/etnaviv/cmdstream.xml.h | 218 > > drivers/staging/etnaviv/common.xml.h | 249 + > > drivers/staging/etnaviv/etnaviv_buffer.c | 271 + > > drivers/staging/etnaviv/etnaviv_cmd_parser.c | 119 +++ > > drivers/staging/etnaviv/etnaviv_drv.c| 705 + > > drivers/staging/etnaviv/etnaviv_drv.h| 138 +++ > > drivers/staging/etnaviv/etnaviv_gem.c| 887 > > drivers/staging/etnaviv/etnaviv_gem.h| 141 +++ > > drivers/staging/etnaviv/etnaviv_gem_prime.c | 121 +++ > > drivers/staging/etnaviv/etnaviv_gem_submit.c | 421 > > drivers/staging/etnaviv/etnaviv_gpu.c| 1468 > > ++ > > drivers/staging/etnaviv/etnaviv_gpu.h| 198 > > drivers/staging/etnaviv/etnaviv_iommu.c | 221 > > drivers/staging/etnaviv/etnaviv_iommu.h | 28 + > > drivers/staging/etnaviv/etnaviv_iommu_v2.c | 33 + > > drivers/staging/etnaviv/etnaviv_iommu_v2.h | 25 + > > drivers/staging/etnaviv/etnaviv_mmu.c| 282 + > > drivers/staging/etnaviv/etnaviv_mmu.h| 58 + > > drivers/staging/etnaviv/state.xml.h | 351 ++ > > drivers/staging/etnaviv/state_hi.xml.h | 407 +++ > > include/uapi/drm/etnaviv_drm.h | 215 > > 25 files changed, 6597 insertions(+) > > create mode 100644 drivers/staging/etnaviv/Kconfig > > create mode 100644 drivers/staging/etnaviv/Makefile > > create mode 100644 drivers/staging/etnaviv/cmdstream.xml.h > > create mode 100644 drivers/staging/etnaviv/common.xml.h > > create mode 100644 drivers/staging/etnaviv/etnaviv_buffer.c > > create mode 100644 drivers/staging/etnaviv/etnaviv_cmd_parser.c > > create mode 100644 drivers/staging/etnaviv/etnaviv_drv.c > > create mode 100644 drivers/staging/etnaviv/etnaviv_drv.h > > create mode 100644 drivers/staging/etnaviv/etnaviv_gem.c > > create mode 100644 drivers/staging/etnaviv/etnaviv_gem.h > > create mode 100644 drivers/staging/etnaviv/etnaviv_gem_prime.c > > create mode 100644 drivers/staging/etnaviv/etnaviv_gem_submit.c > > create mode 100644 drivers/staging/etnaviv/etnaviv_gpu.c > > create mode 100644 drivers/staging/etnaviv/etnaviv_gpu.h > > create mode 100644 drivers/staging/etnaviv/etnaviv_iommu.c > > create mode 100644 drivers/staging/etnaviv/etnaviv_iommu.h > > create mode 100644 drivers/staging/etnaviv/etnaviv_iommu_v2.c > > create mode 100644 drivers/staging/etnaviv/etnaviv_iommu_v2.h > > create mode 100644 drivers/staging/etnaviv/etnaviv_mmu.c > > create mode 100644 drivers/staging/etnaviv/etnaviv_mmu.h > > create mode 100644 drivers/staging/etnaviv/state.xml.h > > create mode 100644 drivers/staging/etnaviv/state_hi.xml.h > > create mode 100644 include/uapi/drm/etnaviv_drm.h > > > > diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig > > index 7f6cae5beb90..5446fe4859ce 100644 > > --- a/drivers/staging/Kconfig > > +++ b/drivers/staging/Kconfig > > @@ -112,4 +112,6 @@ source "drivers/staging/fsl-mc/Kconfig" > > > > source "drivers/staging/wilc1000/Kconfig" > > > > +source "drivers/staging/etnaviv/Kconfig" > > + > > endif # STAGING > > diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile > > index 347f6477aa3e..9fd3c06b6bfd 100644 > > --- a/drivers/staging/Makefile > > +++ b/drivers/staging/Makefile > > @@ -48,3 +48,4 @@ obj-$(CONFIG_COMMON_CLK_XLNX_CLKWZRD) += clocking-wizard/ > > obj-$(CONFIG_FB_TFT) += fbtft/ > > obj-$(CONFIG_FSL_MC_BUS) += fsl-mc/ > > obj-$(CONFIG_WILC1000) += wilc1000/ > > +obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/ > > diff --git a/drivers/staging/etnaviv/Kconfig > > b/drivers/staging/etnaviv/Kconfig > > new file mode 100644 > > index ..6f034eda914c > > --- /dev/null > > +++ b/drivers/staging/etnaviv/Kconfig > > @@ -0,0 +1,20 @@ > > + > > +config DRM_ETNAVIV > > + tristate "etnaviv DRM" > > + depends on DRM > > + select SHMEM > > + select TMPFS > > + select IOMMU_API > > + select IOMMU_SUPPORT > > + default y > > + help > > + DRM dr
[PATCH RFCv2 3/4] staging: etnaviv: add drm driver
On Wed, Sep 16, 2015 at 08:11:54AM +0200, Christian Gmeiner wrote: > Hi Lucas > > > 2015-09-11 16:10 GMT+02:00 Lucas Stach : > > From: Christian Gmeiner > > > > This is a squashed commit of the complete etnaviv DRM driver in order > > to make it easy for people to review the code by seeing the driver as a > > whole and is not intended for merging in this form. > > > > If you are interested in the history of individual commits: > > git://git.pengutronix.de/git/lst/linux.git etnaviv-for-upstream > > > > Signed-off-by: Christian Gmeiner > > Signed-off-by: Russell King > > Signed-off-by: Lucas Stach > > --- [ cut thousands of lines ] If there was some comments in this, I don't know where they are. Expecting people to read through thousands of lines to find where you've commented is unreasonable. Please trim appropriately, according to standard email etiquette. (it also helps to get this patch through mailing lists as it then won't hit the size filters, and moderators don't have to keep approving stuff.) Thanks. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH RFCv2 3/4] staging: etnaviv: add drm driver
Hi Lucas 2015-09-11 16:10 GMT+02:00 Lucas Stach : > From: Christian Gmeiner > > This is a squashed commit of the complete etnaviv DRM driver in order > to make it easy for people to review the code by seeing the driver as a > whole and is not intended for merging in this form. > > If you are interested in the history of individual commits: > git://git.pengutronix.de/git/lst/linux.git etnaviv-for-upstream > > Signed-off-by: Christian Gmeiner > Signed-off-by: Russell King > Signed-off-by: Lucas Stach > --- > drivers/staging/Kconfig |2 + > drivers/staging/Makefile |1 + > drivers/staging/etnaviv/Kconfig | 20 + > drivers/staging/etnaviv/Makefile | 18 + > drivers/staging/etnaviv/cmdstream.xml.h | 218 > drivers/staging/etnaviv/common.xml.h | 249 + > drivers/staging/etnaviv/etnaviv_buffer.c | 271 + > drivers/staging/etnaviv/etnaviv_cmd_parser.c | 119 +++ > drivers/staging/etnaviv/etnaviv_drv.c| 705 + > drivers/staging/etnaviv/etnaviv_drv.h| 138 +++ > drivers/staging/etnaviv/etnaviv_gem.c| 887 > drivers/staging/etnaviv/etnaviv_gem.h| 141 +++ > drivers/staging/etnaviv/etnaviv_gem_prime.c | 121 +++ > drivers/staging/etnaviv/etnaviv_gem_submit.c | 421 > drivers/staging/etnaviv/etnaviv_gpu.c| 1468 > ++ > drivers/staging/etnaviv/etnaviv_gpu.h| 198 > drivers/staging/etnaviv/etnaviv_iommu.c | 221 > drivers/staging/etnaviv/etnaviv_iommu.h | 28 + > drivers/staging/etnaviv/etnaviv_iommu_v2.c | 33 + > drivers/staging/etnaviv/etnaviv_iommu_v2.h | 25 + > drivers/staging/etnaviv/etnaviv_mmu.c| 282 + > drivers/staging/etnaviv/etnaviv_mmu.h| 58 + > drivers/staging/etnaviv/state.xml.h | 351 ++ > drivers/staging/etnaviv/state_hi.xml.h | 407 +++ > include/uapi/drm/etnaviv_drm.h | 215 > 25 files changed, 6597 insertions(+) > create mode 100644 drivers/staging/etnaviv/Kconfig > create mode 100644 drivers/staging/etnaviv/Makefile > create mode 100644 drivers/staging/etnaviv/cmdstream.xml.h > create mode 100644 drivers/staging/etnaviv/common.xml.h > create mode 100644 drivers/staging/etnaviv/etnaviv_buffer.c > create mode 100644 drivers/staging/etnaviv/etnaviv_cmd_parser.c > create mode 100644 drivers/staging/etnaviv/etnaviv_drv.c > create mode 100644 drivers/staging/etnaviv/etnaviv_drv.h > create mode 100644 drivers/staging/etnaviv/etnaviv_gem.c > create mode 100644 drivers/staging/etnaviv/etnaviv_gem.h > create mode 100644 drivers/staging/etnaviv/etnaviv_gem_prime.c > create mode 100644 drivers/staging/etnaviv/etnaviv_gem_submit.c > create mode 100644 drivers/staging/etnaviv/etnaviv_gpu.c > create mode 100644 drivers/staging/etnaviv/etnaviv_gpu.h > create mode 100644 drivers/staging/etnaviv/etnaviv_iommu.c > create mode 100644 drivers/staging/etnaviv/etnaviv_iommu.h > create mode 100644 drivers/staging/etnaviv/etnaviv_iommu_v2.c > create mode 100644 drivers/staging/etnaviv/etnaviv_iommu_v2.h > create mode 100644 drivers/staging/etnaviv/etnaviv_mmu.c > create mode 100644 drivers/staging/etnaviv/etnaviv_mmu.h > create mode 100644 drivers/staging/etnaviv/state.xml.h > create mode 100644 drivers/staging/etnaviv/state_hi.xml.h > create mode 100644 include/uapi/drm/etnaviv_drm.h > > diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig > index 7f6cae5beb90..5446fe4859ce 100644 > --- a/drivers/staging/Kconfig > +++ b/drivers/staging/Kconfig > @@ -112,4 +112,6 @@ source "drivers/staging/fsl-mc/Kconfig" > > source "drivers/staging/wilc1000/Kconfig" > > +source "drivers/staging/etnaviv/Kconfig" > + > endif # STAGING > diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile > index 347f6477aa3e..9fd3c06b6bfd 100644 > --- a/drivers/staging/Makefile > +++ b/drivers/staging/Makefile > @@ -48,3 +48,4 @@ obj-$(CONFIG_COMMON_CLK_XLNX_CLKWZRD) += clocking-wizard/ > obj-$(CONFIG_FB_TFT) += fbtft/ > obj-$(CONFIG_FSL_MC_BUS) += fsl-mc/ > obj-$(CONFIG_WILC1000) += wilc1000/ > +obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/ > diff --git a/drivers/staging/etnaviv/Kconfig b/drivers/staging/etnaviv/Kconfig > new file mode 100644 > index ..6f034eda914c > --- /dev/null > +++ b/drivers/staging/etnaviv/Kconfig > @@ -0,0 +1,20 @@ > + > +config DRM_ETNAVIV > + tristate "etnaviv DRM" > + depends on DRM > + select SHMEM > + select TMPFS > + select IOMMU_API > + select IOMMU_SUPPORT > + default y > + help > + DRM driver for Vivante GPUs. > + > +config DRM_ETNAVIV_REGISTER_LOGGING > + bool "etnaviv DRM register logging" > + depends on DRM_ETNAVIV > + default n > + help > + Compile in support for logging register reads/writes in a format > + that
[PULL] topic/drm-misc
On Mon, Sep 14, 2015 at 8:22 AM, Daniel Vetter wrote: > Hi Dave, > > -rc1 is out the door and here's my first pull request for drm-next. It's > all over: > - better atomic helpers for runtime pm drivers > - atomic fbdev David Herrmann just pointed out to me that atomic fbdev isn't actually in this pull. Just checked my mails and it looks like there's some small things pending for the kerneldoc. I'll do a separate pull for atomic fbdev when I'm back from xdc. -Daniel > - dp aux i2c STATUS_UPDATE handling (for short i2c replies from the sink) > - bunch of constify patches > - various polish all over > > There's a few atomic drivers who want the goodies in here (at least rcar > and i915). > > Cheers, Daniel > > > The following changes since commit 73bf1b7be7aab60d7c651402441dd0b0b4991098: > > Merge branch 'drm-next-4.3' of git://people.freedesktop.org/~agd5f/linux > into drm-next (2015-09-05 07:46:09 +1000) > > are available in the git repository at: > > git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-09-14 > > for you to fetch changes up to 216c59d65f99aa1ef1a92e1ae64f1f1c2590dddc: > > drm/atomic-helper: Don't skip plane disabling on active CRTC (2015-09-13 > 23:20:54 +0200) > > > Bob Paauwe (1): > dtrm/edid: Allow comma separated edid binaries. (v3) > > Daniel Vetter (8): > drm/atomic-helper: properly annotate functions in kerneldoc > drm/fb-helper: Use -errno return in restore_mode_unlocked > drm: Make drm_fb_unregister/remove accept NULL fb > drm/fb-helper: Add module option to disable fbdev emulation > drm/atomic: refuse changing CRTC for planes directly > drm/atomic-helper: Add option to update planes only on active crtc > drm/atomic-helper: Pimp docs with recommendations for rpm drivers > drm: Nuke drm_framebuffer->helper_private > > Danilo Cesar Lemes de Paula (1): > drm/doc: Fixing xml documentation warning > > David Herrmann (2): > drm: simplify drm_sysfs_destroy() via IS_ERR_OR_NULL() > drm: move drm_class into drm_sysfs.c > > Gustavo Padovan (1): > drm: WARN_ON if a modeset driver uses legacy suspend/resume helpers > > Laurent Pinchart (1): > drm/atomic-helper: Don't skip plane disabling on active CRTC > > Maarten Lankhorst (3): > drm/atomic: Make sure lock is held in trylock contexts. > drm/atomic: Make prepare_fb/cleanup_fb only take state, v3. > drm/core: Do not call drm_framebuffer_remove internally during teardown. > > Michel Thierry (1): > drm/mm: Do DRM_MM_CREATE_TOP adj_start calculation after color_adjust > > Rob Clark (1): > drm: cleanup modesetting ioctls, one param per line > > Thierry Reding (1): > drm/atomic-helper: Implement drm_atomic_helper_duplicate_state() > > Ville Syrjälä (11): > drm: Constify generic_edid_names[] > drm: Constify TV mode names > drm/i2c/ch7006: Constify ch7006_tv_norms[] and ch7006_modes[] > drm/dp: s/I2C_STATUS/I2C_WRITE_STATUS_UPDATE/ > drm/i915: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE > drm/radeon: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE > drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes > drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE requests > drm: Make some modes const when iterating through them > drm: Remove the 'mode' argument from drm_select_eld() > drm: Make drm_av_sync_delay() 'mode' argument const > > Documentation/kernel-parameters.txt | 15 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 +- > drivers/gpu/drm/drm_atomic.c| 25 > drivers/gpu/drm/drm_atomic_helper.c | 185 > > drivers/gpu/drm/drm_crtc.c | 18 ++- > drivers/gpu/drm/drm_dp_helper.c | 43 +- > drivers/gpu/drm/drm_drv.c | 8 +- > drivers/gpu/drm/drm_edid.c | 8 +- > drivers/gpu/drm/drm_edid_load.c | 43 -- > drivers/gpu/drm/drm_fb_helper.c | 48 +- > drivers/gpu/drm/drm_internal.h | 2 +- > drivers/gpu/drm/drm_mm.c| 6 +- > drivers/gpu/drm/drm_modeset_lock.c | 2 + > drivers/gpu/drm/drm_plane_helper.c | 6 +- > drivers/gpu/drm/drm_sysfs.c | 49 +++ > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > drivers/gpu/drm/i2c/ch7006_drv.c| 6 +- > drivers/gpu/drm/i2c/ch7006_mode.c | 26 ++-- > drivers/gpu/drm/i2c/ch7006_priv.h | 12 +- > drivers/gpu/drm/i915/intel_audio.c | 2 +- > drivers/gpu/drm/i915/intel_display.c| 9 +- > drivers/gpu/drm/i915/intel_dp.c | 1 + > drivers/gpu/drm/i915/intel_drv.h| 2 - > drivers/gpu/drm/i915/intel_tv.c
[ANNOUNCE] libdrm 2.4.65
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan Coopersmith (1): Include when needed before calling alloca Christian König (2): amdgpu: remove sequence mutex amdgpu: serialize drmPrimeFDToHandle Emil Velikov (20): drm: add interface to get drm devices on the system v3 Move -lm link flag to LIBADD vbltest: fix variable shadowing warning modetest: fix shadowing warnings intel: resolve shadowing warnings intel: error out on has_error in exec2 intel: introduce to_bo_gem() helper configure: enable -Wshadow when available amdgpu: remove unneeded -Wno-switch-enum flag modetest: annotate const data as such for good measure libkms: use static const for good measure radeon: cleanup bo/cs func tables freedreno: annotate the device/bo/pipe/ringbuffer funcs as const data tests/amdgpu: reference the correct variable for memcpy tests/amdgpu: annotate the uvd message templates as const data tests/amdgpu: annotate (most of) the vce templates as const data tests/amdgpu: ensure tests work by using c99 initializers nouveau: use designated initializers intel: ignore missing-field-initializers warnings configure: remove -Wno-missing-field-initializers Hyungwon Hwang (2): xf86drmMode: remove the trailing white spaces modetest: remove the trailing white spaces Jonathan Gray (1): amdgpu: use EINVAL instead of EBADMSG in amdgpu_bo_cpu_unmap() Jérôme Glisse (1): drm: Add -lm to libdrm ldflags to fix build failure. Mathias Tillman (1): drm: fix the usage after free Mauro Rossi (2): amdgpu: add Makefile.sources amdgpu: add Android build support Michel Dänzer (1): tests: Add -lm to LDADD for dristat RafaÅ SapaÅa (1): intel: Serialize drmPrimeFDToHandle with struct_mutex Rob Clark (4): freedreno: don't take ownership of the dmabuf fd on import drm: make individual drm_server_info fxns optional freedreno: add API to get drm fd from fd_device Bump version for release Thierry Reding (1): omap: Initialize DMA BUF file descriptor to -1 Tvrtko Ursulin (1): libdrm: Add framebuffer modifiers uapi Varad Gautam (5): freedreno: fix a bo cache segfault with imported bo's freedreno: fill bo->fd when importing freedreno: get bo size for imported dma-buf freedreno: use drmPrime wrappers to import/export prime bo's freedreno: serialize drmPrimeFDToHandle under table_lock monk.liu (1): amdgpu: fix missing deinit on vamgr_32 git tag: libdrm-2.4.65 http://dri.freedesktop.org/libdrm/libdrm-2.4.65.tar.bz2 MD5: de49916e5f8aef4eba55223c79709b05 libdrm-2.4.65.tar.bz2 SHA1: 74a6b2aa8c436e822e3ec5c52e463313c4e219d9 libdrm-2.4.65.tar.bz2 SHA256: 71960ac8bde7d710992b1bc8879935e8300a870c36bd06f22412d0447e3d96c4 libdrm-2.4.65.tar.bz2 PGP: http://dri.freedesktop.org/libdrm/libdrm-2.4.65.tar.bz2.sig http://dri.freedesktop.org/libdrm/libdrm-2.4.65.tar.gz MD5: de91d20c354ca46ebbc134b9e34faa9e libdrm-2.4.65.tar.gz SHA1: 0a6f2c6d4a47fce5c3b4f12cbda28a0d29b23271 libdrm-2.4.65.tar.gz SHA256: b4382d6018464ba5bece2d7a4b87eb0eba24d891ff2ba29549be9511bd231c2f libdrm-2.4.65.tar.gz PGP: http://dri.freedesktop.org/libdrm/libdrm-2.4.65.tar.gz.sig -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJV+WmPAAoJEBkcm5BVIrBF7BYQAL02s/D5E5T52CeYP8ShXnBb cGci9a+f8j+8YRHOeuYGWeiPgIYAKOt38Ix0D6glw3vIY56UxnDvpUcfuDLkEEPr gKvYojmaOJoMA1AdZaigkLX+zoeEJlMaDCyahRYh1c//cX0wTPmSyK6MnlWWouNY d9KJYHTSnsKils7MGXXW0XT/vn80988vJ6Mt2TwfT20WXqm5/oKzgYhgwIKpuOs0 Jcahk0+h0IfZKKf8ouKgV6o58Gv9/gj+pb4VDY81uU8k4Nqa+wImS8LMQQNu/bdL sQIDA+tItyW9MimpD9MYEV4AzbmOkm62CBG3+drWoP2VuvdH34F/hyG00KqG1O6o 9h+bOwfNQ0hkcnGlvBhKcAo9Q7ITnFYmFld1FTqQWY1ZVoi8V5qqkwP0BCVkBpQ/ nX0BsHBtUv1OlCMy+wHaPjJ9RVorVI1WTdis27CkdJ2uqyJ9SiK2SWp/93KNVAhC on0+2vG+jATJDa2wP0DSkaXK7GizmMHQZJ5zHGVBIYXODujeJjD+2nmRYz5C/mSl x/AcoPMXxxRLJxvSiWoCVG9F7HY/3iAVN+ak6jRUgkVRnUFOiZctSouHGp3lmuQA 7eAZ9TOsshknmpKDuQP8GDb4IJZWYwXngGgmD/C9A3wQ6O7KreyAmhtfy7OBz2r9 NZqwLbzuhMHD2T9fqA1+ =KRg/ -END PGP SIGNATURE-
[Bug 92005] Linux 4.2 DisplayPort MST deadlock?
https://bugs.freedesktop.org/show_bug.cgi?id=92005 --- Comment #3 from Adam J. Richter --- Created attachment 118306 --> https://bugs.freedesktop.org/attachment.cgi?id=118306&action=edit dmesg log of some apparent delays, but not the deadlock, from kernel booted with "drm.debug=6 loglevel=7" I have been asked to try attach a dmesg log of this problem with the kernel booted with a "drm.debug=6" kernel command line argument. The exact problem that produced this interesting stack trace is difficult to reproduce, but long waits when doing "xrandr --current" and other misbehavior happen frequently and I suspect may be related to this mutex contention. In this case, "xarndr" takes a long time to run, examination of /proc//stack shows that the X server seems to be usually requesting new EDID data via DisplayPort MST, and, in this particular instance, the end result was the one of the two screens connected to the DisplayPort MST hub is not showing any video (and "xrandr" does not seem to see its EDID information either). I apologize if this attachment is essentially spam for a bug that might be completely separate from the issue for which I opened this ticket. I am posting it just on the chance that it might be relevant (and also because it as close as I think I'll get today to fulfilling the request to get a drm.debug=6 dmesg log of the original problem. -- 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/20150916/61d2a9d6/attachment-0001.html>
[Bug 92005] Linux 4.2 DisplayPort MST deadlock?
https://bugs.freedesktop.org/show_bug.cgi?id=92005 Dave Airlie changed: What|Removed |Added Attachment #118304|0 |1 is obsolete|| --- Comment #2 from Dave Airlie --- Created attachment 118305 --> https://bugs.freedesktop.org/attachment.cgi?id=118305&action=edit cleanup ports better, and hotplug in a different place. actually this is a more comprehensive version. -- 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/20150916/94054042/attachment.html>
[Bug 92005] Linux 4.2 DisplayPort MST deadlock?
https://bugs.freedesktop.org/show_bug.cgi?id=92005 --- Comment #1 from Dave Airlie --- Created attachment 118304 --> https://bugs.freedesktop.org/attachment.cgi?id=118304&action=edit don't send hotplug for input ports. this might help, it'll at least decrease things. -- 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/20150916/d6cf5dbf/attachment.html>
