u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150720/3107300d/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150720/763bd371/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150720/534c619a/attachment.html>
Hi,
The files
drivers/gpu/drm/nouveau/nv50_fbcon.c
drivers/gpu/drm/nouveau/nvc0_fbcon.c
drivers/video/fbdev/nvidia/nv_accel.c
all contain a right-shift of ~0 (aka -1) - just grep for '~0 >>'. gcc
always does arithmetic right shift of signed types, which means that the
result is always -1 a
I think you're right. The intent is to mask off the bits above
bits_per_pixel. So if bits_per_pixel is 24, the mask would be
0xff00. If it's 16, then the mask would be 0x. If it's 32,
then the mask is 0.
In reality, bits_per_pixel is almost exclusively 32, which will end up
with a mask
From: Zhao Junwang
-register driver's own primary plane
-use drm_crtc_init_with_planes instead of drm_crtc_init
-split ->mode_set into:
1. set the new hw mode
2. update the primary plane (This is done by ->set_base)
-move what ->set_base do into ->atomic_update
-the new atomic i
ause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150720/3e9563f0/attachment.html>
While creating the debugfs file we are setting the inode->i_private to
dev. That same dev is passed to these functions as private of struct
seq_file via single_open(). So at this point it can never be NULL.
Signed-off-by: Sudip Mukherjee
---
v1 was drm/i915: fix possible null pointer dereference
seriously, don't you think?
--
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/20150720/30e615f5/attachment.html>
From: Thierry Reding
Allow connector names to be used in the specification of the -s option.
This requires storing the string passed on the command-line so that it
can later be resolved to a connector ID (after the DRM device has been
opened).
Connector names are constructed from the connector t
Linux driver?
--
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/20150720/0252a98d/attachment.html>
On Mon, Jul 20, 2015 at 01:38:46PM +0100, Chris Wilson wrote:
> On Mon, Jul 20, 2015 at 05:59:29PM +0530, Sudip Mukherjee wrote:
> > We were dereferencing dev first and then checking if it is NULL. Lets
> > check for NULL first and then dereference.
>
> The code is bonkers. Testing for a lack of a
=fbfd3bc7dfd7efcad2d2e52bf634f84c80a77a35
--
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/20150720/699c4cea/attachment.html>
Hi Mikko,
On 20 July 2015 at 08:54, Mikko Perttunen wrote:
> This adds device tree binding documentation for the Video Image
> Compositor (VIC) present on Tegra124 and newer SoC's.
>
> Signed-off-by: Mikko Perttunen
> ---
> .../devicetree/bindings/gpu/nvidia,tegra20-host1x.txt | 15
> +
We were dereferencing dev first and then checking if it is NULL. Lets
check for NULL first and then dereference.
Signed-off-by: Sudip Mukherjee
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/dri
Hi Alexander,
Thank you for your review.
On Mon, Jul 20, 2015 at 3:18 PM, Alexander Stein
wrote:
> On Friday 17 July 2015 18:38:59, Jianwei Wang wrote:
>> [...]
>> +static const struct regmap_config fsl_dcu_regmap_config = {
>> + .reg_bits = 32,
>> + .reg_stride = 4,
>> + .val_bits =
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150720/4515ad2c/attachment.html>
Add a 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
Reviewed-by: Alison Wang
---
arch/arm/boot/dts/ls1021a-twr.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm
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
Reviewed-by: Alison Wang
---
arch/arm/boot/dts/ls1021a.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/ls1
This adds support for the NEC NL4827HC19-05B 480x272 panel to the DRM
simple panel driver.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
Acked-by: Daniel Vetter
---
.../bindings/panel/nec,nl4827hc19_05b.txt | 7 ++
MAINTAINERS
NEC represent NEC LCD Technologies, Ltd.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documen
This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on the Freescale SoCs.
2D-ACE is a Freescale display controller. 2D-ACE describes
the functionality of the module extremely well its name is a value
that cannot be used as a token in programming languages.
Instead
On Mon, Jul 20, 2015 at 08:36:01PM +0530, Sudip Mukherjee wrote:
> While creating the debugfs file we are setting the inode->i_private to
> dev. That same dev is passed to these functions as private of struct
> seq_file via single_open(). So at this point it can never be NULL.
>
> Signed-off-by: S
On 20 July 2015 at 17:15, Jonathan Gray wrote:
> On Mon, Jul 20, 2015 at 05:06:09PM +0100, Emil Velikov wrote:
>> On 18 July 2015 at 22:20, Jonathan Gray wrote:
>> > As far as I can tell no OpenBSD platform ever used 81
>> > for a drm major. While the value was added to libdrm in 2003
>> > or ea
On 20 July 2015 at 06:36, Joonyoung Shim wrote:
> The vbltest doesn't have any dependency of LIBUDEV.
>
> Signed-off-by: Joonyoung Shim
Nicely spotted. I'll push this in a couple of hours.
Reviewed-by: Emil Velikov
-Emil
On 18 July 2015 at 22:20, Jonathan Gray wrote:
> This is implemented with kms ioctls so it could also be used as a
> generic fallback.
>
> Signed-off-by: Jonathan Gray
> ---
> xf86drmMode.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/xf86drmMode.c
Hi Jonathan,
On 18 July 2015 at 22:20, Jonathan Gray wrote:
> Add defines for the device minor names and make use of them
> in drmGetMinorName() so the correct paths will be used on OpenBSD.
>
> Signed-off-by: Jonathan Gray
> ---
> xf86drm.c | 6 +++---
> xf86drm.h | 15 +++
> 2 fi
On 18 July 2015 at 22:20, Jonathan Gray wrote:
> As far as I can tell no OpenBSD platform ever used 81
> for a drm major. While the value was added to libdrm in 2003
> or earlier drm didn't appear in OpenBSD till 2007.
>
> Of the OpenBSD platforms that support drm amd64/macppc/sparc64
> use a maj
On Wed, Jul 15, 2015 at 06:39:35PM +0530, Kausal Malladi wrote:
> CHV/BSW platform supports various Gamma correction modes, which are:
> 1. Legacy 8-bit mode
> 2. 10-bit CGM (Color Gamut Mapping) mode
>
> This patch does the following:
> 1. Adds the core function to program Gamma correction values
On Wed, Jul 15, 2015 at 06:39:34PM +0530, Kausal Malladi wrote:
> This patch adds set_property handler for Gamma color correction and
> enhancement capability at Pipe level on CHV/BSW platform. The set
> function just attaches the Gamma blob to CRTC state, that later gets
> committed using atomic p
On Wed, Jul 15, 2015 at 06:39:31PM +0530, Kausal Malladi wrote:
> This patch adds atomic set property interface for Intel CRTC. This
> interface will be used to set color correction DRM properties.
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
I think we also need .get_prop
On Wed, Jul 15, 2015 at 06:39:30PM +0530, Kausal Malladi wrote:
> As per Color Manager design, each driver is responsible to load its
> palette color correction and enhancement capabilities in the form of
> a DRM blob property, so that user space can query and read.
>
> This patch loads all CHV pl
On Wed, Jul 15, 2015 at 06:39:27PM +0530, Kausal Malladi wrote:
> This patch does the following:
> 1. Adds new files intel_color_manager(.c/.h)
> 2. Attaches color properties to CRTC while initialization
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
I'd suggest moving this
On Mon, Jul 20, 2015 at 06:58:32PM +0530, Sudip Mukherjee wrote:
> On Mon, Jul 20, 2015 at 01:38:46PM +0100, Chris Wilson wrote:
> > On Mon, Jul 20, 2015 at 05:59:29PM +0530, Sudip Mukherjee wrote:
> > > We were dereferencing dev first and then checking if it is NULL. Lets
> > > check for NULL firs
On Mon, Jul 20, 2015 at 12:35:48PM +0300, Pekka Paalanen wrote:
> On Mon, 20 Jul 2015 01:58:33 -0700
> Stéphane Marchesin wrote:
>
> > On Mon, Jul 20, 2015 at 12:46 AM, Pekka Paalanen
> > wrote:
> > > On Sun, 19 Jul 2015 17:20:32 -0700
> > > Stéphane Marchesin wrote:
> > >
> > >> On Thu, Jul
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150720/da41875e/attachment.html>
The vbltest doesn't have any dependency of LIBUDEV.
Signed-off-by: Joonyoung Shim
---
tests/Makefile.am | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 069285f..c5edec8 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150720/0e4387b0/attachment.html>
On Mon, Jul 20, 2015 at 05:59:29PM +0530, Sudip Mukherjee wrote:
> We were dereferencing dev first and then checking if it is NULL. Lets
> check for NULL first and then dereference.
The code is bonkers. Testing for a lack of a correctly constructed
debugfs seq_file inside the debugfs seq_file call
On Mon, 20 Jul 2015 01:58:33 -0700
Stéphane Marchesin wrote:
> On Mon, Jul 20, 2015 at 12:46 AM, Pekka Paalanen
> wrote:
> > On Sun, 19 Jul 2015 17:20:32 -0700
> > Stéphane Marchesin wrote:
> >
> >> On Thu, Jul 16, 2015 at 11:08 PM, Pekka Paalanen
> >> wrote:
> >> >
> >> > On Thu, 16 Jul 2
is? If runtime PM isn't enabled we
don't care very much about power management anyway. So in my opinion if
a driver supports runtime PM it should support it all the way and not
pretend to. Having this mix of runtime PM vs. no runtime PM is beside
the point of using something like runtime PM in the first place.
So if this is about supporting legacy vs. runtime PM, then I think it
should be based on some more explicit check, like if (!dev->pm_domain),
but otherwise we should assume that pm_runtime_enable() succeeds.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150720/314568c1/attachment.sig>
On 07/20/2015 11:28 AM, Jon Hunter wrote:
> Hi Mikko,
Hi!
> ...
>> +static int vic_runtime_resume(struct device *dev)
>> +{
>> +struct vic *vic = dev_get_drvdata(dev);
>> +int err;
>> +
>> +err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_VIC,
>> +
lue = tegra_dpaux_readl(dpaux, DPAUX_DP_AUXDATA_READ(i));
> >
> > for (j = 0; j < num; j++)
> > - buffer[i + j] = value >> (j * 8);
> > + buffer[i * 4 + j] = value >> (j * 8);
> > }
> > }
> >
> > --
> > 2.4.5
> >
> >
>
> This fixes the issue that I reported earlier, so feel free to add my
>
> Tested-by: Steev Klimaszewski
Great, thanks.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150720/b61a4ff3/attachment.sig>
gt; +
> > +static int vic_probe(struct platform_device *pdev)
> > +{
> > + struct vic_config *vic_config = NULL;
> > + struct device *dev = &pdev->dev;
> > + struct host1x_syncpt **syncpts;
> > + struct resource *regs;
> > + const struct of_device_id *match;
> > + struct vic *vic;
> > + int err;
> > +
> > + match = of_match_device(vic_match, dev);
> > + vic_config = (struct vic_config *)match->data;
> > +
> > + vic = devm_kzalloc(dev, sizeof(*vic), GFP_KERNEL);
> > + if (!vic)
> > + return -ENOMEM;
> > +
> > + syncpts = devm_kzalloc(dev, sizeof(*syncpts), GFP_KERNEL);
> > + if (!syncpts)
> > + return -ENOMEM;
> > +
> > + regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!regs) {
> > + dev_err(&pdev->dev, "failed to get registers\n");
> > + return -ENXIO;
> > + }
> > +
> > + vic->regs = devm_ioremap_resource(dev, regs);
> > + if (IS_ERR(vic->regs))
> > + return PTR_ERR(vic->regs);
> > +
> > + vic->clk = devm_clk_get(dev, NULL);
> > + if (IS_ERR(vic->clk)) {
> > + dev_err(&pdev->dev, "failed to get clock\n");
> > + return PTR_ERR(vic->clk);
> > + }
> > +
> > + vic->rst = devm_reset_control_get(dev, "vic");
> > + if (IS_ERR(vic->rst)) {
> > + dev_err(&pdev->dev, "cannot get reset\n");
> > + return PTR_ERR(vic->rst);
> > + }
> > +
> > + platform_set_drvdata(pdev, vic);
> > +
> > + INIT_LIST_HEAD(&vic->client.base.list);
> > + vic->client.base.ops = &vic_client_ops;
> > + vic->client.base.dev = dev;
> > + vic->client.base.class = HOST1X_CLASS_VIC;
> > + vic->client.base.syncpts = syncpts;
> > + vic->client.base.num_syncpts = 1;
> > + vic->dev = dev;
> > + vic->config = vic_config;
> > +
> > + INIT_LIST_HEAD(&vic->client.list);
> > + vic->client.ops = &vic_ops;
> > +
> > + err = host1x_client_register(&vic->client.base);
> > + if (err < 0) {
> > + dev_err(dev, "failed to register host1x client: %d\n", err);
> > + platform_set_drvdata(pdev, NULL);
> > + return err;
> > + }
> > +
> > + pm_runtime_enable(&pdev->dev);
> > + if (!pm_runtime_enabled(&pdev->dev)) {
> > + err = vic_runtime_resume(&pdev->dev);
> > + if (err < 0)
> > + goto unregister_client;
> > + }
>
> I don't see why pm_runtime_enable() should ever fail to enable
> pm_runtime here. Hence, the if-statement appears to be redundant. If you
> are trying to determine whether rpm is supported for the power-domains
> then you should simply check to see if the DT node for the device has
> the "power-domains" property. See my series [1].
Merely checking for a device tree property won't tell you anything.
There are no guarantees that some driver will make the power domains
available, even if they are defined in the DT.
Generally checking device tree properties is a bad idea. You should only
ever rely on whatever mechanism the operating system exposed as a result
of such properties instead.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150720/02d8fcc7/attachment-0001.sig>
Hi Dave,
This is amdkfd's pull request for kernel 4.3.
drm-amdkfd-next-2015-07-20:
- Add Carrizo support for amdkfd, using the new amdgpu driver as the relevant
kgd. The support includes interfaces with amdgpu both for gfx7 (Kaveri) and
gfx8 (Carrizo). However, gfx7 interface is used for deb
On 20/07/15 09:51, Mikko Perttunen wrote:
> On 07/20/2015 11:28 AM, Jon Hunter wrote:
>> Hi Mikko,
>
> Hi!
>
>> ...
>>> +static int vic_runtime_resume(struct device *dev)
>>> +{
>>> + struct vic *vic = dev_get_drvdata(dev);
>>> + int err;
>>> +
>>> + err = tegra_powergate_sequence_power_up
From: Arto Merilainen
This patch adds VIC device tree node for Video Image Compositor.
Signed-off-by: Arto Merilainen
Signed-off-by: Mikko Perttunen
---
arch/arm/boot/dts/tegra124.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm
This adds device tree binding documentation for the Video Image
Compositor (VIC) present on Tegra124 and newer SoC's.
Signed-off-by: Mikko Perttunen
---
.../devicetree/bindings/gpu/nvidia,tegra20-host1x.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/de
From: Arto Merilainen
This patch adds support for Video Image Compositor engine which
can be used for 2d operations.
Signed-off-by: Andrew Chew
Signed-off-by: Arto Merilainen
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/Makefile | 3 +-
drivers/gpu/drm/tegra/drm.c| 7 +
d
From: Arto Merilainen
Add a set of falcon helper routines for use by the tegradrm client drivers
of the various falcon-based engines.
The falcon is a microcontroller that acts as a frontend for the rest of a
particular Tegra engine. In order to properly utilize these engines, the
frontend must
>From Arto's original cover letter:
This series adds Video-Image-Compositor (VIC) support for Tegra124. The unit
replaced gr2d engine on T124 and it is effectively used for similar
operations: making simple surface copy and fill operations.
[..]
The series has been tested on Jetson TK1 by first
On Sun, 19 Jul 2015 17:20:32 -0700
Stéphane Marchesin wrote:
> On Thu, Jul 16, 2015 at 11:08 PM, Pekka Paalanen
> wrote:
> >
> > On Thu, 16 Jul 2015 20:20:39 +0800
> > John Hunter wrote:
> >
> > > From: Zhao Junwang
> > >
> > > This supports the asynchronous commits, required for page-flippi
On Mon, Jul 20, 2015 at 7:21 AM, Daniel Vetter wrote:
> On Mon, Jul 20, 2015 at 12:35:48PM +0300, Pekka Paalanen wrote:
>> On Mon, 20 Jul 2015 01:58:33 -0700
>> Stéphane Marchesin wrote:
>>
>> > On Mon, Jul 20, 2015 at 12:46 AM, Pekka Paalanen
>> > wrote:
>> > > On Sun, 19 Jul 2015 17:20:32 -0
Hi Mikko,
On 20/07/15 08:54, Mikko Perttunen wrote:
> From: Arto Merilainen
>
> This patch adds support for Video Image Compositor engine which
> can be used for 2d operations.
>
> Signed-off-by: Andrew Chew
> Signed-off-by: Arto Merilainen
> Signed-off-by: Mikko Perttunen
> ---
> drivers/g
On Friday 17 July 2015 18:38:59, Jianwei Wang wrote:
> [...]
> +static const struct regmap_config fsl_dcu_regmap_config = {
> + .reg_bits = 32,
> + .reg_stride = 4,
> + .val_bits = 32,
> +};
This defaults to REGCACHE_NONE which in the end sets regmap.cache_only = true.
> [...]
> +#ifd
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150720/b274734a/attachment.html>
From: Thierry Reding
The DPAUX read/write FIFO registers aren't sequential in the register
space, causing transfers larger than 4 bytes to cause accesses to non-
existing FIFO registers.
Fixes: 6b6b604215c6 ("drm/tegra: Add eDP support")
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/
atomic_commit = drm_atomic_helper_commit,
> > + .atomic_commit = bochs_atomic_commit,
> > };
>
>
--
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/20150720/214528ef/attachment.html>
> for (j = 0; j < num; j++)
> - buffer[i + j] = value >> (j * 8);
> + buffer[i * 4 + j] = value >> (j * 8);
> }
> }
>
> --
> 2.4.5
>
>
This fixes the issue that I reported earlier, so feel free to add my
Tested-by: Steev Klimaszewski
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150720/be4f8a7b/attachment-0001.html>
On Mon, Jul 20, 2015 at 12:46 AM, Pekka Paalanen wrote:
> On Sun, 19 Jul 2015 17:20:32 -0700
> Stéphane Marchesin wrote:
>
>> On Thu, Jul 16, 2015 at 11:08 PM, Pekka Paalanen
>> wrote:
>> >
>> > On Thu, 16 Jul 2015 20:20:39 +0800
>> > John Hunter wrote:
>> >
>> > > From: Zhao Junwang
>> > >
60 matches
Mail list logo
