Hi Jan,
On 27 February 2015 at 22:27, Emil Velikov wrote:
> On 27/02/15 18:07, Jan Vesely wrote:
>> His series fixes most of the warnings my compiler spits out running
>> make distcheck.
>> Most of the changes do not change behaviour and those the do are in separate
>> patches.
> Nicely done Jan.
On 27 February 2015 at 18:07, Jan Vesely wrote:
> Signed-off-by: Jan Vesely
> ---
> tests/exynos/exynos_fimg2d_test.c | 3 +++
> tests/modeprint/modeprint.c | 1 +
> xf86drmMode.c | 2 +-
> 3 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/tests/exynos/ex
On 27 February 2015 at 18:07, Jan Vesely wrote:
> Signed-off-by: Jan Vesely
> ---
> tests/drmstat.c | 8
> tests/kmstest/main.c| 2 +-
> tests/modeprint/modeprint.c | 18 +-
> tests/proptest/proptest.c | 2 +-
> tests/radeon/radeon_ttm.c | 4 +
On 27 February 2015 at 18:07, Jan Vesely wrote:
> Signed-off-by: Jan Vesely
> ---
> tests/exynos/exynos_fimg2d_test.c | 4 +---
> xf86drm.c | 9 ++---
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
...
> @@ -333,7 +336,6 @@ static int drmOpenDevice(dev_t dev, in
Hey,
Op 13-03-15 om 07:27 schreef Alexandre Courbot:
> Add a flag allowing Nouveau to specify that an object should be coherent
> at allocation time. This is required for some class of objects like
> fences which are randomly-accessed by both the CPU and GPU. This flag
> instructs the kernel drive
- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/ce223df8/attachment.sig>
tly speaking these could still be used, despite never being part
> of the API. Although my vote (fwiw) would be to that we're safe.
This one is heavily used in the same file.
>
> Cheers,
> Emil
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/bc04f98c/attachment-0001.sig>
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/8cf0c582/attachment.sig>
On 2015ë
03ì 12ì¼ 13:36, Hyungwon Hwang wrote:
> Since commit 0f04cf8df0b20a97369cb634663fef0578cbf273 ("drm/exynos:
> fix wrong pipe calculation for crtc"), fimd_clear_channel() can be
> called when is_drm_iommu_supported() returns true. In this case,
> the kernel is going to be panicked beca
This change adds the support in mdp5 kms driver for single
and dual DSI. Dual DSI case depends on the framework API
and sequence change to support dual data path.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 4 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 11 +-
This change adds the DSI connector support in msm drm driver.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/Kconfig | 11 +
drivers/gpu/drm/msm/Makefile |4 +
drivers/gpu/drm/msm/dsi/dsi.c | 203
drivers/gpu/drm/msm/dsi/dsi.h | 115 ++
drivers/gpu/
This change is to add an interface to MDP for connector devices
setting split display information.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/msm_kms.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 3a78cb4..a9f17bd
Prepare for initial DSI implementation
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/dsi/dsi.xml.h | 418 ++
1 file changed, 376 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
index abf1bba..
DSI is supported by both mdp4 and mdp5. This patch series adds the common DSI
controller driver and also enable it in mdp5.
Hai Li (4):
drm/msm/dsi: Update generated DSI header file
drm/msm: Add split display interface
drm/msm: Initial add DSI connector support
drm/msm/mdp5: Enable DSI con
DSI core registers in DSI6G are compatible with the old versions.
The offsets are 4-byte shift down because of the addition of a
HW_VERSION register. This difference will be handled in source code.
DSI PHY registers are incompatible. This change adds a new domain
for 28nm PHY and PHY regulator, wh
On 2015ë
03ì 12ì¼ 13:36, Hyungwon Hwang wrote:
> Checking whether the iommu mapping allocated is not enough to determine
> whether iommu is supported properly or not. Even though there is mapping,
> the kernel is going to be panicked without the iommu being allocated.
> So this patch adds the
On 13.03.2015 18:11, Daniel Vetter wrote:
> On Thu, Mar 12, 2015 at 06:02:56PM +0900, Michel Dänzer wrote:
>> On 12.03.2015 06:14, Alex Deucher wrote:
>>> On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher
>>> wrote:
On Wed, Mar 11, 2015 at 2:21 PM, Christian König
wrote:
> On 11.03.2
On Fri, Mar 13, 2015 at 3:39 PM, Alexandre Courbot wrote:
> On Fri, Mar 13, 2015 at 3:36 PM, Ilia Mirkin wrote:
>> Doesn't this require a kernel version that has your other patch? What
>> happens when this runs on an older kernel? Does it get silently
>> ignored, or does it end up erroring out? I
From: Ville Syrjälä
When an i2c WRITE gets an i2c defer or short i2c ack reply, we are
supposed to switch the request from I2C_WRITE to I2C_WRITE_STATUS_UPDATE
when we continue to poll for the completion of the request.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 41
From: Ville Syrjälä
A address-only I2C_WRITE can't be replied with a short i2c ack, but I
suppose it could be replied with an i2c defer. So the code should be
prepared for an address-only I2C_WRITE_STATUS_UPDATE.
Cc: Thierry Reding
Cc: "Terje Bergström"
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
When we get an i2c defer or short ack for i2c-over-aux write we need
to switch to WRITE_STATUS_UPDATE to poll for the completion of the
original request.
Looks like radeon doesn't do anything special with the request type,
so hopefully just treating it the same as a i2c wri
From: Ville Syrjälä
When we get an i2c defer or short ack for i2c-over-aux write we need
to switch to WRITE_STATUS_UPDATE to poll for the completion of the
original request.
i915 doesn't try to interpret wht request type apart from separating
reads from writes, and so we should be able to trea
From: Ville Syrjälä
Rename the I2C_STATUS request to I2C_WRITE_STATUS_UPDATE to match the
spec.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/tegra/dpaux.c | 2 +-
include/drm/drm_dp_helper.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/
From: Ville Syrjälä
This series tries to implement support for short i2c-over-aux writes.
I did notice that my monitor (HP ZR24w) does support DDC/CI so I was
able to do some writes, but I only saw native defers instead of i2c
defers/short acks. So I've not actually been able to test this.
An
On Mon, Mar 09, 2015 at 08:10:06AM +0800, Zhigang Gong wrote:
> > -Original Message-
> > From: Beignet [mailto:beignet-bounces at lists.freedesktop.org] On Behalf Of
> > Jeff McGee
> > Sent: Saturday, March 7, 2015 2:44 AM
> > To: Zhigang Gong
> > Cc: daniel at ffwll.ch; intel-gfx at lists.
On Fri, Mar 13, 2015 at 09:51:57AM -0700, Jeff McGee wrote:
> On Fri, Mar 13, 2015 at 05:32:41PM +0100, Daniel Vetter wrote:
> > On Fri, Mar 13, 2015 at 05:09:46PM +0800, Zhigang Gong wrote:
> > > My only concern is about the following macros:
> > >
> > > > +#define LOCAL_I915_PARAM_SUBSLICE_TOTAL
Add a required display-timings node for the TFT LCD panel
the TFT LCD panel is WQVGA "480x272", and the bpp is 24.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
arch/arm/boot/dts/ls1021a-twr.dts | 26 ++
1 file changed, 26 insertions
Add DCU node, DCU is a display controller of Freescale
named 2D-ACE.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
arch/arm/boot/dts/ls1021a.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/
This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on Freescale SoCs.
2D-ACE is a Freescale display controller. It provide an hardware
cursor.
This is a simplified version, only a primary plane, a fb created for
fbdev, a crtc, a connector for TFT LCD panel, an en
On Fri, Mar 13, 2015 at 02:51:25PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> ../drivers/gpu/drm/drm_vm.c:405:6: warning: symbol 'drm_vm_open_locked' was
> not declared. Should it be static?
> ../drivers/gpu/drm/drm_vm.c:431:6: warning: symbol 'drm_vm_close_locke
On Fri, Mar 13, 2015 at 06:46:33PM +0900, Michel Dänzer wrote:
> On 13.03.2015 18:11, Daniel Vetter wrote:
> > On Thu, Mar 12, 2015 at 06:02:56PM +0900, Michel Dänzer wrote:
> >> On 12.03.2015 06:14, Alex Deucher wrote:
> >>> On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher
> >>> wrote:
> On
On Fri, Mar 13, 2015 at 05:09:46PM +0800, Zhigang Gong wrote:
> My only concern is about the following macros:
>
> > +#define LOCAL_I915_PARAM_SUBSLICE_TOTAL 33
> > +#define LOCAL_I915_PARAM_EU_TOTAL34
>
> How about to just use the definitons in the kernel header file?
> For an example:
My only concern is about the following macros:
> +#define LOCAL_I915_PARAM_SUBSLICE_TOTAL 33
> +#define LOCAL_I915_PARAM_EU_TOTAL34
How about to just use the definitons in the kernel header file?
For an example:
#include
#ifdef LOCAL_I915_PARAM_SUBSLICE_TOTAL
//Put all the code
On 03/13/2015 02:36 PM, Daniel Vetter wrote:
> On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
>>
>>
>> On 03/11/2015 08:47 PM, Daniel Vetter wrote:
>>> On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
On 03/10/2015 05:47 PM, Daniel Vetter wrote:
>
Up until now, we assume that eDP is tight to intf_0 and HDMI to
intf_3. This information shall actually come from the mdp5_cfg
module since it can change from one chip to another.
v2: rename macro to mdp5_cfg_intf_is_virtual() [pointed by Archit]
v3: add sanity check before writing in INTF_TIMING_
Some interfaces (WB, DSI Command Mode) need to be kicked off
through a START Signal. This signal needs to be sent at the right
time and requests in some cases to keep track of the pipeline
status (eg: whether pipeline registers are flushed AND output WB
buffers are ready, in case of WB interface).
DSI and WB interfaces need a more complex pipeline configuration
than the current mdp5_ctl_set_intf().
For example, memory output connections need to be selected for
WB. Interface mode (Video vs. Command modes) also need to be
configured for DSI.
This change takes care of configuring the whole pi
Prepare for pipeline operation mode configuration, in particular
for DSI and WB modes.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 68 -
1 file changed, 33 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp
WB and DSI support are in the pipe and will come out soon. Before that,
we need to prepare the MDP5 driver so we can support these connectors.
v2: rename macro to mdp5_cfg_intf_is_virtual() [pointed by Archit]
v3: add sanity check before writing in INTF_TIMING_ENGINE_EN registers
Note:
"drm/msm:
On Fri, Mar 13, 2015 at 3:36 PM, Ilia Mirkin wrote:
> Doesn't this require a kernel version that has your other patch? What
> happens when this runs on an older kernel? Does it get silently
> ignored, or does it end up erroring out? If it errors out, that's
> fine. Otherwise some sort of version c
Add a flag allowing Nouveau to specify that an object should be coherent
at allocation time. This is required for some class of objects like
fences which are randomly-accessed by both the CPU and GPU. This flag
instructs the kernel driver to make sure the object remains coherent
even on architectur
From: Beeresh Gopal
To avoid ambiguity rename register
FRAME_SIZE to SSTILE_FRAME_SIZE.
Signed-off-by: Beeresh Gopal
---
rnndb/mdp/mdp4.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rnndb/mdp/mdp4.xml b/rnndb/mdp/mdp4.xml
index 26d1deb..a84f530 100644
--- a/rnndb/mdp/
From: Beeresh Gopal
Using fb modifier flag, support NV12MT format in MDP4.
v2:
- rework the modifier's description [Daniel Vetter's comment]
- drop .set_mode_config() callback [Rob Clark's comment]
Signed-off-by: Beeresh Gopal
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp4/mdp
From: Beeresh Gopal
To avoid ambiguity rename FRAME_SIZE to
SSTILE_FRAME_SIZE
Signed-off-by: Beeresh Gopal
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h | 36 +
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
Resending a v2 on behalf of Beeresh with comments from Daniel and Rob
addressed.
Beeresh Gopal (2):
drm/msm: update generated headers
drm/msm/mdp4: Support NV12MT format in mdp4
drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h | 36 ---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_
From: Ville Syrjälä
../drivers/gpu/drm/drm_vm.c:405:6: warning: symbol 'drm_vm_open_locked' was not
declared. Should it be static?
../drivers/gpu/drm/drm_vm.c:431:6: warning: symbol 'drm_vm_close_locked' was
not declared. Should it be static?
../drivers/gpu/drm/drm_vm.c:681:5: warning: symbol
Hi,
> Hi,
>
> On 03/09/2015 06:41 PM, Stephane Viau wrote:
>> This change adds the hw configuration for msm8x16 chipsets in
>> mdp5_cfg module.
>>
>> Note that only one external display interface is present in this
>> configuration (DSI) but has not been enabled yet. It will be enabled
>> once drm
On Fri, 13 Mar 2015, Rob Clark wrote:
> hopefully someone else in China can suggest a good way of sending
> patches (I have no clue there)
An alternative is to subscribe with all email addresses you may be
sending patches (or messages) from, but disabling list mail delivery for
all but one addres
On Fri, Mar 13, 2015 at 12:36 PM, Daniel Vetter wrote:
> On Fri, Mar 13, 2015 at 06:46:33PM +0900, Michel Dänzer wrote:
>> On 13.03.2015 18:11, Daniel Vetter wrote:
>> > On Thu, Mar 12, 2015 at 06:02:56PM +0900, Michel Dänzer wrote:
>> >> On 12.03.2015 06:14, Alex Deucher wrote:
>> >>> On Wed, M
This statement is indented an extra space.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 959058f..028c6d4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3905,13 +3905,13 @@ static void gen
Dave Airlie schreef op vr 06-03-2015 om 21:52 [+]:
> Thierry Reding (1):
> drm/mm: Support 4 GiB and larger ranges
Yesterday the screen on my (outdated) ThinkPad X41 went, well, black
while it was busy compiling something unattended. I eventually had to
power cycle that laptop to regain
On Thursday 12 March 2015 10:23:40 John Stultz wrote:
> Convert the timestamping in the amdkfd driver to use
> a timespec64 and 64bit time accessors.
>
> Cc: Arnd Bergmann
> Cc: Oded Gabbay
> Cc: David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: John Stultz
>
The patch l
On 03/13/2015 03:23 AM, Michel Dänzer wrote:
> The commits from
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=f957063fee6392bb9365370db6db74dc0b2dce0a
> to
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=cffefd9bb31cd35ab745d3b49005d10616d25bdc
> and
> htt
On 12.03.2015 22:09, Alex Deucher wrote:
> On Thu, Mar 12, 2015 at 5:23 AM, Christian König
> wrote:
>> On 12.03.2015 10:02, Michel Dänzer wrote:
>>>
>>> On 12.03.2015 06:14, Alex Deucher wrote:
On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher
wrote:
>
> On Wed, Mar 11, 2015
On 03/11/2015 08:47 PM, Daniel Vetter wrote:
> On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
>>
>>
>> On 03/10/2015 05:47 PM, Daniel Vetter wrote:
>>> On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
On 03/10/2015 03:35 PM, Daniel Vetter wrote:
> On Tue, Ma
On Fri, 13 Mar 2015, Daniel Vetter wrote:
> #if defined(CONFIG_FB)
> #include
> #else
Side note, #if IS_ENABLED(CONFIG_FB)
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On 2015ë
03ì 13ì¼ 03:45, Gustavo Padovan wrote:
> 2015-03-12 Inki Dae :
>
>> On 2015ë
02ì 19ì¼ 22:22, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> Hi,
>>>
>>> Here goes some clean ups to the exynos drivers. The main clean ups is
>>> the presetting and zpos making the propert
the description
> >> bodies fixes from your patch are still applicable. In the current
> >> form, the patch does not apply against drm-next (or latest linux
> >> master), but most of it is still applicable and would be a very
> >> welcome improvement.
> >>
> >> Thanks :-)
> >>
> >> BR,
> >> -R
> >>
>
--
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science &Technology
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/d9f4d797/attachment.html>
On 13.03.2015 08:23, Carsten Emde wrote:
> (About 30 OSADL QA Farm systems are now running 3.18.9-rt4. BTW: To
> check out what kernels are under test you may sort the kernel list
> (https://www.osadl.org/?id=933) by kernel version
> (https://www.osadl.org/?id=1001) and scroll down the page.)
>
>
rty *property,
> > {
> > if (property->flags & DRM_MODE_PROP_IMMUTABLE)
> > return false;
> > +
> > if (property->flags & DRM_MODE_PROP_RANGE) {
> > if (value < property->values[0] || value >
> property->values[1])
> > return false;
> > @@ -3194,6 +3188,7 @@ static bool drm_property_change_is_valid(struct
> drm_property *property,
> > } else if (property->flags & DRM_MODE_PROP_BITMASK) {
> > int i;
> > uint64_t valid_mask = 0;
> > +
> > for (i = 0; i < property->num_values; i++)
> > valid_mask |= (1ULL << property->values[i]);
> > return !(value & ~valid_mask);
> > @@ -3326,6 +3321,7 @@ int drm_mode_obj_get_properties_ioctl(struct
> drm_device *dev, void *data,
> > }
> > }
> > arg->count_props = props_count;
> > +
> > out:
> > mutex_unlock(&dev->mode_config.mutex);
> > return ret;
> > @@ -3487,7 +3483,6 @@ int drm_mode_gamma_set_ioctl(struct drm_device
> *dev,
> > out:
> > mutex_unlock(&dev->mode_config.mutex);
> > return ret;
> > -
> > }
> >
> > int drm_mode_gamma_get_ioctl(struct drm_device *dev,
> > @@ -3535,6 +3530,7 @@ int drm_mode_gamma_get_ioctl(struct drm_device
> *dev,
> > ret = -EFAULT;
> > goto out;
> > }
> > +
> > out:
> > mutex_unlock(&dev->mode_config.mutex);
> > return ret;
> > @@ -3668,6 +3664,7 @@ int drm_mode_create_dumb_ioctl(struct drm_device
> *dev,
> >
> > if (!dev->driver->dumb_create)
> > return -ENOSYS;
> > +
> > return dev->driver->dumb_create(file_priv, dev, args);
> > }
> >
> > --
> > 1.9.1
> >
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science &Technology
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/f80e2494/attachment-0001.html>
On Wed, Mar 11, 2015 at 10:13:50PM -0500, Scott Wood wrote:
> Use %pS for actual addresses, otherwise you'll get bad output
> on arches like ppc64 where %pF expects a function descriptor.
>
> Signed-off-by: Scott Wood
> Cc: dri-devel at lists.freedesktop.org
Applied to drm-misc, thanks.
-Daniel
On Thu, Mar 12, 2015 at 06:02:56PM +0900, Michel Dänzer wrote:
> On 12.03.2015 06:14, Alex Deucher wrote:
> > On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher
> > wrote:
> >> On Wed, Mar 11, 2015 at 2:21 PM, Christian König
> >> wrote:
> >>> On 11.03.2015 16:44, Alex Deucher wrote:
>
>
On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
>
>
> On 03/11/2015 08:47 PM, Daniel Vetter wrote:
> >On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
> >>
> >>
> >>On 03/10/2015 05:47 PM, Daniel Vetter wrote:
> >>>On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Tane
Am Donnerstag, den 12.03.2015, 18:53 +0100 schrieb Emil Renner Berthing:
> Hi Philipp
>
> On 12 March 2015 at 10:58, Philipp Zabel wrote:
> > Currently the imx-drm driver misuses the V4L2_PIX_FMT constants to describe
> > the
> > pixel format on the parallel bus between display controllers and e
On Fri, Mar 13, 2015 at 05:59:13PM +0100, Daniel Vetter wrote:
> On Fri, Mar 13, 2015 at 09:51:57AM -0700, Jeff McGee wrote:
> > On Fri, Mar 13, 2015 at 05:32:41PM +0100, Daniel Vetter wrote:
> > > On Fri, Mar 13, 2015 at 05:09:46PM +0800, Zhigang Gong wrote:
> > > > My only concern is about the fo
On Thu, Mar 12, 2015 at 05:26:25PM -0700, jeff.mcgee at intel.com wrote:
> From: Jeff McGee
>
> New test core_getparams consists of 2 subtests, each one testing
> the ability of userspace to query the correct value of a GT config
> attribute: subslice total or EU total. drm/i915 implementation of
On Fri, Mar 13, 2015 at 05:32:41PM +0100, Daniel Vetter wrote:
> On Fri, Mar 13, 2015 at 05:09:46PM +0800, Zhigang Gong wrote:
> > My only concern is about the following macros:
> >
> > > +#define LOCAL_I915_PARAM_SUBSLICE_TOTAL 33
> > > +#define LOCAL_I915_PARAM_EU_TOTAL34
> >
> > How a
Hi Daniel,
> On Fri, Feb 20, 2015 at 3:42 PM, Beeresh Gopal
> wrote:
>> +/* Samsung framebuffer modifiers */
>> +
>> +/*
>> + * NV12 64x32 Tiled
>> + *
>> + * 2 planes Y and CbCr, grouped into 64x32 macro tiles,
>> + * with a non-standard order in memory (Z-shape).
>> + *
>> + * Pixel layout iden
> >> return ret;
> >> @@ -2790,6 +2781,7 @@ struct drm_property *drm_property_create(struct
> >> drm_device *dev, int flags,
> >>
> >> list_add_tail(&property->head, &dev->mode_config.property_list);
> >> return property;
> >> +
> >> fail:
> >> kfree(property->values);
> >> kfree(property);
> >> @@ -3078,6 +3070,7 @@ int drm_mode_getproperty_ioctl(struct drm_device
> >> *dev,
> >> }
> >> out_resp->count_enum_blobs = blob_count;
> >> }
> >> +
> >> done:
> >> mutex_unlock(&dev->mode_config.mutex);
> >> return ret;
> >> @@ -3187,6 +3180,7 @@ static bool drm_property_change_is_valid(struct
> >> drm_property *property,
> >> {
> >> if (property->flags & DRM_MODE_PROP_IMMUTABLE)
> >> return false;
> >> +
> >> if (property->flags & DRM_MODE_PROP_RANGE) {
> >> if (value < property->values[0] || value >
> >> property->values[1])
> >> return false;
> >> @@ -3194,6 +3188,7 @@ static bool drm_property_change_is_valid(struct
> >> drm_property *property,
> >> } else if (property->flags & DRM_MODE_PROP_BITMASK) {
> >> int i;
> >> uint64_t valid_mask = 0;
> >> +
> >> for (i = 0; i < property->num_values; i++)
> >> valid_mask |= (1ULL << property->values[i]);
> >> return !(value & ~valid_mask);
> >> @@ -3326,6 +3321,7 @@ int drm_mode_obj_get_properties_ioctl(struct
> >> drm_device *dev, void *data,
> >> }
> >> }
> >> arg->count_props = props_count;
> >> +
> >> out:
> >> mutex_unlock(&dev->mode_config.mutex);
> >> return ret;
> >> @@ -3487,7 +3483,6 @@ int drm_mode_gamma_set_ioctl(struct drm_device
> *dev,
> >> out:
> >> mutex_unlock(&dev->mode_config.mutex);
> >> return ret;
> >> -
> >> }
> >>
> >> int drm_mode_gamma_get_ioctl(struct drm_device *dev,
> >> @@ -3535,6 +3530,7 @@ int drm_mode_gamma_get_ioctl(struct drm_device
> *dev,
> >> ret = -EFAULT;
> >> goto out;
> >> }
> >> +
> >> out:
> >> mutex_unlock(&dev->mode_config.mutex);
> >> return ret;
> >> @@ -3668,6 +3664,7 @@ int drm_mode_create_dumb_ioctl(struct drm_device
> >> *dev,
> >>
> >> if (!dev->driver->dumb_create)
> >> return -ENOSYS;
> >> +
> >> return dev->driver->dumb_create(file_priv, dev, args);
> >> }
> >>
> >> --
> >> 1.9.1
> >>
> >>
> >
> >
> >
> > --
> > Best regards
> > Junwang Zhao
> > Microprocessor Research and Develop Center
> > Department of Computer Science &Technology
> > Peking University
> > Beijing, 100871, PRC
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
>
--
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science &Technology
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/c760248e/attachment-0001.html>
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/20150313/3bd2b77d/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/fe361701/attachment-0001.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/abc43c50/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/1968b56e/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/25a19142/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/dfe6d043/attachment.html>
l add some logs.
--
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/20150313/18e545a2/attachment.html>
Doesn't this require a kernel version that has your other patch? What
happens when this runs on an older kernel? Does it get silently
ignored, or does it end up erroring out? If it errors out, that's
fine. Otherwise some sort of version check should be put in, no?
On Fri, Mar 13, 2015 at 2:27 AM,
(About 30 OSADL QA Farm systems are now running 3.18.9-rt4. BTW: To
check out what kernels are under test you may sort the kernel list
(https://www.osadl.org/?id=933) by kernel version
(https://www.osadl.org/?id=1001) and scroll down the page.)
The most striking problem of kernel 3.18.9-rt4 aff
78 matches
Mail list logo
