re: drm/radeon: add audio support for DCE6/8 GPUs (v12)
Hello Alex Deucher, This is a semi-automatic email about new static checker warnings. The patch b530602fd462: "drm/radeon: add audio support for DCE6/8 GPUs (v12)" from Jul 31, 2013, leads to the following Smatch complaint: drivers/gpu/drm/radeon/dce6_afmt.c:91 dce6_afmt_select_pin() warn: variable dereferenced before check 'dig->afmt->pin' (see line 89) drivers/gpu/drm/radeon/dce6_afmt.c 88 u32 offset = dig->afmt->offset; 89 u32 id = dig->afmt->pin->id; ^^ Patch adds dereference. 90 91 if (!dig->afmt->pin) ^^^ Patch adds check. 92 return; 93 regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm/tegra: Changes for v3.12-rc1
Hi Dave, The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b: Linux 3.11-rc2 (2013-07-21 12:05:29 -0700) are available in the git repository at: git://anongit.freedesktop.org/tegra/linux tags/drm/for-3.12-rc1 for you to fetch changes up to 03da0e7ba9e3a1fc700f60913ff6bcb19f7eac2a: drm/tegra: Parse device tree earlier (2013-09-03 10:10:13 +0200) Thanks, Thierry drm/tegra: Changes for v3.12-rc1 Only a couple of small patches this time around. These are mostly fixes for minor bugs that showed up, but there is also some preparatory work that will come in handy for future patches. Dan Carpenter (2): gpu: host1x: fix an integer overflow check gpu: host1x: returning success instead of -ENOMEM Mikko Perttunen (1): drm/tegra: hdmi: Make sure clock is enabled before dumping registers Thierry Reding (3): gpu: host1x: Check for valid host1x pointer gpu: host1x: Sort drivers by probe order drm/tegra: Parse device tree earlier drivers/gpu/host1x/dev.c | 2 +- drivers/gpu/host1x/dev.h | 2 +- drivers/gpu/host1x/drm/hdmi.c | 7 +++ drivers/gpu/host1x/drm/rgb.c | 14 +++--- drivers/gpu/host1x/job.c | 15 +++ 5 files changed, 23 insertions(+), 17 deletions(-) pgpCkyrZymwRT.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60827] X under radeon driver crashes after resuming from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=60827 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher --- Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60827] X under radeon driver crashes after resuming from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=60827 --- Comment #3 from Alex Deucher --- You might also try a newer kernel. It looks like the uvd ring that is failing to resume properly. There are a number of fixes for suspend/resume related problems with uvd in 3.11 (most of which should end up in stable). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote: > Op 28-08-13 08:29, Pasi Kärkkäinen schreef: > > On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote: > >> On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote: > >>> Op 22-08-13 02:10, Ilia Mirkin schreef: > The code expects non-VRAM mem nodes to have a pages list. If that's not > set, it will do a null deref down the line. Warn on that condition and > return an error. > > See https://bugs.freedesktop.org/show_bug.cgi?id=64774 > > Reported-by: Pasi Kärkkäinen > Tested-by: Pasi Kärkkäinen > Signed-off-by: Ilia Mirkin > Cc: # 3.8+ > --- > > I don't exactly understand what's going on, but this is just a > straightforward way to avoid a null deref that you see happens in the > bug. I haven't figured out the root cause of this, but it's getting > well into the "I have no idea how TTM works" space. However this seems > like a bit of defensive programming -- nouveau_vm_map_sg will pass > node->pages as a list down, which will be dereferenced by > nvc0_vm_map_sg. Perhaps the other arguments should make that > dereferencing not happen, but it definitely was happening here, as you > can see in the bug. > > Ben/Maarten, I'll let you judge whether this check is appropriate, > since like I hope I was able to convey above, I'm just not really sure :) > >>> Not it really isn't appropriate.. > >>> > >>> You'd have to call call nouveau_vm_map_sg_table instead, the only place > >>> that doesn't handle that correctly > >>> is where it's not expected to be called. > >>> > >>> Here, have a completely untested patch to fix things... > >>> > >> Maarten: I've been testing this stuff with Linux 3.10.x, so I had to > >> modify the patch a bit to make it apply there.. > >> I've attached the modified copy that applies to 3.10.9, hopefully I did > >> the backport correctly. > >> > >> With Linux 3.10.9 and the patch applied the kernel doesn't crash anymore, > >> and I get this error in dmesg: > >> > >> [ 76.105643] nouveau W[ DRM] Trying to create a fb in vram with > >> valid_domains=0004 > >> > >> Does that help? > >> > > Any comments? > > > > Maarten's patch works for me, I get that warning instead of a kernel crash, > > but it's also a bigger change that doesn't apply to older kernels as-is. > > > > Ilia's original patch in this thread can be applied to older kernels as-is, > > and it also prevents the kernel crash from happening. > > > > Should we get both applied, so Ilia's patch can be CC'd to stable ? > > > You haven't understood the root cause then. You're trying to move an IMPORTED > dma-buf into VRAM. > Doing so would seem to work, but at that point it's no longer a dma-buf so > changes done by the exporter > would not show up in nouveau because they no longer refer to the same piece > of memory. > Yes, that's true, I don't understand the root cause. That's mostly because I'm not familiar with the nouveau code/internals. > Failing is the only right option here. > Sorry but I'm not sure I understand that correctly.. what exactly do you suggest? What should fail? Because I'm not familiar with the code (yet) understanding and finding the root cause will take time for me.. that's why I was suggesting to meanwhile apply Ilia's very simple patch from this thread which actually prevents the hard kernel crash from happening, because it seems like an unharmful fix to have to protect against this kind of bugs (the root cause) ? Or is that unacceptable? (To recap: The kernel crash happens very often when trying to use the nouveau adapter in Optimus mode, with all kernels at least 3.8+, and it's very annoying that your laptop crashes when trying to enable a nouveau output. So Ilia's patch doesn't make the driver working properly, but at least it prevents the hard kernel crash from happening. The crash bug is in many kernel versions, including the long-term v3.10 tree. I've had the crash happening with 3.8.x, 3.9.x and 3.10.x) All comments welcome. Thanks, -- Pasi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
Op 03-09-13 16:20, Pasi Kärkkäinen schreef: > On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote: >> Op 28-08-13 08:29, Pasi Kärkkäinen schreef: >>> On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote: On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote: > Op 22-08-13 02:10, Ilia Mirkin schreef: >> The code expects non-VRAM mem nodes to have a pages list. If that's not >> set, it will do a null deref down the line. Warn on that condition and >> return an error. >> >> See https://bugs.freedesktop.org/show_bug.cgi?id=64774 >> >> Reported-by: Pasi Kärkkäinen >> Tested-by: Pasi Kärkkäinen >> Signed-off-by: Ilia Mirkin >> Cc: # 3.8+ >> --- >> >> I don't exactly understand what's going on, but this is just a >> straightforward way to avoid a null deref that you see happens in the >> bug. I haven't figured out the root cause of this, but it's getting >> well into the "I have no idea how TTM works" space. However this seems >> like a bit of defensive programming -- nouveau_vm_map_sg will pass >> node->pages as a list down, which will be dereferenced by >> nvc0_vm_map_sg. Perhaps the other arguments should make that >> dereferencing not happen, but it definitely was happening here, as you >> can see in the bug. >> >> Ben/Maarten, I'll let you judge whether this check is appropriate, >> since like I hope I was able to convey above, I'm just not really sure :) > Not it really isn't appropriate.. > > You'd have to call call nouveau_vm_map_sg_table instead, the only place > that doesn't handle that correctly > is where it's not expected to be called. > > Here, have a completely untested patch to fix things... > Maarten: I've been testing this stuff with Linux 3.10.x, so I had to modify the patch a bit to make it apply there.. I've attached the modified copy that applies to 3.10.9, hopefully I did the backport correctly. With Linux 3.10.9 and the patch applied the kernel doesn't crash anymore, and I get this error in dmesg: [ 76.105643] nouveau W[ DRM] Trying to create a fb in vram with valid_domains=0004 Does that help? >>> Any comments? >>> >>> Maarten's patch works for me, I get that warning instead of a kernel crash, >>> but it's also a bigger change that doesn't apply to older kernels as-is. >>> >>> Ilia's original patch in this thread can be applied to older kernels as-is, >>> and it also prevents the kernel crash from happening. >>> >>> Should we get both applied, so Ilia's patch can be CC'd to stable ? >>> >> You haven't understood the root cause then. You're trying to move an >> IMPORTED dma-buf into VRAM. >> Doing so would seem to work, but at that point it's no longer a dma-buf so >> changes done by the exporter >> would not show up in nouveau because they no longer refer to the same piece >> of memory. >> > Yes, that's true, I don't understand the root cause. > That's mostly because I'm not familiar with the nouveau code/internals. > > >> Failing is the only right option here. >> > Sorry but I'm not sure I understand that correctly.. what exactly do you > suggest? What should fail? > > > Because I'm not familiar with the code (yet) understanding and finding the > root cause > will take time for me.. that's why I was suggesting to meanwhile apply Ilia's > very simple patch > from this thread which actually prevents the hard kernel crash from > happening, because it seems > like an unharmful fix to have to protect against this kind of bugs (the root > cause) ? > Or is that unacceptable? > > (To recap: The kernel crash happens very often when trying to use the nouveau > adapter in Optimus mode, with all kernels at least 3.8+, and it's very > annoying that your laptop crashes when trying to enable a nouveau output. So > Ilia's patch doesn't make the driver working properly, but at least it > prevents the hard kernel crash from happening. The crash bug is in many > kernel versions, including the long-term v3.10 tree. I've had the crash > happening with 3.8.x, 3.9.x and 3.10.x) The fix probably requires commit fdfb8332651db7a280851dfccfc4f0cff4bcd052 to apply cleanly "drm/nouveau: fix some error-path leaks in fbcon handling code" > All comments welcome. > > Thanks, > > -- Pasi > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/1] ARM: dts: AM33XX: Add LCDC info into am335x-evm
Hi,
I have not received any feedback on this patch.
It has been pending since the end of June (first post).
Can I get an estimate when it will be included/accepted?
Thanks,
Benoit
On Fri, Aug 23, 2013 at 11:13:56AM -0500, Benoit Parrot wrote:
> Add LCDC device node in DT for am33xx
> Add LCDC and Panel info in DT for am335x-evm
>
> Changes in v3:
> - rebase to 3.11-rc6
>
> Changes in v2:
> - remove redundant/unnecessary SoC specific setting in the board dts
>
> Signed-off-by: Benoit Parrot
> ---
> arch/arm/boot/dts/am335x-evm.dts | 72
> ++
> arch/arm/boot/dts/am33xx.dtsi|9 +
> 2 files changed, 81 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-evm.dts
> b/arch/arm/boot/dts/am335x-evm.dts
> index 3aee1a4..b0703f1 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -149,6 +149,40 @@
> 0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> >;
> };
> +
> + lcd_pins_s0: lcd_pins_s0 {
> + pinctrl-single,pins = <
> + 0x20 0x01 /* gpmc_ad8.lcd_data16, OUTPUT
> | MODE1 */
> + 0x24 0x01 /* gpmc_ad9.lcd_data17, OUTPUT
> | MODE1 */
> + 0x28 0x01 /* gpmc_ad10.lcd_data18, OUTPUT
> | MODE1 */
> + 0x2c 0x01 /* gpmc_ad11.lcd_data19, OUTPUT
> | MODE1 */
> + 0x30 0x01 /* gpmc_ad12.lcd_data20, OUTPUT
> | MODE1 */
> + 0x34 0x01 /* gpmc_ad13.lcd_data21, OUTPUT
> | MODE1 */
> + 0x38 0x01 /* gpmc_ad14.lcd_data22, OUTPUT
> | MODE1 */
> + 0x3c 0x01 /* gpmc_ad15.lcd_data23, OUTPUT
> | MODE1 */
> + 0xa0 0x00 /* lcd_data0.lcd_data0, OUTPUT
> | MODE0 */
> + 0xa4 0x00 /* lcd_data1.lcd_data1, OUTPUT
> | MODE0 */
> + 0xa8 0x00 /* lcd_data2.lcd_data2, OUTPUT
> | MODE0 */
> + 0xac 0x00 /* lcd_data3.lcd_data3, OUTPUT
> | MODE0 */
> + 0xb0 0x00 /* lcd_data4.lcd_data4, OUTPUT
> | MODE0 */
> + 0xb4 0x00 /* lcd_data5.lcd_data5, OUTPUT
> | MODE0 */
> + 0xb8 0x00 /* lcd_data6.lcd_data6, OUTPUT
> | MODE0 */
> + 0xbc 0x00 /* lcd_data7.lcd_data7, OUTPUT
> | MODE0 */
> + 0xc0 0x00 /* lcd_data8.lcd_data8, OUTPUT
> | MODE0 */
> + 0xc4 0x00 /* lcd_data9.lcd_data9, OUTPUT
> | MODE0 */
> + 0xc8 0x00 /* lcd_data10.lcd_data10,
> OUTPUT | MODE0 */
> + 0xcc 0x00 /* lcd_data11.lcd_data11,
> OUTPUT | MODE0 */
> + 0xd0 0x00 /* lcd_data12.lcd_data12,
> OUTPUT | MODE0 */
> + 0xd4 0x00 /* lcd_data13.lcd_data13,
> OUTPUT | MODE0 */
> + 0xd8 0x00 /* lcd_data14.lcd_data14,
> OUTPUT | MODE0 */
> + 0xdc 0x00 /* lcd_data15.lcd_data15,
> OUTPUT | MODE0 */
> + 0xe0 0x00 /* lcd_vsync.lcd_vsync, OUTPUT
> | MODE0 */
> + 0xe4 0x00 /* lcd_hsync.lcd_hsync, OUTPUT
> | MODE0 */
> + 0xe8 0x00 /* lcd_pclk.lcd_pclk, OUTPUT |
> MODE0 */
> + 0xec 0x00 /*
> lcd_ac_bias_en.lcd_ac_bias_en, OUTPUT | MODE0 */
> + >;
> + };
> +
> };
>
> ocp {
> @@ -311,6 +345,10 @@
> };
> };
> };
> +
> + lcdc: lcdc@4830e000 {
> + status = "okay";
> + };
> };
>
> vbat: fixedregulator@0 {
> @@ -374,6 +412,40 @@
> brightness-levels = <0 51 53 56 62 75 101 152 255>;
> default-brightness-level = <8>;
> };
> +
> + panel {
> + compatible = "ti,tilcdc,panel";
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pins_s0>;
> + panel-info {
> + ac-bias = <255>;
> + ac-bias-intrpt= <0>;
> + dma-burst-sz = <16>;
> + bpp = <32>;
> + fdd = <0x80>;
> + sync-edge = <0>;
> + sync-ctrl = <1>;
> + raster-order = <0>;
> + fifo-th = <0>;
> + };
> +
> + display-timings {
> + 800x480p62 {
> +
Re: [PATCH 4/7] drm/exynos: add support for exynos5420 hdmiphy
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Exynos5420 hdmiphy device is a platform device, unlike
> predecessor SoCs where it used to be a I2C device. This
> support is added to the hdmiphy driver.
>
Stuffing a platform driver in the same place as your i2c driver seems
weird. I think you should split them up.
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_hdmiphy.c | 224
> ++-
> 1 file changed, 221 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> index b1b8a0f..33e89d9 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> @@ -32,6 +32,7 @@ struct hdmiphy_context {
>
> /* hdmiphy resources */
> void __iomem*phy_pow_ctrl_reg;
> + void __iomem*regs;
>
> struct hdmiphy_config *confs;
> unsigned intnr_confs;
> @@ -48,6 +49,135 @@ struct hdmiphy_drv_data {
> };
>
> /* list of all required phy config settings */
> +static struct hdmiphy_config hdmiphy_5420_configs[] = {
> + {
> + .pixel_clock = 2520,
> + .conf = {
> + 0x01, 0x52, 0x3F, 0x55, 0x40, 0x01, 0x00, 0xC8,
> + 0x82, 0xC8, 0xBD, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x06, 0x80, 0x01, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xF4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 2700,
> + .conf = {
> + 0x01, 0xD1, 0x22, 0x51, 0x40, 0x08, 0xFC, 0xE0,
> + 0x98, 0xE8, 0xCB, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x06, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xE4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 27027000,
> + .conf = {
> + 0x01, 0xD1, 0x2D, 0x72, 0x40, 0x64, 0x12, 0xC8,
> + 0x43, 0xE8, 0x0E, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x06, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xE3, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 3600,
> + .conf = {
> + 0x01, 0x51, 0x2D, 0x55, 0x40, 0x40, 0x00, 0xC8,
> + 0x02, 0xC8, 0x0E, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xAB, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 4000,
> + .conf = {
> + 0x01, 0xD1, 0x21, 0x31, 0x40, 0x3C, 0x28, 0xC8,
> + 0x87, 0xE8, 0xC8, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0x9A, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 6500,
> + .conf = {
> + 0x01, 0xD1, 0x36, 0x34, 0x40, 0x0C, 0x04, 0xC8,
> + 0x82, 0xE8, 0x45, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xBD, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 7100,
> + .conf = {
> + 0x01, 0xD1, 0x3B, 0x35, 0x40, 0x0C, 0x04, 0xC8,
> + 0x85, 0xE8, 0x63, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0x57, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 74176000,
> + .conf = {
> + 0x01, 0xD1, 0x1F, 0x10, 0x40, 0x5B, 0xEF, 0xC8,
> + 0x81, 0xE8, 0xB9, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x56, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xA6, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 7425,
> + .conf = {
> + 0x01, 0xD1, 0x1F, 0x10, 0x40, 0x40, 0xF8, 0xC8,
> + 0x81, 0xE8, 0xBA, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x56, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xA5, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 8350,
> + .conf = {
> + 0x01, 0xD1, 0x
Re: [RFC 01/10] drm: ADV7511 i2c HDMI encoder driver
Hi Lars-Peter, (CC'ing Hans Verkuil and the dri-devel and linux-media mailing lists) On Monday 02 September 2013 17:09:11 Lars-Peter Clausen wrote: > On 09/02/2013 05:01 PM, Laurent Pinchart wrote: > > On Monday 02 September 2013 16:43:25 Lars-Peter Clausen wrote: > >> On 09/02/2013 04:15 PM, Laurent Pinchart wrote: > >>> On Monday 02 September 2013 15:40:22 Lars-Peter Clausen wrote: > On 09/02/2013 03:18 PM, Laurent Pinchart wrote: > > On Friday 30 August 2013 14:37:35 Ulrich Hecht wrote: > >> ADV7511 driver snapshot taken from commit f416e32 of xcomm_zynq_3_10 > >> branch at https://github.com/analogdevicesinc/linux.git > > > > I believe Lars-Peter (CC'ed) was planning to upstream the driver. > > Lars-Peter, could you please share your plans ? > > My plan was to have all this upstream long time ago ;) > > As I said in that other thread, I don't think it is a good idea to have > two drivers for the same device. But if nobody else sees a problem with > this and as long as the v4l driver doesn't have devicetree support I > guess we could get away with it for now. Even if it will probably haunt > us later on. > > There are still a few minor bits and pieces to iron out, but lets try > to aim for 2.6.13. > >>> > >>> If you can make it for 2.6.13 I will be extremely impressed :-) > >> > >> Yea, I know DRM always takes a bit longer... > > > > I think you meant 3.13 ;-) > > > >>> Do you plan to push the driver yourself ? If so, I would appreciate if > >>> you could CC me. If there's just a few minor bits to iron out I can > >>> already review your latest version if that can help. > >> > >> There are a couple of style issues, so if you review the driver ignore > >> these for now, but otherwise feedback is welcome, thanks. And I'm not > >> also quite happy with the ASoC integration yet. I'll thus concentrate on the video part in the review. Any chance to get the video portion to mainline first and then add audio support ? > > Sure. Is the version available from the above branch the latest version ? > > Yes, you can find it here: > https://github.com/analogdevicesinc/linux/tree/xcomm_zynq/drivers/gpu/drm/ > i2c Thank you. > Oh and the DT bindings also still need proper documentation. I've squashed all the patches together and have copied the result below. > From f7c27f204cab3d7dcaa128880c0d9ef1ae0e2fc6 Mon Sep 17 00:00:00 2001 > From: Lars-Peter Clausen > Date: Mon, 5 Mar 2012 16:30:57 +0100 > Subject: [PATCH] DRM: Add adv7511 encoder driver > > This patch adds a driver for the Analog Devices adv7511. The adv7511 is a > standalone HDMI transmitter chip. It features a HDMI output interface on one > end and video and audio input interfaces on the other. > > Signed-off-by: Lars-Peter Clausen > --- > drivers/gpu/drm/Kconfig | 6 + > drivers/gpu/drm/i2c/Makefile| 3 + > drivers/gpu/drm/i2c/adv7511.h | 454 + > drivers/gpu/drm/i2c/adv7511_audio.c | 304 +++ > drivers/gpu/drm/i2c/adv7511_core.c | 979 + > 5 files changed, 1746 insertions(+) > create mode 100644 drivers/gpu/drm/i2c/adv7511.h > create mode 100644 drivers/gpu/drm/i2c/adv7511_audio.c > create mode 100644 drivers/gpu/drm/i2c/adv7511_core.c First of all, please run checkpatch.pl on the code :-) > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 626bc0c..d8862a4 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -200,6 +200,12 @@ config DRM_SAVAGE > Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister > chipset. If M is selected the module will be called savage. > > +config DRM_ENCODER_ADV7511 > + tristate "AV7511 encoder" > + depends on DRM && I2C > + select REGMAP_I2C > + select HDMI Beside adding a help text, you should also depend on and/or select SND_SOC. > + > source "drivers/gpu/drm/exynos/Kconfig" > > source "drivers/gpu/drm/vmwgfx/Kconfig" [snip] > diff --git a/drivers/gpu/drm/i2c/adv7511.h b/drivers/gpu/drm/i2c/adv7511.h > new file mode 100644 > index 000..4631fcd6 > --- /dev/null > +++ b/drivers/gpu/drm/i2c/adv7511.h > @@ -0,0 +1,454 @@ > +/** > + * Analog Devices ADV7511 HDMI transmitter driver > + * > + * Copyright 2012 Analog Devices Inc. > + * > + * Licensed under the GPL-2. > + */ > + > +#ifndef __ADV7511_H__ > +#define __ADV7511_H__ > + > +#include This file should be split in two headers, one with platform data that will go to include/linux/platform_data/, and another one that can stay here. > +#define ADV7511_REG_CHIP_REVISION0x00 > +#define ADV7511_REG_N0 0x01 > +#define ADV7511_REG_N1 0x02 > +#define ADV7511_REG_N2 0x03 > +#define ADV7511_REG_SPDIF_FREQ 0x04 > +#define ADV7511_REG_CTS_AUTOMATIC1 0x05 > +#
Re: [PATCH 3/7] drm/exynos: add hdmiphy pmu bit control in hdmiphy driver
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Before hdmiphy operation like config, start etc, hdmiphy
> bit in PMU block should be enabled. Earlier this happens
> in hdmi drvier through a dummy "hdmiphy" clock.
s/drvier/driver/
>
> Signed-off-by: Rahul Sharma
> ---
> .../devicetree/bindings/video/exynos_hdmiphy.txt |6 ++
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 +
> drivers/gpu/drm/exynos/exynos_hdmi.c |2 +
> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 82
>
> 4 files changed, 92 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> index 162f641..f6bf096 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -6,10 +6,16 @@ Required properties:
> 2) "samsung,exynos4210-hdmiphy".
> 3) "samsung,exynos4212-hdmiphy".
> - reg: I2C address of the hdmiphy device.
> +- phy-power-control: this child node represents phy power control
> + register which is inside the pmu block (power management unit).
Should you include devicetree-discuss on this?
>
> Example:
>
> hdmiphy {
> compatible = "samsung,exynos4210-hdmiphy";
> reg = <0x38>;
> +
> + phy-power-control {
> + reg = <0x10040700 0x04>;
> + };
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> index 1c839f8..9a14f96 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> @@ -68,6 +68,8 @@ void exynos_mixer_ops_register(struct exynos_mixer_ops
> *ops);
> int exynos_hdmiphy_driver_register(void);
> void exynos_hdmiphy_driver_unregister(void);
>
> +void exynos_hdmiphy_poweron(struct device *dev);
> +void exynos_hdmiphy_poweroff(struct device *dev);
> void exynos_hdmiphy_enable(struct device *dev);
> void exynos_hdmiphy_disable(struct device *dev);
> int exynos_hdmiphy_check_mode(struct device *dev,
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index cd1d921..a6234fc 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1131,6 +1131,7 @@ static void hdmiphy_poweron(struct hdmi_context *hdata)
> if (hdata->type == HDMI_TYPE14)
> hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, 0,
> HDMI_PHY_POWER_OFF_EN);
> + exynos_hdmiphy_poweron(hdata->hdmiphy_dev);
> }
>
> static void hdmiphy_poweroff(struct hdmi_context *hdata)
> @@ -1138,6 +1139,7 @@ static void hdmiphy_poweroff(struct hdmi_context *hdata)
> if (hdata->type == HDMI_TYPE14)
> hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, ~0,
> HDMI_PHY_POWER_OFF_EN);
> + exynos_hdmiphy_poweroff(hdata->hdmiphy_dev);
Shouldn't the phy power off before HDMI?
> }
>
> static void hdmi_conf_apply(struct hdmi_context *hdata)
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> index 82daa42..b1b8a0f 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> @@ -30,6 +30,9 @@ struct hdmiphy_context {
> struct device *dev;
> struct hdmiphy_config *current_conf;
>
> + /* hdmiphy resources */
> + void __iomem*phy_pow_ctrl_reg;
> +
> struct hdmiphy_config *confs;
> unsigned intnr_confs;
> };
> @@ -225,6 +228,49 @@ static struct hdmiphy_config *hdmiphy_find_conf(struct
> hdmiphy_context *hdata,
> return NULL;
> }
>
> +static int hdmiphy_dt_parse_power_control(struct hdmiphy_context *hdata)
> +{
> + struct device_node *phy_pow_ctrl_node;
> + u32 buf[2];
> + int ret = 0;
> +
> + phy_pow_ctrl_node = of_get_child_by_name(hdata->dev->of_node,
> + "phy-power-control");
> + if (!phy_pow_ctrl_node) {
> + DRM_ERROR("Failed to find phy power control node\n");
> + ret = -ENODEV;
> + goto fail;
You can just return -ENODEV here.
> + }
> +
> + /* reg property holds two informations: addr of pmu register, size */
> + if (of_property_read_u32_array(phy_pow_ctrl_node, "reg",
> + (u32 *)&buf, 2)) {
Maybe I'm missing something, but this looks bad. I think this should be:
of_property_read_u32_array(phy_pow_ctrl_node, "reg", buf, ARRAY_SIZE(buf))
ie: dereferencing buf won't do what you expect it to.
> + DRM_ERROR("faild to get phy power control reg\n");
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + hdata->phy_pow_ctrl_reg = devm_ioremap(hdata->dev, buf[0], buf[1]);
>
Re: [PATCH 2/7] drm/exynos: remove dummy hdmiphy clock
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> hdmiphy is a dummy clock which actually controls the PMU bit
> to enable/disbale hdmiphy (before CCF). This clock is cleaned
s/disbale/disable/
> from the hdmi driver.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c |8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 3af4e4c..cd1d921 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -84,7 +84,6 @@ struct hdmi_resources {
> struct clk *sclk_hdmi;
> struct clk *sclk_pixel;
> struct clk *sclk_hdmiphy;
> - struct clk *hdmiphy;
> struct clk *mout_hdmi;
> struct regulator_bulk_data *regul_bulk;
> int regul_count;
> @@ -1431,7 +1430,6 @@ static void hdmi_poweron(struct hdmi_context *hdata)
> if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
> DRM_DEBUG_KMS("failed to enable regulator bulk\n");
>
> - clk_prepare_enable(res->hdmiphy);
> clk_prepare_enable(res->hdmi);
> clk_prepare_enable(res->sclk_hdmi);
>
> @@ -1456,7 +1454,6 @@ static void hdmi_poweroff(struct hdmi_context *hdata)
>
> clk_disable_unprepare(res->sclk_hdmi);
> clk_disable_unprepare(res->hdmi);
> - clk_disable_unprepare(res->hdmiphy);
> regulator_bulk_disable(res->regul_count, res->regul_bulk);
>
> mutex_lock(&hdata->hdmi_mutex);
> @@ -1549,11 +1546,6 @@ static int hdmi_resources_init(struct hdmi_context
> *hdata)
> DRM_ERROR("failed to get clock 'sclk_hdmiphy'\n");
> goto fail;
> }
> - res->hdmiphy = devm_clk_get(dev, "hdmiphy");
> - if (IS_ERR(res->hdmiphy)) {
> - DRM_ERROR("failed to get clock 'hdmiphy'\n");
> - goto fail;
> - }
> res->mout_hdmi = devm_clk_get(dev, "mout_hdmi");
> if (IS_ERR(res->mout_hdmi)) {
> DRM_ERROR("failed to get clock 'mout_hdmi'\n");
> --
> 1.7.10.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Tue, Sep 03, 2013 at 04:34:56PM +0200, Maarten Lankhorst wrote: > Op 03-09-13 16:20, Pasi Kärkkäinen schreef: > > On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote: > >> Op 28-08-13 08:29, Pasi Kärkkäinen schreef: > >>> On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote: > On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote: > > Op 22-08-13 02:10, Ilia Mirkin schreef: > >> The code expects non-VRAM mem nodes to have a pages list. If that's not > >> set, it will do a null deref down the line. Warn on that condition and > >> return an error. > >> > >> See https://bugs.freedesktop.org/show_bug.cgi?id=64774 > >> > >> Reported-by: Pasi Kärkkäinen > >> Tested-by: Pasi Kärkkäinen > >> Signed-off-by: Ilia Mirkin > >> Cc: # 3.8+ > >> --- > >> > >> I don't exactly understand what's going on, but this is just a > >> straightforward way to avoid a null deref that you see happens in the > >> bug. I haven't figured out the root cause of this, but it's getting > >> well into the "I have no idea how TTM works" space. However this seems > >> like a bit of defensive programming -- nouveau_vm_map_sg will pass > >> node->pages as a list down, which will be dereferenced by > >> nvc0_vm_map_sg. Perhaps the other arguments should make that > >> dereferencing not happen, but it definitely was happening here, as you > >> can see in the bug. > >> > >> Ben/Maarten, I'll let you judge whether this check is appropriate, > >> since like I hope I was able to convey above, I'm just not really sure > >> :) > > Not it really isn't appropriate.. > > > > You'd have to call call nouveau_vm_map_sg_table instead, the only place > > that doesn't handle that correctly > > is where it's not expected to be called. > > > > Here, have a completely untested patch to fix things... > > > Maarten: I've been testing this stuff with Linux 3.10.x, so I had to > modify the patch a bit to make it apply there.. > I've attached the modified copy that applies to 3.10.9, hopefully I did > the backport correctly. > > With Linux 3.10.9 and the patch applied the kernel doesn't crash > anymore, and I get this error in dmesg: > > [ 76.105643] nouveau W[ DRM] Trying to create a fb in vram with > valid_domains=0004 > > Does that help? > > >>> Any comments? > >>> > >>> Maarten's patch works for me, I get that warning instead of a kernel > >>> crash, > >>> but it's also a bigger change that doesn't apply to older kernels as-is. > >>> > >>> Ilia's original patch in this thread can be applied to older kernels > >>> as-is, > >>> and it also prevents the kernel crash from happening. > >>> > >>> Should we get both applied, so Ilia's patch can be CC'd to stable ? > >>> > >> You haven't understood the root cause then. You're trying to move an > >> IMPORTED dma-buf into VRAM. > >> Doing so would seem to work, but at that point it's no longer a dma-buf so > >> changes done by the exporter > >> would not show up in nouveau because they no longer refer to the same > >> piece of memory. > >> > > Yes, that's true, I don't understand the root cause. > > That's mostly because I'm not familiar with the nouveau code/internals. > > > > > >> Failing is the only right option here. > >> > > Sorry but I'm not sure I understand that correctly.. what exactly do you > > suggest? What should fail? > > > > > > Because I'm not familiar with the code (yet) understanding and finding the > > root cause > > will take time for me.. that's why I was suggesting to meanwhile apply > > Ilia's very simple patch > > from this thread which actually prevents the hard kernel crash from > > happening, because it seems > > like an unharmful fix to have to protect against this kind of bugs (the > > root cause) ? > > Or is that unacceptable? > > > > (To recap: The kernel crash happens very often when trying to use the > > nouveau adapter in Optimus mode, with all kernels at least 3.8+, and it's > > very annoying that your laptop crashes when trying to enable a nouveau > > output. So Ilia's patch doesn't make the driver working properly, but at > > least it prevents the hard kernel crash from happening. The crash bug is in > > many kernel versions, including the long-term v3.10 tree. I've had the > > crash happening with 3.8.x, 3.9.x and 3.10.x) > > The fix probably requires commit fdfb8332651db7a280851dfccfc4f0cff4bcd052 to > apply cleanly "drm/nouveau: fix some error-path leaks in fbcon handling code" > So what you mean is to use fdfb8332651db7a280851dfccfc4f0cff4bcd052 and your patch from this thread? and skip Ilia's patch? -- Pasi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
A few comments.
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Exynos hdmiphy operations and configs are kept inside
> the hdmi driver. Hdmiphy related code is tightly coupled
> with hdmi IP driver.
>
> This patche moves hdmiphy related code to hdmiphy driver.
s/patche/patch
> It will help in cleanly supporting the hdmiphy variations
> in further SoCs.
>
> Signed-off-by: Rahul Sharma
> ---
> .../devicetree/bindings/video/exynos_hdmi.txt |2 +
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
> drivers/gpu/drm/exynos/exynos_hdmi.c | 343 +++
> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
> +++-
> drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
> 5 files changed, 533 insertions(+), 296 deletions(-)
> create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 50decf8..240eca5 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -25,6 +25,7 @@ Required properties:
> sclk_pixel.
> - clock-names: aliases as per driver requirements for above clock IDs:
> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
> +- phy: it points to hdmiphy dt node.
> Example:
>
> hdmi {
> @@ -32,4 +33,5 @@ Example:
> reg = <0x1453 0x10>;
> interrupts = <0 95 0>;
> hpd-gpio = <&gpx3 7 1>;
> + phy = <&hdmiphy>;
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> index 724cab1..1c839f8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> @@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context
> *ctx);
> void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
> void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
> void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
> +
> +int exynos_hdmiphy_driver_register(void);
> +void exynos_hdmiphy_driver_unregister(void);
> +
> +void exynos_hdmiphy_enable(struct device *dev);
> +void exynos_hdmiphy_disable(struct device *dev);
> +int exynos_hdmiphy_check_mode(struct device *dev,
> + struct drm_display_mode *mode);
> +int exynos_hdmiphy_set_mode(struct device *dev,
> + struct drm_display_mode *mode);
> +int exynos_hdmiphy_conf_apply(struct device *dev);
> #endif
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index f67ffca..3af4e4c 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -34,6 +34,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -172,7 +174,6 @@ struct hdmi_v14_conf {
> };
>
> struct hdmi_conf_regs {
> - int pixel_clock;
> int cea_video_id;
> union {
> struct hdmi_v13_conf v13_conf;
> @@ -193,9 +194,9 @@ struct hdmi_context {
> int irq;
>
> struct i2c_client *ddc_port;
> - struct i2c_client *hdmiphy_port;
> + struct device *hdmiphy_dev;
>
> - /* current hdmiphy conf regs */
> + /* current hdmi ip configuration registers. */
> struct hdmi_conf_regs mode_conf;
>
> struct hdmi_resources res;
> @@ -205,180 +206,6 @@ struct hdmi_context {
> enum hdmi_type type;
> };
>
> -struct hdmiphy_config {
> - int pixel_clock;
> - u8 conf[32];
> -};
> -
> -/* list of phy config settings */
> -static const struct hdmiphy_config hdmiphy_v13_configs[] = {
> - {
> - .pixel_clock = 2700,
> - .conf = {
> - 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
> - },
> - },
> - {
> - .pixel_clock = 27027000,
> - .conf = {
> - 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
> - },
> - },
> - {
> - .pixel_clock = 74176000,
> - .conf = {
> - 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef, 0x5B,
> - 0x6D, 0x10, 0x01, 0x51, 0
[Bug 68857] SNU OpenCL NAS Parallel Benchmarks don't work
https://bugs.freedesktop.org/show_bug.cgi?id=68857 --- Comment #1 from Tom Stellard --- I'm having a little trouble figuring out the build system for this suite, could you pick one of the failing examples and give instructions for how to build and execute it? Also, what version of Mesa and LLVM are you using? I recommend using the development versions of both for best results. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68901] New: wine/3DMark2001: shader generation fails
https://bugs.freedesktop.org/show_bug.cgi?id=68901 Priority: medium Bug ID: 68901 Keywords: regression Assignee: dri-devel@lists.freedesktop.org Summary: wine/3DMark2001: shader generation fails Severity: normal Classification: Unclassified OS: Linux (All) Reporter: gurket...@googlemail.com URL: http://www.futuremark.com/support/downloads Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa When running 3DMark2001 in wine (1.7.1), the r600 gallium driver (on RV710) fails to generate some shaders. This is a regression: 3f67251e3d0ce61a0e7fc16de91de6fb49cad768 is the first bad commit commit 3f67251e3d0ce61a0e7fc16de91de6fb49cad768 Author: Christian König Date: Sun Mar 10 14:33:29 2013 +0100 glsl_to_tgsi: allocate arrays separately v2 Instead of allocating everything as temporaries, use the new array allocation functions. v2: fix bug in simplify_cmp, declare arrays on demand Signed-off-by: Christian König :04 04 75a734fc12e314c32a959f4111543ec518cb8a51 57eed35384ed9aadd89adfce1a075b4ad0a745cc Msrc The output when the shader generation fails is: EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_shader.c:1886 r600_shader_from_tgsi - GPR limit exceeded - shader requires 129 registers EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_shader.c:134 r600_pipe_shader_create - translation from TGSI failed ! EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_state_common.c:750 r600_shader_select - Failed to build shader variant (type=0) -12 EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_shader.c:1886 r600_shader_from_tgsi - GPR limit exceeded - shader requires 129 registers EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_shader.c:134 r600_pipe_shader_create - translation from TGSI failed ! EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_state_common.c:750 r600_shader_select - Failed to build shader variant (type=0) -12 This is not a dupe of bug 62696 as the problem is still there with git version 6b5c802c30ada043ee31cc5e62249ff99bbc865f. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 2/3] drm/panel: Add simple panel support
On 08/30/2013 09:25 AM, Thierry Reding wrote: > Add a driver for simple panels. Such panels can have a regulator that > provides the supply voltage and a separate GPIO to enable the panel. > Optionally the panels can have a backlight associated with them so it > can be enabled or disabled according to the panel's power management > mode. > diff --git a/Documentation/devicetree/bindings/panel/panel-simple.txt > b/Documentation/devicetree/bindings/panel/panel-simple.txt > +Simple display panel > + > +Required properties: > +- compatible: should be one of: > + - "auo,b101aw03": AU Optronics Corporation 10.1" WSVGA TFT LCD panel > + - "cptt,claa101wb03": Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel > + - "pc,vvx10f004b00": Panasonic Corporation 10.1" WUXGA TFT LCD panel > + > +Optional properties: > +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing > +- power-supply: regulator to provide the supply voltage > +- enable-gpios: GPIO pin to enable or disable the panel > +- backlight: phandle of the backlight device attached to the panel Do we need to represent the timing requirements e.g. between panel enable and backlight enable, or do you expect the driver to hard-code this based on the compatible value? Looking at the driver code, it seems that it has direct knowledge of the video mode that each panel supports, so DDC is actually optional unlike what I asserted/assumed in my previous response. As such, I guess we should have a separate DT binding document for each of the three panels (compatible values) listed above that pretty much just says "go look at simple-panel.txt". ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: i915.disable_pch_pwm overrides PCH_PWM_ENABLE quirk
On Tue, Sep 3, 2013 at 7:37 PM, Kamal Mostafa wrote:
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
>
> Some BIOS configurations of Dell XPS13 are adversely affected by e85843b
> ("drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight") so provide a
> boot param to inhibit the quirk, or force it on.
>
> i915.disable_pch_pwm can be set to
> -1: auto (default; allows the disabling of pch_pwm by dmi quirk table match)
> 0: inhibits the disabling of pch_pwm (overrides dmi quirk table match)
> 1: forces the disabling of pch_pwm
>
> Signed-off-by: Kamal Mostafa
Nack. Piling quirk over quirk isn't the right approach and I think I
should just revert the pch_pwm enable quirk again.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 2/3] drm/panel: Add simple panel support
On 08/30/2013 01:24 PM, Kumar Gala wrote: > > On Aug 30, 2013, at 10:25 AM, Thierry Reding wrote: > >> Add a driver for simple panels. Such panels can have a regulator that >> provides the supply voltage and a separate GPIO to enable the panel. >> Optionally the panels can have a backlight associated with them so it >> can be enabled or disabled according to the panel's power management >> mode. >> >> Support is added for three panels: An AU Optronics 10.1" WSVGA, a >> Chunghwa Picture Tubes 10.1" WXGA and a Panasonic 10.1 WUXGA TFT LCD >> panel. >> diff --git a/Documentation/devicetree/bindings/panel/panel-simple.txt >> b/Documentation/devicetree/bindings/panel/panel-simple.txt >> +Required properties: >> +- compatible: should be one of: >> + - "auo,b101aw03": AU Optronics Corporation 10.1" WSVGA TFT LCD panel >> + - "cptt,claa101wb03": Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel >> + - "pc,vvx10f004b00": Panasonic Corporation 10.1" WUXGA TFT LCD panel >> + > > It would seem there should be a more generic compatible to cover the basic > "panel-simple" case. I would suggest only documenting "simple-panel" here, and not documenting the specific panels at all; the panel-specific compatible values would show up simply due to the rule that all compatible values in *.dts should contain the exact HW model (e.g. "auo,b101aw03"), plus any HW they're compatible with (i.e. "simple-panel"). I'd suggest "simple-panel" rather than "panel-simple" since IIRC other simple bindings are "simple-xxx" rather than "xxx-simple". >> +Optional properties: >> +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing >> +- power-supply: regulator to provide the supply voltage >> +- enable-gpios: GPIO pin to enable or disable the panel >> +- backlight: phandle of the backlight device attached to the panel >> + > > If these are all optional, what does it mean to be a "panel-simple"? I think at least ddc-i2c-bus and backlight should be required properties. I suppose it might be possible for the panel to be always-on, and hence enable-gpios/power-supply could be optional? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Tue, Sep 03, 2013 at 05:48:48PM +0300, Pasi Kärkkäinen wrote:
> > > Not it really isn't appropriate..
> > >
> > > You'd have to call call nouveau_vm_map_sg_table instead, the only
> > > place that doesn't handle that correctly
> > > is where it's not expected to be called.
> > >
> > > Here, have a completely untested patch to fix things...
> > >
> > Maarten: I've been testing this stuff with Linux 3.10.x, so I had to
> > modify the patch a bit to make it apply there..
> > I've attached the modified copy that applies to 3.10.9, hopefully I
> > did the backport correctly.
> >
> > With Linux 3.10.9 and the patch applied the kernel doesn't crash
> > anymore, and I get this error in dmesg:
> >
> > [ 76.105643] nouveau W[ DRM] Trying to create a fb in vram with
> > valid_domains=0004
> >
> > Does that help?
> >
> > >>> Any comments?
> > >>>
> > >>> Maarten's patch works for me, I get that warning instead of a kernel
> > >>> crash,
> > >>> but it's also a bigger change that doesn't apply to older kernels
> > >>> as-is.
> > >>>
> > >>> Ilia's original patch in this thread can be applied to older kernels
> > >>> as-is,
> > >>> and it also prevents the kernel crash from happening.
> > >>>
> > >>> Should we get both applied, so Ilia's patch can be CC'd to stable ?
> > >>>
> > >> You haven't understood the root cause then. You're trying to move an
> > >> IMPORTED dma-buf into VRAM.
> > >> Doing so would seem to work, but at that point it's no longer a dma-buf
> > >> so changes done by the exporter
> > >> would not show up in nouveau because they no longer refer to the same
> > >> piece of memory.
> > >>
> > > Yes, that's true, I don't understand the root cause.
> > > That's mostly because I'm not familiar with the nouveau code/internals.
> > >
> > >
> > >> Failing is the only right option here.
> > >>
> > > Sorry but I'm not sure I understand that correctly.. what exactly do you
> > > suggest? What should fail?
> > >
> > >
> > > Because I'm not familiar with the code (yet) understanding and finding
> > > the root cause
> > > will take time for me.. that's why I was suggesting to meanwhile apply
> > > Ilia's very simple patch
> > > from this thread which actually prevents the hard kernel crash from
> > > happening, because it seems
> > > like an unharmful fix to have to protect against this kind of bugs (the
> > > root cause) ?
> > > Or is that unacceptable?
> > >
> > > (To recap: The kernel crash happens very often when trying to use the
> > > nouveau adapter in Optimus mode, with all kernels at least 3.8+, and it's
> > > very annoying that your laptop crashes when trying to enable a nouveau
> > > output. So Ilia's patch doesn't make the driver working properly, but at
> > > least it prevents the hard kernel crash from happening. The crash bug is
> > > in many kernel versions, including the long-term v3.10 tree. I've had the
> > > crash happening with 3.8.x, 3.9.x and 3.10.x)
> >
> > The fix probably requires commit fdfb8332651db7a280851dfccfc4f0cff4bcd052
> > to apply cleanly "drm/nouveau: fix some error-path leaks in fbcon handling
> > code"
> >
>
> So what you mean is to use fdfb8332651db7a280851dfccfc4f0cff4bcd052 and your
> patch from this thread?
> and skip Ilia's patch?
>
So I tested with Linux 3.10.10. I had to apply these two patches first:
1e2bd5f53b6282e711e9f074765911868f8e7dc1 drm/nouveau: fixup fbcon failure paths
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=1e2bd5f53b6282e711e9f074765911868f8e7dc1
fdfb8332651db7a280851dfccfc4f0cff4bcd052 drm/nouveau: fix some error-path leaks
in fbcon handling code
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=fdfb8332651db7a280851dfccfc4f0cff4bcd052
And with those applied I was able to apply Maarten's patch cleanly (also
attached to this email).
It's worth noting that I'm able to reproduce the kernel crash bug with Fedora
18 (which has xorg-1.13),
but I'm not able to reproduce it with Fedora 19 (which has xorg-1.14). Both
running the same kernel.
Optimus enabled in BIOS on Lenovo T430 laptop. Nvidia GF108 Discreet GPU with
Intel integrated GPU.
Maarten's patch fixes the kernel crash problem, and produces a warning message
instead in dmesg.
You can add my Tested-By to the patch, assuming Maarten's patch is going to be
merged?
Thanks,
-- Pasi
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
{
struct nouveau_framebuffer *nouveau_fb;
struct drm_gem_object *gem;
+ struct nouveau_bo *nvbo;
int ret = -ENOMEM;
gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
if (!gem)
return ERR_PTR(-ENOENT);
+ nvbo = nouv
[PATCH] drm/radeon: add a connector property for audio
This provides a connector property to enable/disable hdmi
audio on the fly. The default is disabled, but you can select
auto (let the driver detect an audio capable monitor and enable it)
or enabled (force audio enabled). This also enables audio by
default so you no longer need a module parameter to enable audio.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 15 --
drivers/gpu/drm/radeon/radeon_connectors.c | 33 ++
drivers/gpu/drm/radeon/radeon_display.c| 12 +++
drivers/gpu/drm/radeon/radeon_drv.c| 2 +-
drivers/gpu/drm/radeon/radeon_mode.h | 9
5 files changed, 64 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index dfac796..9166e0b 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -707,8 +707,9 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
switch (connector->connector_type) {
case DRM_MODE_CONNECTOR_DVII:
case DRM_MODE_CONNECTOR_HDMIB: /* HDMI-B is basically DL-DVI; analog
works fine */
- if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
- radeon_audio)
+ if ((radeon_connector->audio == RADEON_AUDIO_ENABLE) ||
+ (drm_detect_hdmi_monitor(radeon_connector->edid) &&
+(radeon_connector->audio == RADEON_AUDIO_AUTO)))
return ATOM_ENCODER_MODE_HDMI;
else if (radeon_connector->use_digital)
return ATOM_ENCODER_MODE_DVI;
@@ -718,8 +719,9 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
case DRM_MODE_CONNECTOR_DVID:
case DRM_MODE_CONNECTOR_HDMIA:
default:
- if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
- radeon_audio)
+ if ((radeon_connector->audio == RADEON_AUDIO_ENABLE) ||
+ (drm_detect_hdmi_monitor(radeon_connector->edid) &&
+(radeon_connector->audio == RADEON_AUDIO_AUTO)))
return ATOM_ENCODER_MODE_HDMI;
else
return ATOM_ENCODER_MODE_DVI;
@@ -732,8 +734,9 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
if ((dig_connector->dp_sink_type ==
CONNECTOR_OBJECT_ID_DISPLAYPORT) ||
(dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_eDP))
return ATOM_ENCODER_MODE_DP;
- else if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
-radeon_audio)
+ else if ((radeon_connector->audio == RADEON_AUDIO_ENABLE) ||
+(drm_detect_hdmi_monitor(radeon_connector->edid) &&
+ (radeon_connector->audio == RADEON_AUDIO_AUTO)))
return ATOM_ENCODER_MODE_HDMI;
else
return ATOM_ENCODER_MODE_DVI;
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 2399f25..cbbdc85 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -396,6 +396,21 @@ static int radeon_connector_set_property(struct
drm_connector *connector, struct
}
}
+ if (property == rdev->mode_info.audio_property) {
+ struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
+ /* need to find digital encoder on connector */
+ encoder = radeon_find_encoder(connector, DRM_MODE_ENCODER_TMDS);
+ if (!encoder)
+ return 0;
+
+ radeon_encoder = to_radeon_encoder(encoder);
+
+ if (radeon_connector->audio != val) {
+ radeon_connector->audio = val;
+ radeon_property_change_mode(&radeon_encoder->base);
+ }
+ }
+
if (property == rdev->mode_info.underscan_property) {
/* need to find digital encoder on connector */
encoder = radeon_find_encoder(connector, DRM_MODE_ENCODER_TMDS);
@@ -1619,6 +1634,9 @@ radeon_add_atom_connector(struct drm_device *dev,
drm_object_attach_property(&radeon_connector->base.base,
rdev->mode_info.underscan_vborder_property,
0);
+ drm_object_attach_property(&radeon_connector->base.base,
+
rdev->mode_info.audio_property,
+ RADEON_AUDIO_DISABLE);
subpixel_order = SubPixelHorizontalRGB;
connector->interlace_allowed = true;
if (connector_type ==
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #101 from Alex Deucher --- (In reply to comment #96) > Not so fast fellas. Recently checked 3.11RC7 and DRM-Next (current). The > result is the same: it still can't boot with my Radeon HD 2600 XT :( Does disabling aspm help? `radeon.aspm=0 radeon.dpm=0` on the kernel command line in grub. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #100 from Alex Deucher --- (In reply to comment #99) > > Also, can you get a copy of the dmesg output from the driver after it loads? > > Try booting into a non-X runlevel without loading radeon (either blacklist > > it, or set radeon.modeset=0 on the kernel command line in grub) and then > > manually load it. E.g., > > modprobe -r radeon > > modprobe radeon modeset=1 dpm=1 > > I'm sorry I don't understand fully how to do this. boot with `radeon.modeset=0 1` on the kernel command line in grub, then when the kernel boots to single user mode, reload the radeon module with dpm=1. E.g., modprobe -r radeon modprobe radeon modeset=1 dpm=1 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68775] RV635 (r600) 600_DEBUG=sb causes GPU reset playing Second Life
https://bugs.freedesktop.org/show_bug.cgi?id=68775 --- Comment #2 from Shawn Starr --- Created attachment 85154 --> https://bugs.freedesktop.org/attachment.cgi?id=85154&action=edit GPU Reset information + userspace errors from reset GPU Reset information + userspace errors from reset -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68775] RV635 (r600) 600_DEBUG=sb causes GPU reset playing Second Life
https://bugs.freedesktop.org/show_bug.cgi?id=68775 Shawn Starr changed: What|Removed |Added Attachment #84943|0 |1 is obsolete|| --- Comment #3 from Shawn Starr --- Created attachment 85155 --> https://bugs.freedesktop.org/attachment.cgi?id=85155&action=edit Second Life - Shader full debug Second Life - Shader full debug -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #11 from Alexandre Demers --- So, after getting out at different points from ni_dpm_set_power_state(), it seems I can go down to ni_power_control_set_level() without problem. However, if I move to the next call which is ret = ni_dpm_force_performance_level(rdev, RADEON_DPM_FORCED_LEVEL_AUTO), it hangs. Could it be because we are setting something wrong in auto performance level? I'll be attaching my vbios just in case. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #12 from Alexandre Demers --- Created attachment 85157 --> https://bugs.freedesktop.org/attachment.cgi?id=85157&action=edit Cayman 6950 XFX vbios -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
linus-next: update to the drm-intel-fixes tree
Hi Daniel, This morning after fetching the drm-intel-fixes tree, I have discovered that you have just added a whole set of patches on top of Dave's drm tree and made that the drm-intel-fixes tree. I understood that this tree was for fixes to Linus' tree for the current release cycle. Given that Dave's tree has not been merged by Linus (yet), this is a bit inconsistent. Not only that, but now if I merge your tree early (which is what I do with the -fixes trees), I will also merge all of Dave's tree. That in turn would mean that I would have missed the (what would have been automatically applied) merge for I am carrying for Dave's tree. :-( I am going to have to drop your -fixes tree for today. If these are fixes for stuff in Linus' tree, then they should have been based on Linus' tree - if they are fixes for Dave's tree, then they should have been in your drm-intel tree, right? (fetches more trees ...) And now, I discover that they are the latter :-) So your -fixes tree will be dropped, but all those patches will still be merged via you drm-intel tree. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpH5iclLSo4i.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau/i2c: pass the function pointers in at creation time
On Sat, Aug 24, 2013 at 3:03 AM, Ilia Mirkin wrote:
> i2c_bit_add_bus can call the pre_xfer function, which expects the func
> pointer to be set. Pass in func to the port creation logic so that it is
> set before i2c_bit_add_bus.
Merged, thanks!
Ben.
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=68456
>
> Reported-by: Hans-Peter Deifel
> Tested-by: Hans-Peter Deifel
> Signed-off-by: Ilia Mirkin
> ---
>
> This will only happen if i2c_algo_bit.bit_test=1.
>
> drivers/gpu/drm/nouveau/core/include/subdev/i2c.h | 8 +---
> drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c | 10 --
> drivers/gpu/drm/nouveau/core/subdev/i2c/base.c| 2 ++
> drivers/gpu/drm/nouveau/core/subdev/i2c/nv04.c| 4 ++--
> drivers/gpu/drm/nouveau/core/subdev/i2c/nv4e.c| 4 ++--
> drivers/gpu/drm/nouveau/core/subdev/i2c/nv50.c| 4 ++--
> drivers/gpu/drm/nouveau/core/subdev/i2c/nv94.c| 8
> drivers/gpu/drm/nouveau/core/subdev/i2c/nvd0.c| 4 ++--
> 8 files changed, 23 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h
> b/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h
> index 888384c..7e4e277 100644
> --- a/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h
> +++ b/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h
> @@ -39,8 +39,8 @@ struct nouveau_i2c_func {
> int (*drv_ctl)(struct nouveau_i2c_port *, int lane, int sw, int pe);
> };
>
> -#define nouveau_i2c_port_create(p,e,o,i,a,d)
> \
> - nouveau_i2c_port_create_((p), (e), (o), (i), (a),
> \
> +#define nouveau_i2c_port_create(p,e,o,i,a,f,d)
> \
> + nouveau_i2c_port_create_((p), (e), (o), (i), (a), (f),
> \
> sizeof(**d), (void **)d)
> #define nouveau_i2c_port_destroy(p) ({
> \
> struct nouveau_i2c_port *port = (p);
> \
> @@ -53,7 +53,9 @@ struct nouveau_i2c_func {
>
> int nouveau_i2c_port_create_(struct nouveau_object *, struct nouveau_object
> *,
> struct nouveau_oclass *, u8,
> -const struct i2c_algorithm *, int, void **);
> +const struct i2c_algorithm *,
> +const struct nouveau_i2c_func *,
> +int, void **);
> void _nouveau_i2c_port_dtor(struct nouveau_object *);
> #define _nouveau_i2c_port_init nouveau_object_init
> #define _nouveau_i2c_port_fini nouveau_object_fini
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
> b/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
> index dec94e9..4b195ac 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
> @@ -118,7 +118,8 @@ anx9805_aux_chan_ctor(struct nouveau_object *parent,
> int ret;
>
> ret = nouveau_i2c_port_create(parent, engine, oclass, index,
> -&nouveau_i2c_aux_algo, &chan);
> + &nouveau_i2c_aux_algo,
> &anx9805_aux_func,
> + &chan);
> *pobject = nv_object(chan);
> if (ret)
> return ret;
> @@ -140,8 +141,6 @@ anx9805_aux_chan_ctor(struct nouveau_object *parent,
> struct i2c_algo_bit_data *algo = mast->adapter.algo_data;
> algo->udelay = max(algo->udelay, 40);
> }
> -
> - chan->base.func = &anx9805_aux_func;
> return 0;
> }
>
> @@ -234,7 +233,8 @@ anx9805_ddc_port_ctor(struct nouveau_object *parent,
> int ret;
>
> ret = nouveau_i2c_port_create(parent, engine, oclass, index,
> -&anx9805_i2c_algo, &port);
> + &anx9805_i2c_algo, &anx9805_i2c_func,
> + &port);
> *pobject = nv_object(port);
> if (ret)
> return ret;
> @@ -256,8 +256,6 @@ anx9805_ddc_port_ctor(struct nouveau_object *parent,
> struct i2c_algo_bit_data *algo = mast->adapter.algo_data;
> algo->udelay = max(algo->udelay, 40);
> }
> -
> - port->base.func = &anx9805_i2c_func;
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c
> index 8ae2625..2895c19 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c
> @@ -95,6 +95,7 @@ nouveau_i2c_port_create_(struct nouveau_object *parent,
> struct nouveau_object *engine,
> struct nouveau_oclass *oclass, u8 index,
> const struct i2c_algorithm *algo,
> +const struct nouveau_i2c_func *func,
>
Re: [PATCH] drm/nouveau: do not move buffers when not needed
On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst
wrote:
> Op 15-07-13 08:05, Ben Skeggs schreef:
>> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
>> wrote:
>>> I have no idea what this bogus restriction on placement is, but it breaks
>>> decoding 1080p
>>> VDPAU at boot speed. With this patch applied I only need to bump the vdec
>>> clock to
>>> get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer
>>> moves.
>> It's not bogus, and is required for pre-GF8 boards with VRAM > BAR size.
>>
>> What configuration does the buffer that's getting moved here have
>> exactly? The placement restriction isn't necessary on GF8, the rest
>> of the restrictions may currently be required still however.
>>
>>= vdpau on NVC0 with tiling. I upload the raw bitstream to a tiling bo. This
>>is ok because
> the vm hides all the tiling translations, and the engines will read the raw
> bitstream correctly.
Why would you be doing such a thing in the first place? It seems
pointless, and quite possibly counter-productive to use a tiled layout
for a linear data structure...
> 8<---
> This prevents buffer moves from being done on NV50+, where remapping is not
> needed because
> the bar has its own VM, instead of only having the first BAR1-size chunk of
> VRAM accessible.
> nouveau_bo_tile_layout is always 0 on < NV_50.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index d506da5..762bfcd 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1346,14 +1361,13 @@ nouveau_ttm_fault_reserve_notify(struct
> ttm_buffer_object *bo)
> struct nouveau_device *device = nv_device(drm->device);
> u32 mappable = pci_resource_len(device->pdev, 1) >> PAGE_SHIFT;
>
> - /* as long as the bo isn't in vram, and isn't tiled, we've got
> -* nothing to do here.
> + /*
> +* if the bo is not in vram, or remapping can be done (nv50+)
> +* do not worry about placement, any location is valid
> */
> - if (bo->mem.mem_type != TTM_PL_VRAM) {
> - if (nv_device(drm->device)->card_type < NV_50 ||
> - !nouveau_bo_tile_layout(nvbo))
> - return 0;
> - }
> + if (nv_device(drm->device)->card_type >= NV_50 ||
> + bo->mem.mem_type != TTM_PL_VRAM)
> + return 0;
I get what you're trying to do here, and we should definitely avoid
the "mappable vram" check on GF8, but I suspect this condition is too
broad. I'll think about it more after I finish reviewing the rest of
the patches on the list..
Thanks,
Ben.
>
> /* make sure bo is in mappable vram */
> if (bo->mem.start + bo->mem.num_pages < mappable)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/msm: handle read vs write fences
The userspace API already had everything needed to handle read vs write
synchronization. This patch actually bothers to hook it up properly, so
that we don't need to (for example) stall on userspace read access to a
buffer that gpu is also still reading.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.h | 2 +-
drivers/gpu/drm/msm/msm_gem.c | 25 ++---
drivers/gpu/drm/msm/msm_gem.h | 2 +-
drivers/gpu/drm/msm/msm_gpu.c | 9 +++--
4 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 80d7509..1ea9d46 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -153,7 +153,7 @@ void *msm_gem_vaddr(struct drm_gem_object *obj);
int msm_gem_queue_inactive_work(struct drm_gem_object *obj,
struct work_struct *work);
void msm_gem_move_to_active(struct drm_gem_object *obj,
- struct msm_gpu *gpu, uint32_t fence);
+ struct msm_gpu *gpu, bool write, uint32_t fence);
void msm_gem_move_to_inactive(struct drm_gem_object *obj);
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op,
struct timespec *timeout);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 6b5a6c8..df0390f 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -393,11 +393,14 @@ int msm_gem_queue_inactive_work(struct drm_gem_object
*obj,
}
void msm_gem_move_to_active(struct drm_gem_object *obj,
- struct msm_gpu *gpu, uint32_t fence)
+ struct msm_gpu *gpu, bool write, uint32_t fence)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
msm_obj->gpu = gpu;
- msm_obj->fence = fence;
+ if (write)
+ msm_obj->write_fence = fence;
+ else
+ msm_obj->read_fence = fence;
list_del_init(&msm_obj->mm_list);
list_add_tail(&msm_obj->mm_list, &gpu->active_list);
}
@@ -411,7 +414,8 @@ void msm_gem_move_to_inactive(struct drm_gem_object *obj)
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
msm_obj->gpu = NULL;
- msm_obj->fence = 0;
+ msm_obj->read_fence = 0;
+ msm_obj->write_fence = 0;
list_del_init(&msm_obj->mm_list);
list_add_tail(&msm_obj->mm_list, &priv->inactive_list);
@@ -433,8 +437,14 @@ int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t
op,
struct msm_gem_object *msm_obj = to_msm_bo(obj);
int ret = 0;
- if (is_active(msm_obj) && !(op & MSM_PREP_NOSYNC))
- ret = msm_wait_fence_interruptable(dev, msm_obj->fence,
timeout);
+ if (is_active(msm_obj) && !(op & MSM_PREP_NOSYNC)) {
+ uint32_t fence = 0;
+ if (op & MSM_PREP_READ)
+ fence = msm_obj->write_fence;
+ if (op & MSM_PREP_WRITE)
+ fence = max(fence, msm_obj->read_fence);
+ ret = msm_wait_fence_interruptable(dev, fence, timeout);
+ }
/* TODO cache maintenance */
@@ -455,9 +465,10 @@ void msm_gem_describe(struct drm_gem_object *obj, struct
seq_file *m)
uint64_t off = drm_vma_node_start(&obj->vma_node);
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
- seq_printf(m, "%08x: %c(%d) %2d (%2d) %08llx %p %d\n",
+ seq_printf(m, "%08x: %c(r=%u,w=%u) %2d (%2d) %08llx %p %d\n",
msm_obj->flags, is_active(msm_obj) ? 'A' : 'I',
- msm_obj->fence, obj->name,
obj->refcount.refcount.counter,
+ msm_obj->read_fence, msm_obj->write_fence,
+ obj->name, obj->refcount.refcount.counter,
off, msm_obj->vaddr, obj->size);
}
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index d746f13..0676f32 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -36,7 +36,7 @@ struct msm_gem_object {
*/
struct list_head mm_list;
struct msm_gpu *gpu; /* non-null if active */
- uint32_t fence;
+ uint32_t read_fence, write_fence;
/* Transiently in the process of submit ioctl, objects associated
* with the submit are on submit->bo_list.. this only lasts for
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index e1e1ec9..cb9cdff 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -265,7 +265,8 @@ static void retire_worker(struct work_struct *work)
obj = list_first_entry(&gpu->active_list,
struct msm_gem_object, mm_list);
- if (obj->fence <= fence) {
+ if ((obj->read_fence <= fence) &&
+ (obj->write_fence <= fence)) {
/* move to inactive: */
msm_gem_move_to_inactive(&obj->base);
msm
[PATCH 2/2] drm/msm: hangcheck harder
If gpu locks up with the rptr shortly beyond the wrap-around point in
the ringbuffer, because the rptr was not reset (but wptr is, by virtue
of resetting rb->cur), we could end up in a scenario where we think
there is not enough space in the ringbuffer for the next cmds. And
since the CP won't reset rptr until after processing an IB, this leaves
things in a sort of deadlock.
So reset rptr too. And a bit more spiffing up of hangcheck to make
things easier to debug.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 10 +-
drivers/gpu/drm/msm/msm_gpu.c | 9 -
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index a605847..a0b9d8a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -124,6 +124,8 @@ void adreno_recover(struct msm_gpu *gpu)
/* reset completed fence seqno, just discard anything pending: */
adreno_gpu->memptrs->fence = gpu->submitted_fence;
+ adreno_gpu->memptrs->rptr = 0;
+ adreno_gpu->memptrs->wptr = 0;
gpu->funcs->pm_resume(gpu);
ret = gpu->funcs->hw_init(gpu);
@@ -229,7 +231,7 @@ void adreno_idle(struct msm_gpu *gpu)
return;
} while(time_before(jiffies, t));
- DRM_ERROR("timeout waiting for %s to drain ringbuffer!\n", gpu->name);
+ DRM_ERROR("%s: timeout waiting to drain ringbuffer!\n", gpu->name);
/* TODO maybe we need to reset GPU here to recover from hang? */
}
@@ -256,11 +258,17 @@ void adreno_wait_ring(struct msm_gpu *gpu, uint32_t
ndwords)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
uint32_t freedwords;
+ unsigned long t = jiffies + ADRENO_IDLE_TIMEOUT;
do {
uint32_t size = gpu->rb->size / 4;
uint32_t wptr = get_wptr(gpu->rb);
uint32_t rptr = adreno_gpu->memptrs->rptr;
freedwords = (rptr + (size - 1) - wptr) % size;
+
+ if (time_after(jiffies, t)) {
+ DRM_ERROR("%s: timeout waiting for ringbuffer space\n",
gpu->name);
+ break;
+ }
} while(freedwords < ndwords);
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index cb9cdff..10cc443 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -237,8 +237,15 @@ static void hangcheck_handler(unsigned long data)
gpu->hangcheck_fence = fence;
} else if (fence < gpu->submitted_fence) {
/* no progress and not done.. hung! */
- struct msm_drm_private *priv = gpu->dev->dev_private;
+ struct drm_device *dev = gpu->dev;
+ struct msm_drm_private *priv = dev->dev_private;
gpu->hangcheck_fence = fence;
+ dev_err(dev->dev, "%s: hangcheck detected gpu lockup!\n",
+ gpu->name);
+ dev_err(dev->dev, "%s: completed fence: %u\n",
+ gpu->name, fence);
+ dev_err(dev->dev, "%s: submitted fence: %u\n",
+ gpu->name, gpu->submitted_fence);
queue_work(priv->wq, &gpu->recover_work);
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/nouveau: use MSI interrupts
On Fri, Aug 30, 2013 at 5:11 PM, Lucas Stach wrote:
> Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs:
>> On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin wrote:
>> > On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs wrote:
>> >> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin
>> >> wrote:
>> >>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin
>> wrote:
>> > On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
>> >> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin
>> >> wrote:
>> >>> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs
>> >>> wrote:
>> On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin
>> wrote:
>> > On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach
>> > wrote:
>> >> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
>> >>> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach
>> >>> wrote:
>> >>> > MSIs were only problematic on some old, broken chipsets. But
>> >>> > now that we
>> >>> > already see systems where PCI legacy interrupts are somewhat
>> >>> > flaky, it's
>> >>> > really time to move to MSIs.
>> >>> >
>> >>> > Signed-off-by: Lucas Stach
>> >>> > ---
>> >>> > drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
>> >>> > drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17
>> >>> > +
>> >>> > 2 files changed, 18 insertions(+)
>> >>> >
>> >>> > diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>> >>> > b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>> >>> > index 9d2cd20..ce6569f 100644
>> >>> > --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>> >>> > +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>> >>> > @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
>> >>> > struct nouveau_mc {
>> >>> > struct nouveau_subdev base;
>> >>> > const struct nouveau_mc_intr *intr_map;
>> >>> > + bool use_msi;
>> >>> > };
>> >>> >
>> >>> > static inline struct nouveau_mc *
>> >>> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>> >>> > b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>> >>> > index ec9cd6f..02b337e 100644
>> >>> > --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>> >>> > +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>> >>> > @@ -23,6 +23,7 @@
>> >>> > */
>> >>> >
>> >>> > #include
>> >>> > +#include
>> >>> >
>> >>> > static irqreturn_t
>> >>> > nouveau_mc_intr(int irq, void *arg)
>> >>> > @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
>> >>> > map++;
>> >>> > }
>> >>> >
>> >>> > + if (pmc->use_msi)
>> >>> > + nv_wr08(pmc->base.base.parent, 0x00088068,
>> >>> > 0xff);
>> >>> Register not present everywhere.
>> >>>
>> >>> At the very least, the enabling of MSI should be disallowed on
>> >>> the
>> >>> earlier chipsets where it's not supported. Though, it's perhaps
>> >>> possible that the pci_enable_msi() call will fail in all of these
>> >>> cases anyway.. I'm not certain.
>> >>>
>> >> MSIs are required property for everything doing PCIe. So the only
>> >> cases
>> >> where this should fail is plain PCI/AGP devices. I don't really
>> >> have a
>> >> test system for those old cards set up.
>> >>
>> >> But I remember Ilia having some legacy things plugged in, so
>> >> maybe he
>> >> could test this patch and see how it goes?
>> >
>> > Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
>> > that it's not native PCIe, but some sort of bridge thing IIRC),
>> Cases like the nv34 here (i think there's some nv4x that aren't
>> native
>> pcie too) are what I'm wondering about primarily.
>> >>>
>> >>> And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
>> >>> with "AutoAddGPU" disabled the NV18 and NV42 seem fine. However
>> >>> merely
>> >>> starting X (not xinit, not startx, not [gkx]dm) on the NV34 and
>> >>> ^C'ing
>> >>> it (with no clients connecting to said X), causes a "failed to idle
>> >>> channel" message in dmesg, which apparently never rectifies itself,
>> >>> so
>> >>> X is hung forever. FTR, there were no displays connected either, but
>> >>> I
>> >>> tried the exact same procedure without the MSI patch and it worked
>> >>> fine. Here is the init sequence with the MSI patch:
>> >> I don't suppose bashing 0x1868 instead of 0x88068 works here? If
[PATCH] dma-buf: Expose buffer size to userspace (v2)
Each dma-buf has an associated size and it's reasonable for userspace
to want to know what it is.
Since userspace already has an fd, expose the size using the
size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0);
idiom.
v2: Added Daniel's sugeested documentation, with minor fixups
Signed-off-by: Christopher James Halse Rogers
Reviewed-by: Daniel Vetter
Tested-by: Daniel Vetter
---
Documentation/dma-buf-sharing.txt | 12
drivers/base/dma-buf.c| 28
2 files changed, 40 insertions(+)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index 0b23261..849e982 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -407,6 +407,18 @@ Being able to mmap an export dma-buf buffer object has 2
main use-cases:
interesting ways depending upong the exporter (if userspace starts depending
upon this implicit synchronization).
+Other Interfaces Exposed to Userspace on the dma-buf FD
+--
+
+- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only
+ with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow
+ the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other
+ llseek operation will report -EINVAL.
+
+ If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all
+ cases. Userspace can use this to detect support for discovering the dma-buf
+ size using llseek.
+
Miscellaneous notes
---
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 6687ba7..c33a857 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -77,9 +77,36 @@ static int dma_buf_mmap_internal(struct file *file, struct
vm_area_struct *vma)
return dmabuf->ops->mmap(dmabuf, vma);
}
+static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
+{
+ struct dma_buf *dmabuf;
+ loff_t base;
+
+ if (!is_dma_buf_file(file))
+ return -EBADF;
+
+ dmabuf = file->private_data;
+
+ /* only support discovering the end of the buffer,
+ but also allow SEEK_SET to maintain the idiomatic
+ SEEK_END(0), SEEK_CUR(0) pattern */
+ if (whence == SEEK_END)
+ base = dmabuf->size;
+ else if (whence == SEEK_SET)
+ base = 0;
+ else
+ return -EINVAL;
+
+ if (offset != 0)
+ return -EINVAL;
+
+ return base + offset;
+}
+
static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
+ .llseek = dma_buf_llseek,
};
/*
@@ -133,6 +160,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
dmabuf->exp_name = exp_name;
file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
+ file->f_mode |= FMODE_LSEEK;
dmabuf->file = file;
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nv84-: write fence value on exit, and restore value on init.
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
wrote:
> This increases the chance slightly that recovery from lockup can happen
> succesfully.
I'd *really* love to see proof of this. When channels die, all
outstanding fences are marked as signalled. This should do absolutely
nothing...
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/nouveau/nv84_fence.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nv84_fence.c
> b/drivers/gpu/drm/nouveau/nv84_fence.c
> index 2cf0ade..daf4b18 100644
> --- a/drivers/gpu/drm/nouveau/nv84_fence.c
> +++ b/drivers/gpu/drm/nouveau/nv84_fence.c
> @@ -122,8 +122,11 @@ nv84_fence_context_del(struct nouveau_channel *chan)
> struct drm_device *dev = chan->drm->dev;
> struct nv84_fence_priv *priv = chan->drm->fence;
> struct nv84_fence_chan *fctx = chan->fence;
> + struct nouveau_fifo_chan *fifo = (void *)chan->object;
> int i;
>
> + nouveau_bo_wr32(priv->bo, fifo->chid * 16/4, fctx->base.sequence);
> +
> for (i = 0; i < dev->mode_config.num_crtc; i++) {
> struct nouveau_bo *bo = nv50_display_crtc_sema(dev, i);
> nouveau_bo_vma_del(bo, &fctx->dispc_vma[i]);
> @@ -168,7 +171,7 @@ nv84_fence_context_new(struct nouveau_channel *chan)
> ret = nouveau_bo_vma_add(bo, client->vm, &fctx->dispc_vma[i]);
> }
>
> - nouveau_bo_wr32(priv->bo, fifo->chid * 16/4, 0x);
> + fctx->base.sequence = nouveau_bo_rd32(priv->bo, fifo->chid * 16/4);
>
> if (ret)
> nv84_fence_context_del(chan);
> --
> 1.8.3.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nv50-: make dma-objects read-only where appropriate
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
wrote:
> I don't see why the display engine would need write access to the entirety of
> vram, when read-only access is enough.
Meh, this really doesn't matter... We're doing the same setup as
nvidia do here, and I see no good reason not to.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/nouveau/nv50_display.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
> b/drivers/gpu/drm/nouveau/nv50_display.c
> index aab72f5..eac6b2a 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.c
> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
> @@ -159,7 +159,7 @@ nv50_dmac_create_fbdma(struct nouveau_object *core, u32
> parent)
> NV_DMA_IN_MEMORY_CLASS,
> &(struct nv_dma_class) {
> .flags = NV_DMA_TARGET_VRAM |
> -NV_DMA_ACCESS_RDWR,
> +NV_DMA_ACCESS_RD,
> .start = 0,
> .limit = pfb->ram->size - 1,
> .conf0 = NV50_DMA_CONF0_ENABLE |
> @@ -172,7 +172,7 @@ nv50_dmac_create_fbdma(struct nouveau_object *core, u32
> parent)
> NV_DMA_IN_MEMORY_CLASS,
> &(struct nv_dma_class) {
> .flags = NV_DMA_TARGET_VRAM |
> -NV_DMA_ACCESS_RDWR,
> +NV_DMA_ACCESS_RD,
> .start = 0,
> .limit = pfb->ram->size - 1,
> .conf0 = NV50_DMA_CONF0_ENABLE | 0x70
> |
> @@ -185,7 +185,7 @@ nv50_dmac_create_fbdma(struct nouveau_object *core, u32
> parent)
> NV_DMA_IN_MEMORY_CLASS,
> &(struct nv_dma_class) {
> .flags = NV_DMA_TARGET_VRAM |
> -NV_DMA_ACCESS_RDWR,
> +NV_DMA_ACCESS_RD,
> .start = 0,
> .limit = pfb->ram->size - 1,
> .conf0 = NV50_DMA_CONF0_ENABLE | 0x7a
> |
> @@ -204,7 +204,7 @@ nvc0_dmac_create_fbdma(struct nouveau_object *core, u32
> parent)
> NV_DMA_IN_MEMORY_CLASS,
> &(struct nv_dma_class) {
> .flags = NV_DMA_TARGET_VRAM |
> -NV_DMA_ACCESS_RDWR,
> +NV_DMA_ACCESS_RD,
> .start = 0,
> .limit = pfb->ram->size - 1,
> .conf0 = NVC0_DMA_CONF0_ENABLE,
> @@ -216,7 +216,7 @@ nvc0_dmac_create_fbdma(struct nouveau_object *core, u32
> parent)
> NV_DMA_IN_MEMORY_CLASS,
> &(struct nv_dma_class) {
> .flags = NV_DMA_TARGET_VRAM |
> -NV_DMA_ACCESS_RDWR,
> +NV_DMA_ACCESS_RD,
> .start = 0,
> .limit = pfb->ram->size - 1,
> .conf0 = NVC0_DMA_CONF0_ENABLE | 0xfe,
> @@ -228,7 +228,7 @@ nvc0_dmac_create_fbdma(struct nouveau_object *core, u32
> parent)
> NV_DMA_IN_MEMORY_CLASS,
> &(struct nv_dma_class) {
> .flags = NV_DMA_TARGET_VRAM |
> -NV_DMA_ACCESS_RDWR,
> +NV_DMA_ACCESS_RD,
> .start = 0,
> .limit = pfb->ram->size - 1,
> .conf0 = NVC0_DMA_CONF0_ENABLE | 0xfe,
> @@ -246,7 +246,7 @@ nvd0_dmac_create_fbdma(struct nouveau_object *core, u32
> parent)
> NV_DMA_IN_MEMORY_CLASS,
> &(struct nv_dma_class) {
> .flags = NV_DMA_TARGET_VRAM |
> -NV_DMA_ACCESS_RDWR,
> +NV_DMA_ACCESS_RD,
> .start = 0,
> .limit = pfb->ram->size -
Re: [PATCH] drm/nouveau: fix command submission to use vmalloc for big allocations
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
wrote:
> I was getting a order 4 allocation failure from kmalloc when testing some game
> after a few days uptime with some suspend/resumes. For big allocations vmalloc
> should be used instead.
I've picked up this patch with a minor modification (see below)
>
> Also limit size more aggressively to 256 KiB.
I dropped this, it's *completely* useless, the sizes are already
enforced right at the beginning of the ioctl (shockingly, the max size
is going to be 256KiB already)...
Thanks,
Ben.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/nouveau/nouveau_gem.c | 30 +++---
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
> b/drivers/gpu/drm/nouveau/nouveau_gem.c
> index 177b86d5..779d702 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> @@ -584,18 +584,34 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel
> *chan,
> return 0;
> }
>
> +static inline void
> +u_free(void *addr)
> +{
> + if (!is_vmalloc_addr(addr))
> + kfree(addr);
> + else
> + vfree(addr);
> +}
> +
> static inline void *
> u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
> {
> void *mem;
> void __user *userptr = (void __force __user *)(uintptr_t)user;
>
> - mem = kmalloc(nmemb * size, GFP_KERNEL);
> + if (nmemb > 256 * 1024 / size)
> + return ERR_PTR(-ENOMEM);
> +
> + size *= nmemb;
> +
> + mem = kmalloc(size, GFP_KERNEL | __GFP_NOWARN);
> + if (!mem)
> + mem = vmalloc(size);
> if (!mem)
> return ERR_PTR(-ENOMEM);
>
> - if (DRM_COPY_FROM_USER(mem, userptr, nmemb * size)) {
> - kfree(mem);
> + if (DRM_COPY_FROM_USER(mem, userptr, size)) {
> + u_free(mem);
> return ERR_PTR(-EFAULT);
> }
>
> @@ -681,7 +697,7 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
> nouveau_bo_wr32(nvbo, r->reloc_bo_offset >> 2, data);
> }
>
> - kfree(reloc);
> + u_free(reloc);
> return ret;
> }
>
> @@ -743,7 +759,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
> *data,
>
> bo = u_memcpya(req->buffers, req->nr_buffers, sizeof(*bo));
> if (IS_ERR(bo)) {
> - kfree(push);
> + u_free(push);
> return nouveau_abi16_put(abi16, PTR_ERR(bo));
> }
>
> @@ -854,8 +870,8 @@ out:
> nouveau_fence_unref(&fence);
>
> out_prevalid:
> - kfree(bo);
> - kfree(push);
> + u_free(bo);
> + u_free(push);
>
> out_next:
> if (chan->dma.ib_max) {
> --
> 1.8.3.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: force alignment to 0x1000 for gpu objects
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
wrote:
> There are a lot of places that allocate multiples of 1000,
> but do not set alignment correctly and still require this
> alignment implicitly or explicitly.
This is wrong. Where are the places you think you need this?
Ben.
> ---
> drivers/gpu/drm/nouveau/core/core/gpuobj.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/core/core/gpuobj.c
> b/drivers/gpu/drm/nouveau/core/core/gpuobj.c
> index 7595506..7bcae1d 100644
> --- a/drivers/gpu/drm/nouveau/core/core/gpuobj.c
> +++ b/drivers/gpu/drm/nouveau/core/core/gpuobj.c
> @@ -65,6 +65,14 @@ nouveau_gpuobj_create_(struct nouveau_object *parent,
> int ret, i;
> u64 addr;
>
> + /*
> +* There are a lot of places that allocate multiples of 1000,
> +* but do not set alignment correctly and still require this
> +* alignment implicitly or explicitly.
> +*/
> + if (size >= 0x1000 && align < 0x1000)
> + align = 0x1000;
> +
> *pobject = NULL;
>
> if (pargpu) {
> --
> 1.8.3.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
wrote:
> Op 22-08-13 02:10, Ilia Mirkin schreef:
>> The code expects non-VRAM mem nodes to have a pages list. If that's not
>> set, it will do a null deref down the line. Warn on that condition and
>> return an error.
>>
>> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
>>
>> Reported-by: Pasi Kärkkäinen
>> Tested-by: Pasi Kärkkäinen
>> Signed-off-by: Ilia Mirkin
>> Cc: # 3.8+
>> ---
>>
>> I don't exactly understand what's going on, but this is just a
>> straightforward way to avoid a null deref that you see happens in the
>> bug. I haven't figured out the root cause of this, but it's getting
>> well into the "I have no idea how TTM works" space. However this seems
>> like a bit of defensive programming -- nouveau_vm_map_sg will pass
>> node->pages as a list down, which will be dereferenced by
>> nvc0_vm_map_sg. Perhaps the other arguments should make that
>> dereferencing not happen, but it definitely was happening here, as you
>> can see in the bug.
>>
>> Ben/Maarten, I'll let you judge whether this check is appropriate,
>> since like I hope I was able to convey above, I'm just not really sure :)
> Not it really isn't appropriate..
>
> You'd have to call call nouveau_vm_map_sg_table instead, the only place that
> doesn't handle that correctly
> is where it's not expected to be called.
>
> Here, have a completely untested patch to fix things...
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
> {
> struct nouveau_framebuffer *nouveau_fb;
> struct drm_gem_object *gem;
> + struct nouveau_bo *nvbo;
> int ret = -ENOMEM;
>
> gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
> if (!gem)
> return ERR_PTR(-ENOENT);
>
> + nvbo = nouveau_gem_object(gem);
> + if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
> + nv_warn(nouveau_drm(dev), "Trying to create a fb in vram with"
> + " valid_domains=%08x\n", nvbo->valid_domains);
> + ret = -EINVAL;
> + goto err_unref;
> + }
> +
Definitely the right idea, we can't handle this case right now.
However, we may someday want/need to be able to scan out of system
memory, so this is the wrong place.
I suspect the correct thing to do (which'll also handle the
"defensive" part) is to bail in nouveau_bo_move() on attempts to move
a DMA-BUF backed object into VRAM.
Sound OK?
Ben.
> nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
> if (!nouveau_fb)
> goto err_unref;
>
> - ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd,
> nouveau_gem_object(gem));
> + ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nvbo);
> if (ret)
> goto err;
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 02/19] video: Add Common Display Framework core
Hi Tomi, On Monday 02 September 2013 11:42:00 Tomi Valkeinen wrote: > On 09/08/13 20:14, Laurent Pinchart wrote: > > The Common Display Framework (CDF) splits display devices in entities > > that interact through an abstract API. Each entity is managed by its own > > driver independently of the other entities, with the framework > > orchestrating interactions. > > > > This commit introduces the CDF core with entity (un)registration and > > core control operations support. > > > > Signed-off-by: Laurent Pinchart > > The media entity code used in CDF needs (at least) MEDIA_CAMERA_SUPPORT > and MEDIA_CONTROLLER to be enabled in the kernel config. These are not > selected/depended upon currently. Good point. I'll select MEDIA_CONTROLLER. > And while MEDIA_CONTROLLER makes sense, MEDIA_CAMERA_SUPPORT doesn't, so > maybe there's some tuning needed for the media code. Agreed, I'll fix that. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: i915.disable_pch_pwm overrides PCH_PWM_ENABLE quirk
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Some BIOS configurations of Dell XPS13 are adversely affected by e85843b
("drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight") so provide a
boot param to inhibit the quirk, or force it on.
i915.disable_pch_pwm can be set to
-1: auto (default; allows the disabling of pch_pwm by dmi quirk table match)
0: inhibits the disabling of pch_pwm (overrides dmi quirk table match)
1: forces the disabling of pch_pwm
Signed-off-by: Kamal Mostafa
---
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 11 ---
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 72e2be7..fee05df 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -154,6 +154,10 @@ module_param_named(prefault_disable,
i915_prefault_disable, bool, 0600);
MODULE_PARM_DESC(prefault_disable,
"Disable page prefaulting for pread/pwrite/reloc
(default:false). For developers only.");
+int i915_disable_pch_pwm __read_mostly = -1;
+module_param_named(disable_pch_pwm, i915_disable_pch_pwm, int, 0600);
+MODULE_PARM_DESC(disable_pch_pwm, "disable PCH_PWM (default: -1 (auto))");
+
static struct drm_driver driver;
extern int intel_agp_enabled;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 769c138..e6f2a34 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1726,6 +1726,7 @@ extern bool i915_fastboot __read_mostly;
extern int i915_enable_pc8 __read_mostly;
extern int i915_pc8_timeout __read_mostly;
extern bool i915_prefault_disable __read_mostly;
+extern int i915_disable_pch_pwm __read_mostly;
extern int i915_suspend(struct drm_device *dev, pm_message_t state);
extern int i915_resume(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 30e5946..86fa722 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9948,9 +9948,8 @@ static void quirk_invert_brightness(struct drm_device
*dev)
*/
static void quirk_no_pcm_pwm_enable(struct drm_device *dev)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
- dev_priv->quirks |= QUIRK_NO_PCH_PWM_ENABLE;
- DRM_INFO("applying no-PCH_PWM_ENABLE quirk\n");
+ if (i915_disable_pch_pwm < 0)
+ i915_disable_pch_pwm = 1;
}
struct intel_quirk {
@@ -10048,6 +10047,12 @@ static void intel_init_quirks(struct drm_device *dev)
if (dmi_check_system(*intel_dmi_quirks[i].dmi_id_list) != 0)
intel_dmi_quirks[i].hook(dev);
}
+
+ if (i915_disable_pch_pwm == 1) {
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ dev_priv->quirks |= QUIRK_NO_PCH_PWM_ENABLE;
+ DRM_INFO("applying no-PCH_PWM_ENABLE quirk\n");
+ }
}
/* Disable the VGA plane that we never use */
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: i915.disable_pch_pwm overrides PCH_PWM_ENABLE quirk
On Tue, 2013-09-03 at 19:50 +0200, Daniel Vetter wrote:
> On Tue, Sep 3, 2013 at 7:37 PM, Kamal Mostafa wrote:
> > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
> >
> > Some BIOS configurations of Dell XPS13 are adversely affected by e85843b
> > ("drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight") so provide a
> > boot param to inhibit the quirk, or force it on.
> >
> > i915.disable_pch_pwm can be set to
> > -1: auto (default; allows the disabling of pch_pwm by dmi quirk table
> > match)
> > 0: inhibits the disabling of pch_pwm (overrides dmi quirk table match)
> > 1: forces the disabling of pch_pwm
> >
> > Signed-off-by: Kamal Mostafa
>
> Nack. Piling quirk over quirk isn't the right approach
I understand your reluctance, but this isn't actually any new quirk
functionality, just a way to manually enable/disable the original
PCH_PWM_ENABLE quirk. I think this is the least crazy approach,
because:
Most XPS13 configurations do need the quirk (and maybe some other yet to
be identified machines also), but dmi matching cannot discern the one
particular XPS13 configuration ("Ivy Bridge booting UEFI mode without
Legacy Option ROM") that is adversely affected by it. We could
alternately consider trying to detect that specific configuration with
code in i915, but that seemed a lot crazier (and less generally useful)
than just providing an override switch for rare or yet-to-be-discovered
configurations.
Hmmm. What if we had a pair of boot params "i915.quirks_set" and
"i915.quirks_mask" boot params that could be used to manually set or
mask _all_ the bits in dev_priv->quirks? Such params would surely come
in handy for cases just like this one, and would be useful for testing
future machines easily. (Would you take that if I submitted it?)
> and I think I
> should just revert the pch_pwm enable quirk again.
> -Daniel
But reverting the original quirk would break ALL the XPS13
configurations, which nobody is requesting. Please don't revert the
quirk. At most, you might want to disable the Ivy Bridge dmi match (but
I don't recommend this either):
/* Dell XPS13 HD and XPS13 FHD Ivy Bridge */
{ 0x0166, 0x1028, 0x058b, quirk_no_pcm_pwm_enable },
-Kamal
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
Thanks Sean,
On 3 September 2013 20:15, Sean Paul wrote:
> A few comments.
>
> On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
> wrote:
>> Exynos hdmiphy operations and configs are kept inside
>> the hdmi driver. Hdmiphy related code is tightly coupled
>> with hdmi IP driver.
>>
>> This patche moves hdmiphy related code to hdmiphy driver.
>
> s/patche/patch
>
ok.
>> It will help in cleanly supporting the hdmiphy variations
>> in further SoCs.
>>
>> Signed-off-by: Rahul Sharma
>> ---
>> .../devicetree/bindings/video/exynos_hdmi.txt |2 +
>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 343 +++
>> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
>> +++-
>> drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
>> 5 files changed, 533 insertions(+), 296 deletions(-)
>> create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> index 50decf8..240eca5 100644
>> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> @@ -25,6 +25,7 @@ Required properties:
>> sclk_pixel.
>> - clock-names: aliases as per driver requirements for above clock IDs:
>> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
>> +- phy: it points to hdmiphy dt node.
>> Example:
>>
>> hdmi {
>> @@ -32,4 +33,5 @@ Example:
>> reg = <0x1453 0x10>;
>> interrupts = <0 95 0>;
>> hpd-gpio = <&gpx3 7 1>;
>> + phy = <&hdmiphy>;
>> };
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> index 724cab1..1c839f8 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> @@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct
>> exynos_drm_hdmi_context *ctx);
>> void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
>> void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
>> void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
>> +
>> +int exynos_hdmiphy_driver_register(void);
>> +void exynos_hdmiphy_driver_unregister(void);
>> +
>> +void exynos_hdmiphy_enable(struct device *dev);
>> +void exynos_hdmiphy_disable(struct device *dev);
>> +int exynos_hdmiphy_check_mode(struct device *dev,
>> + struct drm_display_mode *mode);
>> +int exynos_hdmiphy_set_mode(struct device *dev,
>> + struct drm_display_mode *mode);
>> +int exynos_hdmiphy_conf_apply(struct device *dev);
>> #endif
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index f67ffca..3af4e4c 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -34,6 +34,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #include
>>
>> @@ -172,7 +174,6 @@ struct hdmi_v14_conf {
>> };
>>
>> struct hdmi_conf_regs {
>> - int pixel_clock;
>> int cea_video_id;
>> union {
>> struct hdmi_v13_conf v13_conf;
>> @@ -193,9 +194,9 @@ struct hdmi_context {
>> int irq;
>>
>> struct i2c_client *ddc_port;
>> - struct i2c_client *hdmiphy_port;
>> + struct device *hdmiphy_dev;
>>
>> - /* current hdmiphy conf regs */
>> + /* current hdmi ip configuration registers. */
>> struct hdmi_conf_regs mode_conf;
>>
>> struct hdmi_resources res;
>> @@ -205,180 +206,6 @@ struct hdmi_context {
>> enum hdmi_type type;
>> };
>>
>> -struct hdmiphy_config {
>> - int pixel_clock;
>> - u8 conf[32];
>> -};
>> -
>> -/* list of phy config settings */
>> -static const struct hdmiphy_config hdmiphy_v13_configs[] = {
>> - {
>> - .pixel_clock = 2700,
>> - .conf = {
>> - 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
>> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
>> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
>> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
>> - },
>> - },
>> - {
>> - .pixel_clock = 27027000,
>> - .conf = {
>> - 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
>> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
>> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
>> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
>> - },
>> - },
>> -
re: drm/radeon: add audio support for DCE6/8 GPUs (v12)
Hello Alex Deucher, This is a semi-automatic email about new static checker warnings. The patch b530602fd462: "drm/radeon: add audio support for DCE6/8 GPUs (v12)" from Jul 31, 2013, leads to the following Smatch complaint: drivers/gpu/drm/radeon/dce6_afmt.c:91 dce6_afmt_select_pin() warn: variable dereferenced before check 'dig->afmt->pin' (see line 89) drivers/gpu/drm/radeon/dce6_afmt.c 88 u32 offset = dig->afmt->offset; 89 u32 id = dig->afmt->pin->id; ^^ Patch adds dereference. 90 91 if (!dig->afmt->pin) ^^^ Patch adds check. 92 return; 93 regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm/tegra: Changes for v3.12-rc1
Hi Dave, The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b: Linux 3.11-rc2 (2013-07-21 12:05:29 -0700) are available in the git repository at: git://anongit.freedesktop.org/tegra/linux tags/drm/for-3.12-rc1 for you to fetch changes up to 03da0e7ba9e3a1fc700f60913ff6bcb19f7eac2a: drm/tegra: Parse device tree earlier (2013-09-03 10:10:13 +0200) Thanks, Thierry drm/tegra: Changes for v3.12-rc1 Only a couple of small patches this time around. These are mostly fixes for minor bugs that showed up, but there is also some preparatory work that will come in handy for future patches. Dan Carpenter (2): gpu: host1x: fix an integer overflow check gpu: host1x: returning success instead of -ENOMEM Mikko Perttunen (1): drm/tegra: hdmi: Make sure clock is enabled before dumping registers Thierry Reding (3): gpu: host1x: Check for valid host1x pointer gpu: host1x: Sort drivers by probe order drm/tegra: Parse device tree earlier drivers/gpu/host1x/dev.c | 2 +- drivers/gpu/host1x/dev.h | 2 +- drivers/gpu/host1x/drm/hdmi.c | 7 +++ drivers/gpu/host1x/drm/rgb.c | 14 +++--- drivers/gpu/host1x/job.c | 15 +++ 5 files changed, 23 insertions(+), 17 deletions(-) pgpCkyrZymwRT.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60827] X under radeon driver crashes after resuming from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=60827 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher --- Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60827] X under radeon driver crashes after resuming from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=60827 --- Comment #3 from Alex Deucher --- You might also try a newer kernel. It looks like the uvd ring that is failing to resume properly. There are a number of fixes for suspend/resume related problems with uvd in 3.11 (most of which should end up in stable). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote: > Op 28-08-13 08:29, Pasi Kärkkäinen schreef: > > On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote: > >> On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote: > >>> Op 22-08-13 02:10, Ilia Mirkin schreef: > The code expects non-VRAM mem nodes to have a pages list. If that's not > set, it will do a null deref down the line. Warn on that condition and > return an error. > > See https://bugs.freedesktop.org/show_bug.cgi?id=64774 > > Reported-by: Pasi Kärkkäinen > Tested-by: Pasi Kärkkäinen > Signed-off-by: Ilia Mirkin > Cc: # 3.8+ > --- > > I don't exactly understand what's going on, but this is just a > straightforward way to avoid a null deref that you see happens in the > bug. I haven't figured out the root cause of this, but it's getting > well into the "I have no idea how TTM works" space. However this seems > like a bit of defensive programming -- nouveau_vm_map_sg will pass > node->pages as a list down, which will be dereferenced by > nvc0_vm_map_sg. Perhaps the other arguments should make that > dereferencing not happen, but it definitely was happening here, as you > can see in the bug. > > Ben/Maarten, I'll let you judge whether this check is appropriate, > since like I hope I was able to convey above, I'm just not really sure :) > >>> Not it really isn't appropriate.. > >>> > >>> You'd have to call call nouveau_vm_map_sg_table instead, the only place > >>> that doesn't handle that correctly > >>> is where it's not expected to be called. > >>> > >>> Here, have a completely untested patch to fix things... > >>> > >> Maarten: I've been testing this stuff with Linux 3.10.x, so I had to > >> modify the patch a bit to make it apply there.. > >> I've attached the modified copy that applies to 3.10.9, hopefully I did > >> the backport correctly. > >> > >> With Linux 3.10.9 and the patch applied the kernel doesn't crash anymore, > >> and I get this error in dmesg: > >> > >> [ 76.105643] nouveau W[ DRM] Trying to create a fb in vram with > >> valid_domains=0004 > >> > >> Does that help? > >> > > Any comments? > > > > Maarten's patch works for me, I get that warning instead of a kernel crash, > > but it's also a bigger change that doesn't apply to older kernels as-is. > > > > Ilia's original patch in this thread can be applied to older kernels as-is, > > and it also prevents the kernel crash from happening. > > > > Should we get both applied, so Ilia's patch can be CC'd to stable ? > > > You haven't understood the root cause then. You're trying to move an IMPORTED > dma-buf into VRAM. > Doing so would seem to work, but at that point it's no longer a dma-buf so > changes done by the exporter > would not show up in nouveau because they no longer refer to the same piece > of memory. > Yes, that's true, I don't understand the root cause. That's mostly because I'm not familiar with the nouveau code/internals. > Failing is the only right option here. > Sorry but I'm not sure I understand that correctly.. what exactly do you suggest? What should fail? Because I'm not familiar with the code (yet) understanding and finding the root cause will take time for me.. that's why I was suggesting to meanwhile apply Ilia's very simple patch from this thread which actually prevents the hard kernel crash from happening, because it seems like an unharmful fix to have to protect against this kind of bugs (the root cause) ? Or is that unacceptable? (To recap: The kernel crash happens very often when trying to use the nouveau adapter in Optimus mode, with all kernels at least 3.8+, and it's very annoying that your laptop crashes when trying to enable a nouveau output. So Ilia's patch doesn't make the driver working properly, but at least it prevents the hard kernel crash from happening. The crash bug is in many kernel versions, including the long-term v3.10 tree. I've had the crash happening with 3.8.x, 3.9.x and 3.10.x) All comments welcome. Thanks, -- Pasi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
Op 03-09-13 16:20, Pasi Kärkkäinen schreef: > On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote: >> Op 28-08-13 08:29, Pasi Kärkkäinen schreef: >>> On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote: On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote: > Op 22-08-13 02:10, Ilia Mirkin schreef: >> The code expects non-VRAM mem nodes to have a pages list. If that's not >> set, it will do a null deref down the line. Warn on that condition and >> return an error. >> >> See https://bugs.freedesktop.org/show_bug.cgi?id=64774 >> >> Reported-by: Pasi Kärkkäinen >> Tested-by: Pasi Kärkkäinen >> Signed-off-by: Ilia Mirkin >> Cc: # 3.8+ >> --- >> >> I don't exactly understand what's going on, but this is just a >> straightforward way to avoid a null deref that you see happens in the >> bug. I haven't figured out the root cause of this, but it's getting >> well into the "I have no idea how TTM works" space. However this seems >> like a bit of defensive programming -- nouveau_vm_map_sg will pass >> node->pages as a list down, which will be dereferenced by >> nvc0_vm_map_sg. Perhaps the other arguments should make that >> dereferencing not happen, but it definitely was happening here, as you >> can see in the bug. >> >> Ben/Maarten, I'll let you judge whether this check is appropriate, >> since like I hope I was able to convey above, I'm just not really sure :) > Not it really isn't appropriate.. > > You'd have to call call nouveau_vm_map_sg_table instead, the only place > that doesn't handle that correctly > is where it's not expected to be called. > > Here, have a completely untested patch to fix things... > Maarten: I've been testing this stuff with Linux 3.10.x, so I had to modify the patch a bit to make it apply there.. I've attached the modified copy that applies to 3.10.9, hopefully I did the backport correctly. With Linux 3.10.9 and the patch applied the kernel doesn't crash anymore, and I get this error in dmesg: [ 76.105643] nouveau W[ DRM] Trying to create a fb in vram with valid_domains=0004 Does that help? >>> Any comments? >>> >>> Maarten's patch works for me, I get that warning instead of a kernel crash, >>> but it's also a bigger change that doesn't apply to older kernels as-is. >>> >>> Ilia's original patch in this thread can be applied to older kernels as-is, >>> and it also prevents the kernel crash from happening. >>> >>> Should we get both applied, so Ilia's patch can be CC'd to stable ? >>> >> You haven't understood the root cause then. You're trying to move an >> IMPORTED dma-buf into VRAM. >> Doing so would seem to work, but at that point it's no longer a dma-buf so >> changes done by the exporter >> would not show up in nouveau because they no longer refer to the same piece >> of memory. >> > Yes, that's true, I don't understand the root cause. > That's mostly because I'm not familiar with the nouveau code/internals. > > >> Failing is the only right option here. >> > Sorry but I'm not sure I understand that correctly.. what exactly do you > suggest? What should fail? > > > Because I'm not familiar with the code (yet) understanding and finding the > root cause > will take time for me.. that's why I was suggesting to meanwhile apply Ilia's > very simple patch > from this thread which actually prevents the hard kernel crash from > happening, because it seems > like an unharmful fix to have to protect against this kind of bugs (the root > cause) ? > Or is that unacceptable? > > (To recap: The kernel crash happens very often when trying to use the nouveau > adapter in Optimus mode, with all kernels at least 3.8+, and it's very > annoying that your laptop crashes when trying to enable a nouveau output. So > Ilia's patch doesn't make the driver working properly, but at least it > prevents the hard kernel crash from happening. The crash bug is in many > kernel versions, including the long-term v3.10 tree. I've had the crash > happening with 3.8.x, 3.9.x and 3.10.x) The fix probably requires commit fdfb8332651db7a280851dfccfc4f0cff4bcd052 to apply cleanly "drm/nouveau: fix some error-path leaks in fbcon handling code" > All comments welcome. > > Thanks, > > -- Pasi > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/1] ARM: dts: AM33XX: Add LCDC info into am335x-evm
Hi,
I have not received any feedback on this patch.
It has been pending since the end of June (first post).
Can I get an estimate when it will be included/accepted?
Thanks,
Benoit
On Fri, Aug 23, 2013 at 11:13:56AM -0500, Benoit Parrot wrote:
> Add LCDC device node in DT for am33xx
> Add LCDC and Panel info in DT for am335x-evm
>
> Changes in v3:
> - rebase to 3.11-rc6
>
> Changes in v2:
> - remove redundant/unnecessary SoC specific setting in the board dts
>
> Signed-off-by: Benoit Parrot
> ---
> arch/arm/boot/dts/am335x-evm.dts | 72
> ++
> arch/arm/boot/dts/am33xx.dtsi|9 +
> 2 files changed, 81 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-evm.dts
> b/arch/arm/boot/dts/am335x-evm.dts
> index 3aee1a4..b0703f1 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -149,6 +149,40 @@
> 0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> >;
> };
> +
> + lcd_pins_s0: lcd_pins_s0 {
> + pinctrl-single,pins = <
> + 0x20 0x01 /* gpmc_ad8.lcd_data16, OUTPUT
> | MODE1 */
> + 0x24 0x01 /* gpmc_ad9.lcd_data17, OUTPUT
> | MODE1 */
> + 0x28 0x01 /* gpmc_ad10.lcd_data18, OUTPUT
> | MODE1 */
> + 0x2c 0x01 /* gpmc_ad11.lcd_data19, OUTPUT
> | MODE1 */
> + 0x30 0x01 /* gpmc_ad12.lcd_data20, OUTPUT
> | MODE1 */
> + 0x34 0x01 /* gpmc_ad13.lcd_data21, OUTPUT
> | MODE1 */
> + 0x38 0x01 /* gpmc_ad14.lcd_data22, OUTPUT
> | MODE1 */
> + 0x3c 0x01 /* gpmc_ad15.lcd_data23, OUTPUT
> | MODE1 */
> + 0xa0 0x00 /* lcd_data0.lcd_data0, OUTPUT
> | MODE0 */
> + 0xa4 0x00 /* lcd_data1.lcd_data1, OUTPUT
> | MODE0 */
> + 0xa8 0x00 /* lcd_data2.lcd_data2, OUTPUT
> | MODE0 */
> + 0xac 0x00 /* lcd_data3.lcd_data3, OUTPUT
> | MODE0 */
> + 0xb0 0x00 /* lcd_data4.lcd_data4, OUTPUT
> | MODE0 */
> + 0xb4 0x00 /* lcd_data5.lcd_data5, OUTPUT
> | MODE0 */
> + 0xb8 0x00 /* lcd_data6.lcd_data6, OUTPUT
> | MODE0 */
> + 0xbc 0x00 /* lcd_data7.lcd_data7, OUTPUT
> | MODE0 */
> + 0xc0 0x00 /* lcd_data8.lcd_data8, OUTPUT
> | MODE0 */
> + 0xc4 0x00 /* lcd_data9.lcd_data9, OUTPUT
> | MODE0 */
> + 0xc8 0x00 /* lcd_data10.lcd_data10,
> OUTPUT | MODE0 */
> + 0xcc 0x00 /* lcd_data11.lcd_data11,
> OUTPUT | MODE0 */
> + 0xd0 0x00 /* lcd_data12.lcd_data12,
> OUTPUT | MODE0 */
> + 0xd4 0x00 /* lcd_data13.lcd_data13,
> OUTPUT | MODE0 */
> + 0xd8 0x00 /* lcd_data14.lcd_data14,
> OUTPUT | MODE0 */
> + 0xdc 0x00 /* lcd_data15.lcd_data15,
> OUTPUT | MODE0 */
> + 0xe0 0x00 /* lcd_vsync.lcd_vsync, OUTPUT
> | MODE0 */
> + 0xe4 0x00 /* lcd_hsync.lcd_hsync, OUTPUT
> | MODE0 */
> + 0xe8 0x00 /* lcd_pclk.lcd_pclk, OUTPUT |
> MODE0 */
> + 0xec 0x00 /*
> lcd_ac_bias_en.lcd_ac_bias_en, OUTPUT | MODE0 */
> + >;
> + };
> +
> };
>
> ocp {
> @@ -311,6 +345,10 @@
> };
> };
> };
> +
> + lcdc: lcdc@4830e000 {
> + status = "okay";
> + };
> };
>
> vbat: fixedregulator@0 {
> @@ -374,6 +412,40 @@
> brightness-levels = <0 51 53 56 62 75 101 152 255>;
> default-brightness-level = <8>;
> };
> +
> + panel {
> + compatible = "ti,tilcdc,panel";
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pins_s0>;
> + panel-info {
> + ac-bias = <255>;
> + ac-bias-intrpt= <0>;
> + dma-burst-sz = <16>;
> + bpp = <32>;
> + fdd = <0x80>;
> + sync-edge = <0>;
> + sync-ctrl = <1>;
> + raster-order = <0>;
> + fifo-th = <0>;
> + };
> +
> + display-timings {
> + 800x480p62 {
> +
Re: [PATCH 4/7] drm/exynos: add support for exynos5420 hdmiphy
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Exynos5420 hdmiphy device is a platform device, unlike
> predecessor SoCs where it used to be a I2C device. This
> support is added to the hdmiphy driver.
>
Stuffing a platform driver in the same place as your i2c driver seems
weird. I think you should split them up.
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_hdmiphy.c | 224
> ++-
> 1 file changed, 221 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> index b1b8a0f..33e89d9 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> @@ -32,6 +32,7 @@ struct hdmiphy_context {
>
> /* hdmiphy resources */
> void __iomem*phy_pow_ctrl_reg;
> + void __iomem*regs;
>
> struct hdmiphy_config *confs;
> unsigned intnr_confs;
> @@ -48,6 +49,135 @@ struct hdmiphy_drv_data {
> };
>
> /* list of all required phy config settings */
> +static struct hdmiphy_config hdmiphy_5420_configs[] = {
> + {
> + .pixel_clock = 2520,
> + .conf = {
> + 0x01, 0x52, 0x3F, 0x55, 0x40, 0x01, 0x00, 0xC8,
> + 0x82, 0xC8, 0xBD, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x06, 0x80, 0x01, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xF4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 2700,
> + .conf = {
> + 0x01, 0xD1, 0x22, 0x51, 0x40, 0x08, 0xFC, 0xE0,
> + 0x98, 0xE8, 0xCB, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x06, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xE4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 27027000,
> + .conf = {
> + 0x01, 0xD1, 0x2D, 0x72, 0x40, 0x64, 0x12, 0xC8,
> + 0x43, 0xE8, 0x0E, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x06, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xE3, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 3600,
> + .conf = {
> + 0x01, 0x51, 0x2D, 0x55, 0x40, 0x40, 0x00, 0xC8,
> + 0x02, 0xC8, 0x0E, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xAB, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 4000,
> + .conf = {
> + 0x01, 0xD1, 0x21, 0x31, 0x40, 0x3C, 0x28, 0xC8,
> + 0x87, 0xE8, 0xC8, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0x9A, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 6500,
> + .conf = {
> + 0x01, 0xD1, 0x36, 0x34, 0x40, 0x0C, 0x04, 0xC8,
> + 0x82, 0xE8, 0x45, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xBD, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 7100,
> + .conf = {
> + 0x01, 0xD1, 0x3B, 0x35, 0x40, 0x0C, 0x04, 0xC8,
> + 0x85, 0xE8, 0x63, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0x57, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 74176000,
> + .conf = {
> + 0x01, 0xD1, 0x1F, 0x10, 0x40, 0x5B, 0xEF, 0xC8,
> + 0x81, 0xE8, 0xB9, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x56, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xA6, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 7425,
> + .conf = {
> + 0x01, 0xD1, 0x1F, 0x10, 0x40, 0x40, 0xF8, 0xC8,
> + 0x81, 0xE8, 0xBA, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x56, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xA5, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 8350,
> + .conf = {
> + 0x01, 0xD1, 0x
Re: [RFC 01/10] drm: ADV7511 i2c HDMI encoder driver
Hi Lars-Peter, (CC'ing Hans Verkuil and the dri-devel and linux-media mailing lists) On Monday 02 September 2013 17:09:11 Lars-Peter Clausen wrote: > On 09/02/2013 05:01 PM, Laurent Pinchart wrote: > > On Monday 02 September 2013 16:43:25 Lars-Peter Clausen wrote: > >> On 09/02/2013 04:15 PM, Laurent Pinchart wrote: > >>> On Monday 02 September 2013 15:40:22 Lars-Peter Clausen wrote: > On 09/02/2013 03:18 PM, Laurent Pinchart wrote: > > On Friday 30 August 2013 14:37:35 Ulrich Hecht wrote: > >> ADV7511 driver snapshot taken from commit f416e32 of xcomm_zynq_3_10 > >> branch at https://github.com/analogdevicesinc/linux.git > > > > I believe Lars-Peter (CC'ed) was planning to upstream the driver. > > Lars-Peter, could you please share your plans ? > > My plan was to have all this upstream long time ago ;) > > As I said in that other thread, I don't think it is a good idea to have > two drivers for the same device. But if nobody else sees a problem with > this and as long as the v4l driver doesn't have devicetree support I > guess we could get away with it for now. Even if it will probably haunt > us later on. > > There are still a few minor bits and pieces to iron out, but lets try > to aim for 2.6.13. > >>> > >>> If you can make it for 2.6.13 I will be extremely impressed :-) > >> > >> Yea, I know DRM always takes a bit longer... > > > > I think you meant 3.13 ;-) > > > >>> Do you plan to push the driver yourself ? If so, I would appreciate if > >>> you could CC me. If there's just a few minor bits to iron out I can > >>> already review your latest version if that can help. > >> > >> There are a couple of style issues, so if you review the driver ignore > >> these for now, but otherwise feedback is welcome, thanks. And I'm not > >> also quite happy with the ASoC integration yet. I'll thus concentrate on the video part in the review. Any chance to get the video portion to mainline first and then add audio support ? > > Sure. Is the version available from the above branch the latest version ? > > Yes, you can find it here: > https://github.com/analogdevicesinc/linux/tree/xcomm_zynq/drivers/gpu/drm/ > i2c Thank you. > Oh and the DT bindings also still need proper documentation. I've squashed all the patches together and have copied the result below. > From f7c27f204cab3d7dcaa128880c0d9ef1ae0e2fc6 Mon Sep 17 00:00:00 2001 > From: Lars-Peter Clausen > Date: Mon, 5 Mar 2012 16:30:57 +0100 > Subject: [PATCH] DRM: Add adv7511 encoder driver > > This patch adds a driver for the Analog Devices adv7511. The adv7511 is a > standalone HDMI transmitter chip. It features a HDMI output interface on one > end and video and audio input interfaces on the other. > > Signed-off-by: Lars-Peter Clausen > --- > drivers/gpu/drm/Kconfig | 6 + > drivers/gpu/drm/i2c/Makefile| 3 + > drivers/gpu/drm/i2c/adv7511.h | 454 + > drivers/gpu/drm/i2c/adv7511_audio.c | 304 +++ > drivers/gpu/drm/i2c/adv7511_core.c | 979 + > 5 files changed, 1746 insertions(+) > create mode 100644 drivers/gpu/drm/i2c/adv7511.h > create mode 100644 drivers/gpu/drm/i2c/adv7511_audio.c > create mode 100644 drivers/gpu/drm/i2c/adv7511_core.c First of all, please run checkpatch.pl on the code :-) > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 626bc0c..d8862a4 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -200,6 +200,12 @@ config DRM_SAVAGE > Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister > chipset. If M is selected the module will be called savage. > > +config DRM_ENCODER_ADV7511 > + tristate "AV7511 encoder" > + depends on DRM && I2C > + select REGMAP_I2C > + select HDMI Beside adding a help text, you should also depend on and/or select SND_SOC. > + > source "drivers/gpu/drm/exynos/Kconfig" > > source "drivers/gpu/drm/vmwgfx/Kconfig" [snip] > diff --git a/drivers/gpu/drm/i2c/adv7511.h b/drivers/gpu/drm/i2c/adv7511.h > new file mode 100644 > index 000..4631fcd6 > --- /dev/null > +++ b/drivers/gpu/drm/i2c/adv7511.h > @@ -0,0 +1,454 @@ > +/** > + * Analog Devices ADV7511 HDMI transmitter driver > + * > + * Copyright 2012 Analog Devices Inc. > + * > + * Licensed under the GPL-2. > + */ > + > +#ifndef __ADV7511_H__ > +#define __ADV7511_H__ > + > +#include This file should be split in two headers, one with platform data that will go to include/linux/platform_data/, and another one that can stay here. > +#define ADV7511_REG_CHIP_REVISION0x00 > +#define ADV7511_REG_N0 0x01 > +#define ADV7511_REG_N1 0x02 > +#define ADV7511_REG_N2 0x03 > +#define ADV7511_REG_SPDIF_FREQ 0x04 > +#define ADV7511_REG_CTS_AUTOMATIC1 0x05 > +#
Re: [PATCH 3/7] drm/exynos: add hdmiphy pmu bit control in hdmiphy driver
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Before hdmiphy operation like config, start etc, hdmiphy
> bit in PMU block should be enabled. Earlier this happens
> in hdmi drvier through a dummy "hdmiphy" clock.
s/drvier/driver/
>
> Signed-off-by: Rahul Sharma
> ---
> .../devicetree/bindings/video/exynos_hdmiphy.txt |6 ++
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 +
> drivers/gpu/drm/exynos/exynos_hdmi.c |2 +
> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 82
>
> 4 files changed, 92 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> index 162f641..f6bf096 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -6,10 +6,16 @@ Required properties:
> 2) "samsung,exynos4210-hdmiphy".
> 3) "samsung,exynos4212-hdmiphy".
> - reg: I2C address of the hdmiphy device.
> +- phy-power-control: this child node represents phy power control
> + register which is inside the pmu block (power management unit).
Should you include devicetree-discuss on this?
>
> Example:
>
> hdmiphy {
> compatible = "samsung,exynos4210-hdmiphy";
> reg = <0x38>;
> +
> + phy-power-control {
> + reg = <0x10040700 0x04>;
> + };
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> index 1c839f8..9a14f96 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> @@ -68,6 +68,8 @@ void exynos_mixer_ops_register(struct exynos_mixer_ops
> *ops);
> int exynos_hdmiphy_driver_register(void);
> void exynos_hdmiphy_driver_unregister(void);
>
> +void exynos_hdmiphy_poweron(struct device *dev);
> +void exynos_hdmiphy_poweroff(struct device *dev);
> void exynos_hdmiphy_enable(struct device *dev);
> void exynos_hdmiphy_disable(struct device *dev);
> int exynos_hdmiphy_check_mode(struct device *dev,
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index cd1d921..a6234fc 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1131,6 +1131,7 @@ static void hdmiphy_poweron(struct hdmi_context *hdata)
> if (hdata->type == HDMI_TYPE14)
> hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, 0,
> HDMI_PHY_POWER_OFF_EN);
> + exynos_hdmiphy_poweron(hdata->hdmiphy_dev);
> }
>
> static void hdmiphy_poweroff(struct hdmi_context *hdata)
> @@ -1138,6 +1139,7 @@ static void hdmiphy_poweroff(struct hdmi_context *hdata)
> if (hdata->type == HDMI_TYPE14)
> hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, ~0,
> HDMI_PHY_POWER_OFF_EN);
> + exynos_hdmiphy_poweroff(hdata->hdmiphy_dev);
Shouldn't the phy power off before HDMI?
> }
>
> static void hdmi_conf_apply(struct hdmi_context *hdata)
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> index 82daa42..b1b8a0f 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> @@ -30,6 +30,9 @@ struct hdmiphy_context {
> struct device *dev;
> struct hdmiphy_config *current_conf;
>
> + /* hdmiphy resources */
> + void __iomem*phy_pow_ctrl_reg;
> +
> struct hdmiphy_config *confs;
> unsigned intnr_confs;
> };
> @@ -225,6 +228,49 @@ static struct hdmiphy_config *hdmiphy_find_conf(struct
> hdmiphy_context *hdata,
> return NULL;
> }
>
> +static int hdmiphy_dt_parse_power_control(struct hdmiphy_context *hdata)
> +{
> + struct device_node *phy_pow_ctrl_node;
> + u32 buf[2];
> + int ret = 0;
> +
> + phy_pow_ctrl_node = of_get_child_by_name(hdata->dev->of_node,
> + "phy-power-control");
> + if (!phy_pow_ctrl_node) {
> + DRM_ERROR("Failed to find phy power control node\n");
> + ret = -ENODEV;
> + goto fail;
You can just return -ENODEV here.
> + }
> +
> + /* reg property holds two informations: addr of pmu register, size */
> + if (of_property_read_u32_array(phy_pow_ctrl_node, "reg",
> + (u32 *)&buf, 2)) {
Maybe I'm missing something, but this looks bad. I think this should be:
of_property_read_u32_array(phy_pow_ctrl_node, "reg", buf, ARRAY_SIZE(buf))
ie: dereferencing buf won't do what you expect it to.
> + DRM_ERROR("faild to get phy power control reg\n");
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + hdata->phy_pow_ctrl_reg = devm_ioremap(hdata->dev, buf[0], buf[1]);
>
Re: [PATCH 2/7] drm/exynos: remove dummy hdmiphy clock
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> hdmiphy is a dummy clock which actually controls the PMU bit
> to enable/disbale hdmiphy (before CCF). This clock is cleaned
s/disbale/disable/
> from the hdmi driver.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c |8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 3af4e4c..cd1d921 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -84,7 +84,6 @@ struct hdmi_resources {
> struct clk *sclk_hdmi;
> struct clk *sclk_pixel;
> struct clk *sclk_hdmiphy;
> - struct clk *hdmiphy;
> struct clk *mout_hdmi;
> struct regulator_bulk_data *regul_bulk;
> int regul_count;
> @@ -1431,7 +1430,6 @@ static void hdmi_poweron(struct hdmi_context *hdata)
> if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
> DRM_DEBUG_KMS("failed to enable regulator bulk\n");
>
> - clk_prepare_enable(res->hdmiphy);
> clk_prepare_enable(res->hdmi);
> clk_prepare_enable(res->sclk_hdmi);
>
> @@ -1456,7 +1454,6 @@ static void hdmi_poweroff(struct hdmi_context *hdata)
>
> clk_disable_unprepare(res->sclk_hdmi);
> clk_disable_unprepare(res->hdmi);
> - clk_disable_unprepare(res->hdmiphy);
> regulator_bulk_disable(res->regul_count, res->regul_bulk);
>
> mutex_lock(&hdata->hdmi_mutex);
> @@ -1549,11 +1546,6 @@ static int hdmi_resources_init(struct hdmi_context
> *hdata)
> DRM_ERROR("failed to get clock 'sclk_hdmiphy'\n");
> goto fail;
> }
> - res->hdmiphy = devm_clk_get(dev, "hdmiphy");
> - if (IS_ERR(res->hdmiphy)) {
> - DRM_ERROR("failed to get clock 'hdmiphy'\n");
> - goto fail;
> - }
> res->mout_hdmi = devm_clk_get(dev, "mout_hdmi");
> if (IS_ERR(res->mout_hdmi)) {
> DRM_ERROR("failed to get clock 'mout_hdmi'\n");
> --
> 1.7.10.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Tue, Sep 03, 2013 at 04:34:56PM +0200, Maarten Lankhorst wrote: > Op 03-09-13 16:20, Pasi Kärkkäinen schreef: > > On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote: > >> Op 28-08-13 08:29, Pasi Kärkkäinen schreef: > >>> On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote: > On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote: > > Op 22-08-13 02:10, Ilia Mirkin schreef: > >> The code expects non-VRAM mem nodes to have a pages list. If that's not > >> set, it will do a null deref down the line. Warn on that condition and > >> return an error. > >> > >> See https://bugs.freedesktop.org/show_bug.cgi?id=64774 > >> > >> Reported-by: Pasi Kärkkäinen > >> Tested-by: Pasi Kärkkäinen > >> Signed-off-by: Ilia Mirkin > >> Cc: # 3.8+ > >> --- > >> > >> I don't exactly understand what's going on, but this is just a > >> straightforward way to avoid a null deref that you see happens in the > >> bug. I haven't figured out the root cause of this, but it's getting > >> well into the "I have no idea how TTM works" space. However this seems > >> like a bit of defensive programming -- nouveau_vm_map_sg will pass > >> node->pages as a list down, which will be dereferenced by > >> nvc0_vm_map_sg. Perhaps the other arguments should make that > >> dereferencing not happen, but it definitely was happening here, as you > >> can see in the bug. > >> > >> Ben/Maarten, I'll let you judge whether this check is appropriate, > >> since like I hope I was able to convey above, I'm just not really sure > >> :) > > Not it really isn't appropriate.. > > > > You'd have to call call nouveau_vm_map_sg_table instead, the only place > > that doesn't handle that correctly > > is where it's not expected to be called. > > > > Here, have a completely untested patch to fix things... > > > Maarten: I've been testing this stuff with Linux 3.10.x, so I had to > modify the patch a bit to make it apply there.. > I've attached the modified copy that applies to 3.10.9, hopefully I did > the backport correctly. > > With Linux 3.10.9 and the patch applied the kernel doesn't crash > anymore, and I get this error in dmesg: > > [ 76.105643] nouveau W[ DRM] Trying to create a fb in vram with > valid_domains=0004 > > Does that help? > > >>> Any comments? > >>> > >>> Maarten's patch works for me, I get that warning instead of a kernel > >>> crash, > >>> but it's also a bigger change that doesn't apply to older kernels as-is. > >>> > >>> Ilia's original patch in this thread can be applied to older kernels > >>> as-is, > >>> and it also prevents the kernel crash from happening. > >>> > >>> Should we get both applied, so Ilia's patch can be CC'd to stable ? > >>> > >> You haven't understood the root cause then. You're trying to move an > >> IMPORTED dma-buf into VRAM. > >> Doing so would seem to work, but at that point it's no longer a dma-buf so > >> changes done by the exporter > >> would not show up in nouveau because they no longer refer to the same > >> piece of memory. > >> > > Yes, that's true, I don't understand the root cause. > > That's mostly because I'm not familiar with the nouveau code/internals. > > > > > >> Failing is the only right option here. > >> > > Sorry but I'm not sure I understand that correctly.. what exactly do you > > suggest? What should fail? > > > > > > Because I'm not familiar with the code (yet) understanding and finding the > > root cause > > will take time for me.. that's why I was suggesting to meanwhile apply > > Ilia's very simple patch > > from this thread which actually prevents the hard kernel crash from > > happening, because it seems > > like an unharmful fix to have to protect against this kind of bugs (the > > root cause) ? > > Or is that unacceptable? > > > > (To recap: The kernel crash happens very often when trying to use the > > nouveau adapter in Optimus mode, with all kernels at least 3.8+, and it's > > very annoying that your laptop crashes when trying to enable a nouveau > > output. So Ilia's patch doesn't make the driver working properly, but at > > least it prevents the hard kernel crash from happening. The crash bug is in > > many kernel versions, including the long-term v3.10 tree. I've had the > > crash happening with 3.8.x, 3.9.x and 3.10.x) > > The fix probably requires commit fdfb8332651db7a280851dfccfc4f0cff4bcd052 to > apply cleanly "drm/nouveau: fix some error-path leaks in fbcon handling code" > So what you mean is to use fdfb8332651db7a280851dfccfc4f0cff4bcd052 and your patch from this thread? and skip Ilia's patch? -- Pasi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
A few comments.
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Exynos hdmiphy operations and configs are kept inside
> the hdmi driver. Hdmiphy related code is tightly coupled
> with hdmi IP driver.
>
> This patche moves hdmiphy related code to hdmiphy driver.
s/patche/patch
> It will help in cleanly supporting the hdmiphy variations
> in further SoCs.
>
> Signed-off-by: Rahul Sharma
> ---
> .../devicetree/bindings/video/exynos_hdmi.txt |2 +
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
> drivers/gpu/drm/exynos/exynos_hdmi.c | 343 +++
> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
> +++-
> drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
> 5 files changed, 533 insertions(+), 296 deletions(-)
> create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 50decf8..240eca5 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -25,6 +25,7 @@ Required properties:
> sclk_pixel.
> - clock-names: aliases as per driver requirements for above clock IDs:
> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
> +- phy: it points to hdmiphy dt node.
> Example:
>
> hdmi {
> @@ -32,4 +33,5 @@ Example:
> reg = <0x1453 0x10>;
> interrupts = <0 95 0>;
> hpd-gpio = <&gpx3 7 1>;
> + phy = <&hdmiphy>;
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> index 724cab1..1c839f8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> @@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context
> *ctx);
> void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
> void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
> void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
> +
> +int exynos_hdmiphy_driver_register(void);
> +void exynos_hdmiphy_driver_unregister(void);
> +
> +void exynos_hdmiphy_enable(struct device *dev);
> +void exynos_hdmiphy_disable(struct device *dev);
> +int exynos_hdmiphy_check_mode(struct device *dev,
> + struct drm_display_mode *mode);
> +int exynos_hdmiphy_set_mode(struct device *dev,
> + struct drm_display_mode *mode);
> +int exynos_hdmiphy_conf_apply(struct device *dev);
> #endif
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index f67ffca..3af4e4c 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -34,6 +34,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -172,7 +174,6 @@ struct hdmi_v14_conf {
> };
>
> struct hdmi_conf_regs {
> - int pixel_clock;
> int cea_video_id;
> union {
> struct hdmi_v13_conf v13_conf;
> @@ -193,9 +194,9 @@ struct hdmi_context {
> int irq;
>
> struct i2c_client *ddc_port;
> - struct i2c_client *hdmiphy_port;
> + struct device *hdmiphy_dev;
>
> - /* current hdmiphy conf regs */
> + /* current hdmi ip configuration registers. */
> struct hdmi_conf_regs mode_conf;
>
> struct hdmi_resources res;
> @@ -205,180 +206,6 @@ struct hdmi_context {
> enum hdmi_type type;
> };
>
> -struct hdmiphy_config {
> - int pixel_clock;
> - u8 conf[32];
> -};
> -
> -/* list of phy config settings */
> -static const struct hdmiphy_config hdmiphy_v13_configs[] = {
> - {
> - .pixel_clock = 2700,
> - .conf = {
> - 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
> - },
> - },
> - {
> - .pixel_clock = 27027000,
> - .conf = {
> - 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
> - },
> - },
> - {
> - .pixel_clock = 74176000,
> - .conf = {
> - 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef, 0x5B,
> - 0x6D, 0x10, 0x01, 0x51, 0
[Bug 68857] SNU OpenCL NAS Parallel Benchmarks don't work
https://bugs.freedesktop.org/show_bug.cgi?id=68857 --- Comment #1 from Tom Stellard --- I'm having a little trouble figuring out the build system for this suite, could you pick one of the failing examples and give instructions for how to build and execute it? Also, what version of Mesa and LLVM are you using? I recommend using the development versions of both for best results. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68901] New: wine/3DMark2001: shader generation fails
https://bugs.freedesktop.org/show_bug.cgi?id=68901 Priority: medium Bug ID: 68901 Keywords: regression Assignee: dri-devel@lists.freedesktop.org Summary: wine/3DMark2001: shader generation fails Severity: normal Classification: Unclassified OS: Linux (All) Reporter: gurket...@googlemail.com URL: http://www.futuremark.com/support/downloads Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa When running 3DMark2001 in wine (1.7.1), the r600 gallium driver (on RV710) fails to generate some shaders. This is a regression: 3f67251e3d0ce61a0e7fc16de91de6fb49cad768 is the first bad commit commit 3f67251e3d0ce61a0e7fc16de91de6fb49cad768 Author: Christian König Date: Sun Mar 10 14:33:29 2013 +0100 glsl_to_tgsi: allocate arrays separately v2 Instead of allocating everything as temporaries, use the new array allocation functions. v2: fix bug in simplify_cmp, declare arrays on demand Signed-off-by: Christian König :04 04 75a734fc12e314c32a959f4111543ec518cb8a51 57eed35384ed9aadd89adfce1a075b4ad0a745cc Msrc The output when the shader generation fails is: EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_shader.c:1886 r600_shader_from_tgsi - GPR limit exceeded - shader requires 129 registers EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_shader.c:134 r600_pipe_shader_create - translation from TGSI failed ! EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_state_common.c:750 r600_shader_select - Failed to build shader variant (type=0) -12 EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_shader.c:1886 r600_shader_from_tgsi - GPR limit exceeded - shader requires 129 registers EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_shader.c:134 r600_pipe_shader_create - translation from TGSI failed ! EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_state_common.c:750 r600_shader_select - Failed to build shader variant (type=0) -12 This is not a dupe of bug 62696 as the problem is still there with git version 6b5c802c30ada043ee31cc5e62249ff99bbc865f. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 2/3] drm/panel: Add simple panel support
On 08/30/2013 09:25 AM, Thierry Reding wrote: > Add a driver for simple panels. Such panels can have a regulator that > provides the supply voltage and a separate GPIO to enable the panel. > Optionally the panels can have a backlight associated with them so it > can be enabled or disabled according to the panel's power management > mode. > diff --git a/Documentation/devicetree/bindings/panel/panel-simple.txt > b/Documentation/devicetree/bindings/panel/panel-simple.txt > +Simple display panel > + > +Required properties: > +- compatible: should be one of: > + - "auo,b101aw03": AU Optronics Corporation 10.1" WSVGA TFT LCD panel > + - "cptt,claa101wb03": Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel > + - "pc,vvx10f004b00": Panasonic Corporation 10.1" WUXGA TFT LCD panel > + > +Optional properties: > +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing > +- power-supply: regulator to provide the supply voltage > +- enable-gpios: GPIO pin to enable or disable the panel > +- backlight: phandle of the backlight device attached to the panel Do we need to represent the timing requirements e.g. between panel enable and backlight enable, or do you expect the driver to hard-code this based on the compatible value? Looking at the driver code, it seems that it has direct knowledge of the video mode that each panel supports, so DDC is actually optional unlike what I asserted/assumed in my previous response. As such, I guess we should have a separate DT binding document for each of the three panels (compatible values) listed above that pretty much just says "go look at simple-panel.txt". ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: i915.disable_pch_pwm overrides PCH_PWM_ENABLE quirk
On Tue, Sep 3, 2013 at 7:37 PM, Kamal Mostafa wrote:
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
>
> Some BIOS configurations of Dell XPS13 are adversely affected by e85843b
> ("drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight") so provide a
> boot param to inhibit the quirk, or force it on.
>
> i915.disable_pch_pwm can be set to
> -1: auto (default; allows the disabling of pch_pwm by dmi quirk table match)
> 0: inhibits the disabling of pch_pwm (overrides dmi quirk table match)
> 1: forces the disabling of pch_pwm
>
> Signed-off-by: Kamal Mostafa
Nack. Piling quirk over quirk isn't the right approach and I think I
should just revert the pch_pwm enable quirk again.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 2/3] drm/panel: Add simple panel support
On 08/30/2013 01:24 PM, Kumar Gala wrote: > > On Aug 30, 2013, at 10:25 AM, Thierry Reding wrote: > >> Add a driver for simple panels. Such panels can have a regulator that >> provides the supply voltage and a separate GPIO to enable the panel. >> Optionally the panels can have a backlight associated with them so it >> can be enabled or disabled according to the panel's power management >> mode. >> >> Support is added for three panels: An AU Optronics 10.1" WSVGA, a >> Chunghwa Picture Tubes 10.1" WXGA and a Panasonic 10.1 WUXGA TFT LCD >> panel. >> diff --git a/Documentation/devicetree/bindings/panel/panel-simple.txt >> b/Documentation/devicetree/bindings/panel/panel-simple.txt >> +Required properties: >> +- compatible: should be one of: >> + - "auo,b101aw03": AU Optronics Corporation 10.1" WSVGA TFT LCD panel >> + - "cptt,claa101wb03": Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel >> + - "pc,vvx10f004b00": Panasonic Corporation 10.1" WUXGA TFT LCD panel >> + > > It would seem there should be a more generic compatible to cover the basic > "panel-simple" case. I would suggest only documenting "simple-panel" here, and not documenting the specific panels at all; the panel-specific compatible values would show up simply due to the rule that all compatible values in *.dts should contain the exact HW model (e.g. "auo,b101aw03"), plus any HW they're compatible with (i.e. "simple-panel"). I'd suggest "simple-panel" rather than "panel-simple" since IIRC other simple bindings are "simple-xxx" rather than "xxx-simple". >> +Optional properties: >> +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing >> +- power-supply: regulator to provide the supply voltage >> +- enable-gpios: GPIO pin to enable or disable the panel >> +- backlight: phandle of the backlight device attached to the panel >> + > > If these are all optional, what does it mean to be a "panel-simple"? I think at least ddc-i2c-bus and backlight should be required properties. I suppose it might be possible for the panel to be always-on, and hence enable-gpios/power-supply could be optional? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Tue, Sep 03, 2013 at 05:48:48PM +0300, Pasi Kärkkäinen wrote:
> > > Not it really isn't appropriate..
> > >
> > > You'd have to call call nouveau_vm_map_sg_table instead, the only
> > > place that doesn't handle that correctly
> > > is where it's not expected to be called.
> > >
> > > Here, have a completely untested patch to fix things...
> > >
> > Maarten: I've been testing this stuff with Linux 3.10.x, so I had to
> > modify the patch a bit to make it apply there..
> > I've attached the modified copy that applies to 3.10.9, hopefully I
> > did the backport correctly.
> >
> > With Linux 3.10.9 and the patch applied the kernel doesn't crash
> > anymore, and I get this error in dmesg:
> >
> > [ 76.105643] nouveau W[ DRM] Trying to create a fb in vram with
> > valid_domains=0004
> >
> > Does that help?
> >
> > >>> Any comments?
> > >>>
> > >>> Maarten's patch works for me, I get that warning instead of a kernel
> > >>> crash,
> > >>> but it's also a bigger change that doesn't apply to older kernels
> > >>> as-is.
> > >>>
> > >>> Ilia's original patch in this thread can be applied to older kernels
> > >>> as-is,
> > >>> and it also prevents the kernel crash from happening.
> > >>>
> > >>> Should we get both applied, so Ilia's patch can be CC'd to stable ?
> > >>>
> > >> You haven't understood the root cause then. You're trying to move an
> > >> IMPORTED dma-buf into VRAM.
> > >> Doing so would seem to work, but at that point it's no longer a dma-buf
> > >> so changes done by the exporter
> > >> would not show up in nouveau because they no longer refer to the same
> > >> piece of memory.
> > >>
> > > Yes, that's true, I don't understand the root cause.
> > > That's mostly because I'm not familiar with the nouveau code/internals.
> > >
> > >
> > >> Failing is the only right option here.
> > >>
> > > Sorry but I'm not sure I understand that correctly.. what exactly do you
> > > suggest? What should fail?
> > >
> > >
> > > Because I'm not familiar with the code (yet) understanding and finding
> > > the root cause
> > > will take time for me.. that's why I was suggesting to meanwhile apply
> > > Ilia's very simple patch
> > > from this thread which actually prevents the hard kernel crash from
> > > happening, because it seems
> > > like an unharmful fix to have to protect against this kind of bugs (the
> > > root cause) ?
> > > Or is that unacceptable?
> > >
> > > (To recap: The kernel crash happens very often when trying to use the
> > > nouveau adapter in Optimus mode, with all kernels at least 3.8+, and it's
> > > very annoying that your laptop crashes when trying to enable a nouveau
> > > output. So Ilia's patch doesn't make the driver working properly, but at
> > > least it prevents the hard kernel crash from happening. The crash bug is
> > > in many kernel versions, including the long-term v3.10 tree. I've had the
> > > crash happening with 3.8.x, 3.9.x and 3.10.x)
> >
> > The fix probably requires commit fdfb8332651db7a280851dfccfc4f0cff4bcd052
> > to apply cleanly "drm/nouveau: fix some error-path leaks in fbcon handling
> > code"
> >
>
> So what you mean is to use fdfb8332651db7a280851dfccfc4f0cff4bcd052 and your
> patch from this thread?
> and skip Ilia's patch?
>
So I tested with Linux 3.10.10. I had to apply these two patches first:
1e2bd5f53b6282e711e9f074765911868f8e7dc1 drm/nouveau: fixup fbcon failure paths
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=1e2bd5f53b6282e711e9f074765911868f8e7dc1
fdfb8332651db7a280851dfccfc4f0cff4bcd052 drm/nouveau: fix some error-path leaks
in fbcon handling code
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=fdfb8332651db7a280851dfccfc4f0cff4bcd052
And with those applied I was able to apply Maarten's patch cleanly (also
attached to this email).
It's worth noting that I'm able to reproduce the kernel crash bug with Fedora
18 (which has xorg-1.13),
but I'm not able to reproduce it with Fedora 19 (which has xorg-1.14). Both
running the same kernel.
Optimus enabled in BIOS on Lenovo T430 laptop. Nvidia GF108 Discreet GPU with
Intel integrated GPU.
Maarten's patch fixes the kernel crash problem, and produces a warning message
instead in dmesg.
You can add my Tested-By to the patch, assuming Maarten's patch is going to be
merged?
Thanks,
-- Pasi
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
{
struct nouveau_framebuffer *nouveau_fb;
struct drm_gem_object *gem;
+ struct nouveau_bo *nvbo;
int ret = -ENOMEM;
gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
if (!gem)
return ERR_PTR(-ENOENT);
+ nvbo = nouv
[PATCH] drm/radeon: add a connector property for audio
This provides a connector property to enable/disable hdmi
audio on the fly. The default is disabled, but you can select
auto (let the driver detect an audio capable monitor and enable it)
or enabled (force audio enabled). This also enables audio by
default so you no longer need a module parameter to enable audio.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 15 --
drivers/gpu/drm/radeon/radeon_connectors.c | 33 ++
drivers/gpu/drm/radeon/radeon_display.c| 12 +++
drivers/gpu/drm/radeon/radeon_drv.c| 2 +-
drivers/gpu/drm/radeon/radeon_mode.h | 9
5 files changed, 64 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index dfac796..9166e0b 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -707,8 +707,9 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
switch (connector->connector_type) {
case DRM_MODE_CONNECTOR_DVII:
case DRM_MODE_CONNECTOR_HDMIB: /* HDMI-B is basically DL-DVI; analog
works fine */
- if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
- radeon_audio)
+ if ((radeon_connector->audio == RADEON_AUDIO_ENABLE) ||
+ (drm_detect_hdmi_monitor(radeon_connector->edid) &&
+(radeon_connector->audio == RADEON_AUDIO_AUTO)))
return ATOM_ENCODER_MODE_HDMI;
else if (radeon_connector->use_digital)
return ATOM_ENCODER_MODE_DVI;
@@ -718,8 +719,9 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
case DRM_MODE_CONNECTOR_DVID:
case DRM_MODE_CONNECTOR_HDMIA:
default:
- if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
- radeon_audio)
+ if ((radeon_connector->audio == RADEON_AUDIO_ENABLE) ||
+ (drm_detect_hdmi_monitor(radeon_connector->edid) &&
+(radeon_connector->audio == RADEON_AUDIO_AUTO)))
return ATOM_ENCODER_MODE_HDMI;
else
return ATOM_ENCODER_MODE_DVI;
@@ -732,8 +734,9 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
if ((dig_connector->dp_sink_type ==
CONNECTOR_OBJECT_ID_DISPLAYPORT) ||
(dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_eDP))
return ATOM_ENCODER_MODE_DP;
- else if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
-radeon_audio)
+ else if ((radeon_connector->audio == RADEON_AUDIO_ENABLE) ||
+(drm_detect_hdmi_monitor(radeon_connector->edid) &&
+ (radeon_connector->audio == RADEON_AUDIO_AUTO)))
return ATOM_ENCODER_MODE_HDMI;
else
return ATOM_ENCODER_MODE_DVI;
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 2399f25..cbbdc85 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -396,6 +396,21 @@ static int radeon_connector_set_property(struct
drm_connector *connector, struct
}
}
+ if (property == rdev->mode_info.audio_property) {
+ struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
+ /* need to find digital encoder on connector */
+ encoder = radeon_find_encoder(connector, DRM_MODE_ENCODER_TMDS);
+ if (!encoder)
+ return 0;
+
+ radeon_encoder = to_radeon_encoder(encoder);
+
+ if (radeon_connector->audio != val) {
+ radeon_connector->audio = val;
+ radeon_property_change_mode(&radeon_encoder->base);
+ }
+ }
+
if (property == rdev->mode_info.underscan_property) {
/* need to find digital encoder on connector */
encoder = radeon_find_encoder(connector, DRM_MODE_ENCODER_TMDS);
@@ -1619,6 +1634,9 @@ radeon_add_atom_connector(struct drm_device *dev,
drm_object_attach_property(&radeon_connector->base.base,
rdev->mode_info.underscan_vborder_property,
0);
+ drm_object_attach_property(&radeon_connector->base.base,
+
rdev->mode_info.audio_property,
+ RADEON_AUDIO_DISABLE);
subpixel_order = SubPixelHorizontalRGB;
connector->interlace_allowed = true;
if (connector_type ==
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #101 from Alex Deucher --- (In reply to comment #96) > Not so fast fellas. Recently checked 3.11RC7 and DRM-Next (current). The > result is the same: it still can't boot with my Radeon HD 2600 XT :( Does disabling aspm help? `radeon.aspm=0 radeon.dpm=0` on the kernel command line in grub. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #100 from Alex Deucher --- (In reply to comment #99) > > Also, can you get a copy of the dmesg output from the driver after it loads? > > Try booting into a non-X runlevel without loading radeon (either blacklist > > it, or set radeon.modeset=0 on the kernel command line in grub) and then > > manually load it. E.g., > > modprobe -r radeon > > modprobe radeon modeset=1 dpm=1 > > I'm sorry I don't understand fully how to do this. boot with `radeon.modeset=0 1` on the kernel command line in grub, then when the kernel boots to single user mode, reload the radeon module with dpm=1. E.g., modprobe -r radeon modprobe radeon modeset=1 dpm=1 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68775] RV635 (r600) 600_DEBUG=sb causes GPU reset playing Second Life
https://bugs.freedesktop.org/show_bug.cgi?id=68775 --- Comment #2 from Shawn Starr --- Created attachment 85154 --> https://bugs.freedesktop.org/attachment.cgi?id=85154&action=edit GPU Reset information + userspace errors from reset GPU Reset information + userspace errors from reset -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68775] RV635 (r600) 600_DEBUG=sb causes GPU reset playing Second Life
https://bugs.freedesktop.org/show_bug.cgi?id=68775 Shawn Starr changed: What|Removed |Added Attachment #84943|0 |1 is obsolete|| --- Comment #3 from Shawn Starr --- Created attachment 85155 --> https://bugs.freedesktop.org/attachment.cgi?id=85155&action=edit Second Life - Shader full debug Second Life - Shader full debug -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #11 from Alexandre Demers --- So, after getting out at different points from ni_dpm_set_power_state(), it seems I can go down to ni_power_control_set_level() without problem. However, if I move to the next call which is ret = ni_dpm_force_performance_level(rdev, RADEON_DPM_FORCED_LEVEL_AUTO), it hangs. Could it be because we are setting something wrong in auto performance level? I'll be attaching my vbios just in case. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #12 from Alexandre Demers --- Created attachment 85157 --> https://bugs.freedesktop.org/attachment.cgi?id=85157&action=edit Cayman 6950 XFX vbios -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
linus-next: update to the drm-intel-fixes tree
Hi Daniel, This morning after fetching the drm-intel-fixes tree, I have discovered that you have just added a whole set of patches on top of Dave's drm tree and made that the drm-intel-fixes tree. I understood that this tree was for fixes to Linus' tree for the current release cycle. Given that Dave's tree has not been merged by Linus (yet), this is a bit inconsistent. Not only that, but now if I merge your tree early (which is what I do with the -fixes trees), I will also merge all of Dave's tree. That in turn would mean that I would have missed the (what would have been automatically applied) merge for I am carrying for Dave's tree. :-( I am going to have to drop your -fixes tree for today. If these are fixes for stuff in Linus' tree, then they should have been based on Linus' tree - if they are fixes for Dave's tree, then they should have been in your drm-intel tree, right? (fetches more trees ...) And now, I discover that they are the latter :-) So your -fixes tree will be dropped, but all those patches will still be merged via you drm-intel tree. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpH5iclLSo4i.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau/i2c: pass the function pointers in at creation time
On Sat, Aug 24, 2013 at 3:03 AM, Ilia Mirkin wrote:
> i2c_bit_add_bus can call the pre_xfer function, which expects the func
> pointer to be set. Pass in func to the port creation logic so that it is
> set before i2c_bit_add_bus.
Merged, thanks!
Ben.
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=68456
>
> Reported-by: Hans-Peter Deifel
> Tested-by: Hans-Peter Deifel
> Signed-off-by: Ilia Mirkin
> ---
>
> This will only happen if i2c_algo_bit.bit_test=1.
>
> drivers/gpu/drm/nouveau/core/include/subdev/i2c.h | 8 +---
> drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c | 10 --
> drivers/gpu/drm/nouveau/core/subdev/i2c/base.c| 2 ++
> drivers/gpu/drm/nouveau/core/subdev/i2c/nv04.c| 4 ++--
> drivers/gpu/drm/nouveau/core/subdev/i2c/nv4e.c| 4 ++--
> drivers/gpu/drm/nouveau/core/subdev/i2c/nv50.c| 4 ++--
> drivers/gpu/drm/nouveau/core/subdev/i2c/nv94.c| 8
> drivers/gpu/drm/nouveau/core/subdev/i2c/nvd0.c| 4 ++--
> 8 files changed, 23 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h
> b/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h
> index 888384c..7e4e277 100644
> --- a/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h
> +++ b/drivers/gpu/drm/nouveau/core/include/subdev/i2c.h
> @@ -39,8 +39,8 @@ struct nouveau_i2c_func {
> int (*drv_ctl)(struct nouveau_i2c_port *, int lane, int sw, int pe);
> };
>
> -#define nouveau_i2c_port_create(p,e,o,i,a,d)
> \
> - nouveau_i2c_port_create_((p), (e), (o), (i), (a),
> \
> +#define nouveau_i2c_port_create(p,e,o,i,a,f,d)
> \
> + nouveau_i2c_port_create_((p), (e), (o), (i), (a), (f),
> \
> sizeof(**d), (void **)d)
> #define nouveau_i2c_port_destroy(p) ({
> \
> struct nouveau_i2c_port *port = (p);
> \
> @@ -53,7 +53,9 @@ struct nouveau_i2c_func {
>
> int nouveau_i2c_port_create_(struct nouveau_object *, struct nouveau_object
> *,
> struct nouveau_oclass *, u8,
> -const struct i2c_algorithm *, int, void **);
> +const struct i2c_algorithm *,
> +const struct nouveau_i2c_func *,
> +int, void **);
> void _nouveau_i2c_port_dtor(struct nouveau_object *);
> #define _nouveau_i2c_port_init nouveau_object_init
> #define _nouveau_i2c_port_fini nouveau_object_fini
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
> b/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
> index dec94e9..4b195ac 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c
> @@ -118,7 +118,8 @@ anx9805_aux_chan_ctor(struct nouveau_object *parent,
> int ret;
>
> ret = nouveau_i2c_port_create(parent, engine, oclass, index,
> -&nouveau_i2c_aux_algo, &chan);
> + &nouveau_i2c_aux_algo,
> &anx9805_aux_func,
> + &chan);
> *pobject = nv_object(chan);
> if (ret)
> return ret;
> @@ -140,8 +141,6 @@ anx9805_aux_chan_ctor(struct nouveau_object *parent,
> struct i2c_algo_bit_data *algo = mast->adapter.algo_data;
> algo->udelay = max(algo->udelay, 40);
> }
> -
> - chan->base.func = &anx9805_aux_func;
> return 0;
> }
>
> @@ -234,7 +233,8 @@ anx9805_ddc_port_ctor(struct nouveau_object *parent,
> int ret;
>
> ret = nouveau_i2c_port_create(parent, engine, oclass, index,
> -&anx9805_i2c_algo, &port);
> + &anx9805_i2c_algo, &anx9805_i2c_func,
> + &port);
> *pobject = nv_object(port);
> if (ret)
> return ret;
> @@ -256,8 +256,6 @@ anx9805_ddc_port_ctor(struct nouveau_object *parent,
> struct i2c_algo_bit_data *algo = mast->adapter.algo_data;
> algo->udelay = max(algo->udelay, 40);
> }
> -
> - port->base.func = &anx9805_i2c_func;
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c
> index 8ae2625..2895c19 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c
> @@ -95,6 +95,7 @@ nouveau_i2c_port_create_(struct nouveau_object *parent,
> struct nouveau_object *engine,
> struct nouveau_oclass *oclass, u8 index,
> const struct i2c_algorithm *algo,
> +const struct nouveau_i2c_func *func,
>
Re: [PATCH] drm/nouveau: do not move buffers when not needed
On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst
wrote:
> Op 15-07-13 08:05, Ben Skeggs schreef:
>> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
>> wrote:
>>> I have no idea what this bogus restriction on placement is, but it breaks
>>> decoding 1080p
>>> VDPAU at boot speed. With this patch applied I only need to bump the vdec
>>> clock to
>>> get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer
>>> moves.
>> It's not bogus, and is required for pre-GF8 boards with VRAM > BAR size.
>>
>> What configuration does the buffer that's getting moved here have
>> exactly? The placement restriction isn't necessary on GF8, the rest
>> of the restrictions may currently be required still however.
>>
>>= vdpau on NVC0 with tiling. I upload the raw bitstream to a tiling bo. This
>>is ok because
> the vm hides all the tiling translations, and the engines will read the raw
> bitstream correctly.
Why would you be doing such a thing in the first place? It seems
pointless, and quite possibly counter-productive to use a tiled layout
for a linear data structure...
> 8<---
> This prevents buffer moves from being done on NV50+, where remapping is not
> needed because
> the bar has its own VM, instead of only having the first BAR1-size chunk of
> VRAM accessible.
> nouveau_bo_tile_layout is always 0 on < NV_50.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index d506da5..762bfcd 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1346,14 +1361,13 @@ nouveau_ttm_fault_reserve_notify(struct
> ttm_buffer_object *bo)
> struct nouveau_device *device = nv_device(drm->device);
> u32 mappable = pci_resource_len(device->pdev, 1) >> PAGE_SHIFT;
>
> - /* as long as the bo isn't in vram, and isn't tiled, we've got
> -* nothing to do here.
> + /*
> +* if the bo is not in vram, or remapping can be done (nv50+)
> +* do not worry about placement, any location is valid
> */
> - if (bo->mem.mem_type != TTM_PL_VRAM) {
> - if (nv_device(drm->device)->card_type < NV_50 ||
> - !nouveau_bo_tile_layout(nvbo))
> - return 0;
> - }
> + if (nv_device(drm->device)->card_type >= NV_50 ||
> + bo->mem.mem_type != TTM_PL_VRAM)
> + return 0;
I get what you're trying to do here, and we should definitely avoid
the "mappable vram" check on GF8, but I suspect this condition is too
broad. I'll think about it more after I finish reviewing the rest of
the patches on the list..
Thanks,
Ben.
>
> /* make sure bo is in mappable vram */
> if (bo->mem.start + bo->mem.num_pages < mappable)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/msm: handle read vs write fences
The userspace API already had everything needed to handle read vs write
synchronization. This patch actually bothers to hook it up properly, so
that we don't need to (for example) stall on userspace read access to a
buffer that gpu is also still reading.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.h | 2 +-
drivers/gpu/drm/msm/msm_gem.c | 25 ++---
drivers/gpu/drm/msm/msm_gem.h | 2 +-
drivers/gpu/drm/msm/msm_gpu.c | 9 +++--
4 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 80d7509..1ea9d46 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -153,7 +153,7 @@ void *msm_gem_vaddr(struct drm_gem_object *obj);
int msm_gem_queue_inactive_work(struct drm_gem_object *obj,
struct work_struct *work);
void msm_gem_move_to_active(struct drm_gem_object *obj,
- struct msm_gpu *gpu, uint32_t fence);
+ struct msm_gpu *gpu, bool write, uint32_t fence);
void msm_gem_move_to_inactive(struct drm_gem_object *obj);
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op,
struct timespec *timeout);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 6b5a6c8..df0390f 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -393,11 +393,14 @@ int msm_gem_queue_inactive_work(struct drm_gem_object
*obj,
}
void msm_gem_move_to_active(struct drm_gem_object *obj,
- struct msm_gpu *gpu, uint32_t fence)
+ struct msm_gpu *gpu, bool write, uint32_t fence)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
msm_obj->gpu = gpu;
- msm_obj->fence = fence;
+ if (write)
+ msm_obj->write_fence = fence;
+ else
+ msm_obj->read_fence = fence;
list_del_init(&msm_obj->mm_list);
list_add_tail(&msm_obj->mm_list, &gpu->active_list);
}
@@ -411,7 +414,8 @@ void msm_gem_move_to_inactive(struct drm_gem_object *obj)
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
msm_obj->gpu = NULL;
- msm_obj->fence = 0;
+ msm_obj->read_fence = 0;
+ msm_obj->write_fence = 0;
list_del_init(&msm_obj->mm_list);
list_add_tail(&msm_obj->mm_list, &priv->inactive_list);
@@ -433,8 +437,14 @@ int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t
op,
struct msm_gem_object *msm_obj = to_msm_bo(obj);
int ret = 0;
- if (is_active(msm_obj) && !(op & MSM_PREP_NOSYNC))
- ret = msm_wait_fence_interruptable(dev, msm_obj->fence,
timeout);
+ if (is_active(msm_obj) && !(op & MSM_PREP_NOSYNC)) {
+ uint32_t fence = 0;
+ if (op & MSM_PREP_READ)
+ fence = msm_obj->write_fence;
+ if (op & MSM_PREP_WRITE)
+ fence = max(fence, msm_obj->read_fence);
+ ret = msm_wait_fence_interruptable(dev, fence, timeout);
+ }
/* TODO cache maintenance */
@@ -455,9 +465,10 @@ void msm_gem_describe(struct drm_gem_object *obj, struct
seq_file *m)
uint64_t off = drm_vma_node_start(&obj->vma_node);
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
- seq_printf(m, "%08x: %c(%d) %2d (%2d) %08llx %p %d\n",
+ seq_printf(m, "%08x: %c(r=%u,w=%u) %2d (%2d) %08llx %p %d\n",
msm_obj->flags, is_active(msm_obj) ? 'A' : 'I',
- msm_obj->fence, obj->name,
obj->refcount.refcount.counter,
+ msm_obj->read_fence, msm_obj->write_fence,
+ obj->name, obj->refcount.refcount.counter,
off, msm_obj->vaddr, obj->size);
}
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index d746f13..0676f32 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -36,7 +36,7 @@ struct msm_gem_object {
*/
struct list_head mm_list;
struct msm_gpu *gpu; /* non-null if active */
- uint32_t fence;
+ uint32_t read_fence, write_fence;
/* Transiently in the process of submit ioctl, objects associated
* with the submit are on submit->bo_list.. this only lasts for
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index e1e1ec9..cb9cdff 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -265,7 +265,8 @@ static void retire_worker(struct work_struct *work)
obj = list_first_entry(&gpu->active_list,
struct msm_gem_object, mm_list);
- if (obj->fence <= fence) {
+ if ((obj->read_fence <= fence) &&
+ (obj->write_fence <= fence)) {
/* move to inactive: */
msm_gem_move_to_inactive(&obj->base);
msm
[PATCH 2/2] drm/msm: hangcheck harder
If gpu locks up with the rptr shortly beyond the wrap-around point in
the ringbuffer, because the rptr was not reset (but wptr is, by virtue
of resetting rb->cur), we could end up in a scenario where we think
there is not enough space in the ringbuffer for the next cmds. And
since the CP won't reset rptr until after processing an IB, this leaves
things in a sort of deadlock.
So reset rptr too. And a bit more spiffing up of hangcheck to make
things easier to debug.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 10 +-
drivers/gpu/drm/msm/msm_gpu.c | 9 -
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index a605847..a0b9d8a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -124,6 +124,8 @@ void adreno_recover(struct msm_gpu *gpu)
/* reset completed fence seqno, just discard anything pending: */
adreno_gpu->memptrs->fence = gpu->submitted_fence;
+ adreno_gpu->memptrs->rptr = 0;
+ adreno_gpu->memptrs->wptr = 0;
gpu->funcs->pm_resume(gpu);
ret = gpu->funcs->hw_init(gpu);
@@ -229,7 +231,7 @@ void adreno_idle(struct msm_gpu *gpu)
return;
} while(time_before(jiffies, t));
- DRM_ERROR("timeout waiting for %s to drain ringbuffer!\n", gpu->name);
+ DRM_ERROR("%s: timeout waiting to drain ringbuffer!\n", gpu->name);
/* TODO maybe we need to reset GPU here to recover from hang? */
}
@@ -256,11 +258,17 @@ void adreno_wait_ring(struct msm_gpu *gpu, uint32_t
ndwords)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
uint32_t freedwords;
+ unsigned long t = jiffies + ADRENO_IDLE_TIMEOUT;
do {
uint32_t size = gpu->rb->size / 4;
uint32_t wptr = get_wptr(gpu->rb);
uint32_t rptr = adreno_gpu->memptrs->rptr;
freedwords = (rptr + (size - 1) - wptr) % size;
+
+ if (time_after(jiffies, t)) {
+ DRM_ERROR("%s: timeout waiting for ringbuffer space\n",
gpu->name);
+ break;
+ }
} while(freedwords < ndwords);
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index cb9cdff..10cc443 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -237,8 +237,15 @@ static void hangcheck_handler(unsigned long data)
gpu->hangcheck_fence = fence;
} else if (fence < gpu->submitted_fence) {
/* no progress and not done.. hung! */
- struct msm_drm_private *priv = gpu->dev->dev_private;
+ struct drm_device *dev = gpu->dev;
+ struct msm_drm_private *priv = dev->dev_private;
gpu->hangcheck_fence = fence;
+ dev_err(dev->dev, "%s: hangcheck detected gpu lockup!\n",
+ gpu->name);
+ dev_err(dev->dev, "%s: completed fence: %u\n",
+ gpu->name, fence);
+ dev_err(dev->dev, "%s: submitted fence: %u\n",
+ gpu->name, gpu->submitted_fence);
queue_work(priv->wq, &gpu->recover_work);
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/nouveau: use MSI interrupts
On Fri, Aug 30, 2013 at 5:11 PM, Lucas Stach wrote:
> Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs:
>> On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin wrote:
>> > On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs wrote:
>> >> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin
>> >> wrote:
>> >>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin
>> wrote:
>> > On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
>> >> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin
>> >> wrote:
>> >>> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs
>> >>> wrote:
>> On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin
>> wrote:
>> > On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach
>> > wrote:
>> >> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
>> >>> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach
>> >>> wrote:
>> >>> > MSIs were only problematic on some old, broken chipsets. But
>> >>> > now that we
>> >>> > already see systems where PCI legacy interrupts are somewhat
>> >>> > flaky, it's
>> >>> > really time to move to MSIs.
>> >>> >
>> >>> > Signed-off-by: Lucas Stach
>> >>> > ---
>> >>> > drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
>> >>> > drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17
>> >>> > +
>> >>> > 2 files changed, 18 insertions(+)
>> >>> >
>> >>> > diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>> >>> > b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>> >>> > index 9d2cd20..ce6569f 100644
>> >>> > --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>> >>> > +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>> >>> > @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
>> >>> > struct nouveau_mc {
>> >>> > struct nouveau_subdev base;
>> >>> > const struct nouveau_mc_intr *intr_map;
>> >>> > + bool use_msi;
>> >>> > };
>> >>> >
>> >>> > static inline struct nouveau_mc *
>> >>> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>> >>> > b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>> >>> > index ec9cd6f..02b337e 100644
>> >>> > --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>> >>> > +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>> >>> > @@ -23,6 +23,7 @@
>> >>> > */
>> >>> >
>> >>> > #include
>> >>> > +#include
>> >>> >
>> >>> > static irqreturn_t
>> >>> > nouveau_mc_intr(int irq, void *arg)
>> >>> > @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
>> >>> > map++;
>> >>> > }
>> >>> >
>> >>> > + if (pmc->use_msi)
>> >>> > + nv_wr08(pmc->base.base.parent, 0x00088068,
>> >>> > 0xff);
>> >>> Register not present everywhere.
>> >>>
>> >>> At the very least, the enabling of MSI should be disallowed on
>> >>> the
>> >>> earlier chipsets where it's not supported. Though, it's perhaps
>> >>> possible that the pci_enable_msi() call will fail in all of these
>> >>> cases anyway.. I'm not certain.
>> >>>
>> >> MSIs are required property for everything doing PCIe. So the only
>> >> cases
>> >> where this should fail is plain PCI/AGP devices. I don't really
>> >> have a
>> >> test system for those old cards set up.
>> >>
>> >> But I remember Ilia having some legacy things plugged in, so
>> >> maybe he
>> >> could test this patch and see how it goes?
>> >
>> > Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
>> > that it's not native PCIe, but some sort of bridge thing IIRC),
>> Cases like the nv34 here (i think there's some nv4x that aren't
>> native
>> pcie too) are what I'm wondering about primarily.
>> >>>
>> >>> And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
>> >>> with "AutoAddGPU" disabled the NV18 and NV42 seem fine. However
>> >>> merely
>> >>> starting X (not xinit, not startx, not [gkx]dm) on the NV34 and
>> >>> ^C'ing
>> >>> it (with no clients connecting to said X), causes a "failed to idle
>> >>> channel" message in dmesg, which apparently never rectifies itself,
>> >>> so
>> >>> X is hung forever. FTR, there were no displays connected either, but
>> >>> I
>> >>> tried the exact same procedure without the MSI patch and it worked
>> >>> fine. Here is the init sequence with the MSI patch:
>> >> I don't suppose bashing 0x1868 instead of 0x88068 works here? If
[PATCH] dma-buf: Expose buffer size to userspace (v2)
Each dma-buf has an associated size and it's reasonable for userspace
to want to know what it is.
Since userspace already has an fd, expose the size using the
size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0);
idiom.
v2: Added Daniel's sugeested documentation, with minor fixups
Signed-off-by: Christopher James Halse Rogers
Reviewed-by: Daniel Vetter
Tested-by: Daniel Vetter
---
Documentation/dma-buf-sharing.txt | 12
drivers/base/dma-buf.c| 28
2 files changed, 40 insertions(+)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index 0b23261..849e982 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -407,6 +407,18 @@ Being able to mmap an export dma-buf buffer object has 2
main use-cases:
interesting ways depending upong the exporter (if userspace starts depending
upon this implicit synchronization).
+Other Interfaces Exposed to Userspace on the dma-buf FD
+--
+
+- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only
+ with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow
+ the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other
+ llseek operation will report -EINVAL.
+
+ If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all
+ cases. Userspace can use this to detect support for discovering the dma-buf
+ size using llseek.
+
Miscellaneous notes
---
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 6687ba7..c33a857 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -77,9 +77,36 @@ static int dma_buf_mmap_internal(struct file *file, struct
vm_area_struct *vma)
return dmabuf->ops->mmap(dmabuf, vma);
}
+static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
+{
+ struct dma_buf *dmabuf;
+ loff_t base;
+
+ if (!is_dma_buf_file(file))
+ return -EBADF;
+
+ dmabuf = file->private_data;
+
+ /* only support discovering the end of the buffer,
+ but also allow SEEK_SET to maintain the idiomatic
+ SEEK_END(0), SEEK_CUR(0) pattern */
+ if (whence == SEEK_END)
+ base = dmabuf->size;
+ else if (whence == SEEK_SET)
+ base = 0;
+ else
+ return -EINVAL;
+
+ if (offset != 0)
+ return -EINVAL;
+
+ return base + offset;
+}
+
static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
+ .llseek = dma_buf_llseek,
};
/*
@@ -133,6 +160,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
dmabuf->exp_name = exp_name;
file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
+ file->f_mode |= FMODE_LSEEK;
dmabuf->file = file;
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nv84-: write fence value on exit, and restore value on init.
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
wrote:
> This increases the chance slightly that recovery from lockup can happen
> succesfully.
I'd *really* love to see proof of this. When channels die, all
outstanding fences are marked as signalled. This should do absolutely
nothing...
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/nouveau/nv84_fence.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nv84_fence.c
> b/drivers/gpu/drm/nouveau/nv84_fence.c
> index 2cf0ade..daf4b18 100644
> --- a/drivers/gpu/drm/nouveau/nv84_fence.c
> +++ b/drivers/gpu/drm/nouveau/nv84_fence.c
> @@ -122,8 +122,11 @@ nv84_fence_context_del(struct nouveau_channel *chan)
> struct drm_device *dev = chan->drm->dev;
> struct nv84_fence_priv *priv = chan->drm->fence;
> struct nv84_fence_chan *fctx = chan->fence;
> + struct nouveau_fifo_chan *fifo = (void *)chan->object;
> int i;
>
> + nouveau_bo_wr32(priv->bo, fifo->chid * 16/4, fctx->base.sequence);
> +
> for (i = 0; i < dev->mode_config.num_crtc; i++) {
> struct nouveau_bo *bo = nv50_display_crtc_sema(dev, i);
> nouveau_bo_vma_del(bo, &fctx->dispc_vma[i]);
> @@ -168,7 +171,7 @@ nv84_fence_context_new(struct nouveau_channel *chan)
> ret = nouveau_bo_vma_add(bo, client->vm, &fctx->dispc_vma[i]);
> }
>
> - nouveau_bo_wr32(priv->bo, fifo->chid * 16/4, 0x);
> + fctx->base.sequence = nouveau_bo_rd32(priv->bo, fifo->chid * 16/4);
>
> if (ret)
> nv84_fence_context_del(chan);
> --
> 1.8.3.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nv50-: make dma-objects read-only where appropriate
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
wrote:
> I don't see why the display engine would need write access to the entirety of
> vram, when read-only access is enough.
Meh, this really doesn't matter... We're doing the same setup as
nvidia do here, and I see no good reason not to.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/nouveau/nv50_display.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
> b/drivers/gpu/drm/nouveau/nv50_display.c
> index aab72f5..eac6b2a 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.c
> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
> @@ -159,7 +159,7 @@ nv50_dmac_create_fbdma(struct nouveau_object *core, u32
> parent)
> NV_DMA_IN_MEMORY_CLASS,
> &(struct nv_dma_class) {
> .flags = NV_DMA_TARGET_VRAM |
> -NV_DMA_ACCESS_RDWR,
> +NV_DMA_ACCESS_RD,
> .start = 0,
> .limit = pfb->ram->size - 1,
> .conf0 = NV50_DMA_CONF0_ENABLE |
> @@ -172,7 +172,7 @@ nv50_dmac_create_fbdma(struct nouveau_object *core, u32
> parent)
> NV_DMA_IN_MEMORY_CLASS,
> &(struct nv_dma_class) {
> .flags = NV_DMA_TARGET_VRAM |
> -NV_DMA_ACCESS_RDWR,
> +NV_DMA_ACCESS_RD,
> .start = 0,
> .limit = pfb->ram->size - 1,
> .conf0 = NV50_DMA_CONF0_ENABLE | 0x70
> |
> @@ -185,7 +185,7 @@ nv50_dmac_create_fbdma(struct nouveau_object *core, u32
> parent)
> NV_DMA_IN_MEMORY_CLASS,
> &(struct nv_dma_class) {
> .flags = NV_DMA_TARGET_VRAM |
> -NV_DMA_ACCESS_RDWR,
> +NV_DMA_ACCESS_RD,
> .start = 0,
> .limit = pfb->ram->size - 1,
> .conf0 = NV50_DMA_CONF0_ENABLE | 0x7a
> |
> @@ -204,7 +204,7 @@ nvc0_dmac_create_fbdma(struct nouveau_object *core, u32
> parent)
> NV_DMA_IN_MEMORY_CLASS,
> &(struct nv_dma_class) {
> .flags = NV_DMA_TARGET_VRAM |
> -NV_DMA_ACCESS_RDWR,
> +NV_DMA_ACCESS_RD,
> .start = 0,
> .limit = pfb->ram->size - 1,
> .conf0 = NVC0_DMA_CONF0_ENABLE,
> @@ -216,7 +216,7 @@ nvc0_dmac_create_fbdma(struct nouveau_object *core, u32
> parent)
> NV_DMA_IN_MEMORY_CLASS,
> &(struct nv_dma_class) {
> .flags = NV_DMA_TARGET_VRAM |
> -NV_DMA_ACCESS_RDWR,
> +NV_DMA_ACCESS_RD,
> .start = 0,
> .limit = pfb->ram->size - 1,
> .conf0 = NVC0_DMA_CONF0_ENABLE | 0xfe,
> @@ -228,7 +228,7 @@ nvc0_dmac_create_fbdma(struct nouveau_object *core, u32
> parent)
> NV_DMA_IN_MEMORY_CLASS,
> &(struct nv_dma_class) {
> .flags = NV_DMA_TARGET_VRAM |
> -NV_DMA_ACCESS_RDWR,
> +NV_DMA_ACCESS_RD,
> .start = 0,
> .limit = pfb->ram->size - 1,
> .conf0 = NVC0_DMA_CONF0_ENABLE | 0xfe,
> @@ -246,7 +246,7 @@ nvd0_dmac_create_fbdma(struct nouveau_object *core, u32
> parent)
> NV_DMA_IN_MEMORY_CLASS,
> &(struct nv_dma_class) {
> .flags = NV_DMA_TARGET_VRAM |
> -NV_DMA_ACCESS_RDWR,
> +NV_DMA_ACCESS_RD,
> .start = 0,
> .limit = pfb->ram->size -
Re: [PATCH] drm/nouveau: fix command submission to use vmalloc for big allocations
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
wrote:
> I was getting a order 4 allocation failure from kmalloc when testing some game
> after a few days uptime with some suspend/resumes. For big allocations vmalloc
> should be used instead.
I've picked up this patch with a minor modification (see below)
>
> Also limit size more aggressively to 256 KiB.
I dropped this, it's *completely* useless, the sizes are already
enforced right at the beginning of the ioctl (shockingly, the max size
is going to be 256KiB already)...
Thanks,
Ben.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/nouveau/nouveau_gem.c | 30 +++---
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
> b/drivers/gpu/drm/nouveau/nouveau_gem.c
> index 177b86d5..779d702 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> @@ -584,18 +584,34 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel
> *chan,
> return 0;
> }
>
> +static inline void
> +u_free(void *addr)
> +{
> + if (!is_vmalloc_addr(addr))
> + kfree(addr);
> + else
> + vfree(addr);
> +}
> +
> static inline void *
> u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
> {
> void *mem;
> void __user *userptr = (void __force __user *)(uintptr_t)user;
>
> - mem = kmalloc(nmemb * size, GFP_KERNEL);
> + if (nmemb > 256 * 1024 / size)
> + return ERR_PTR(-ENOMEM);
> +
> + size *= nmemb;
> +
> + mem = kmalloc(size, GFP_KERNEL | __GFP_NOWARN);
> + if (!mem)
> + mem = vmalloc(size);
> if (!mem)
> return ERR_PTR(-ENOMEM);
>
> - if (DRM_COPY_FROM_USER(mem, userptr, nmemb * size)) {
> - kfree(mem);
> + if (DRM_COPY_FROM_USER(mem, userptr, size)) {
> + u_free(mem);
> return ERR_PTR(-EFAULT);
> }
>
> @@ -681,7 +697,7 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
> nouveau_bo_wr32(nvbo, r->reloc_bo_offset >> 2, data);
> }
>
> - kfree(reloc);
> + u_free(reloc);
> return ret;
> }
>
> @@ -743,7 +759,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
> *data,
>
> bo = u_memcpya(req->buffers, req->nr_buffers, sizeof(*bo));
> if (IS_ERR(bo)) {
> - kfree(push);
> + u_free(push);
> return nouveau_abi16_put(abi16, PTR_ERR(bo));
> }
>
> @@ -854,8 +870,8 @@ out:
> nouveau_fence_unref(&fence);
>
> out_prevalid:
> - kfree(bo);
> - kfree(push);
> + u_free(bo);
> + u_free(push);
>
> out_next:
> if (chan->dma.ib_max) {
> --
> 1.8.3.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: force alignment to 0x1000 for gpu objects
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
wrote:
> There are a lot of places that allocate multiples of 1000,
> but do not set alignment correctly and still require this
> alignment implicitly or explicitly.
This is wrong. Where are the places you think you need this?
Ben.
> ---
> drivers/gpu/drm/nouveau/core/core/gpuobj.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/core/core/gpuobj.c
> b/drivers/gpu/drm/nouveau/core/core/gpuobj.c
> index 7595506..7bcae1d 100644
> --- a/drivers/gpu/drm/nouveau/core/core/gpuobj.c
> +++ b/drivers/gpu/drm/nouveau/core/core/gpuobj.c
> @@ -65,6 +65,14 @@ nouveau_gpuobj_create_(struct nouveau_object *parent,
> int ret, i;
> u64 addr;
>
> + /*
> +* There are a lot of places that allocate multiples of 1000,
> +* but do not set alignment correctly and still require this
> +* alignment implicitly or explicitly.
> +*/
> + if (size >= 0x1000 && align < 0x1000)
> + align = 0x1000;
> +
> *pobject = NULL;
>
> if (pargpu) {
> --
> 1.8.3.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
wrote:
> Op 22-08-13 02:10, Ilia Mirkin schreef:
>> The code expects non-VRAM mem nodes to have a pages list. If that's not
>> set, it will do a null deref down the line. Warn on that condition and
>> return an error.
>>
>> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
>>
>> Reported-by: Pasi Kärkkäinen
>> Tested-by: Pasi Kärkkäinen
>> Signed-off-by: Ilia Mirkin
>> Cc: # 3.8+
>> ---
>>
>> I don't exactly understand what's going on, but this is just a
>> straightforward way to avoid a null deref that you see happens in the
>> bug. I haven't figured out the root cause of this, but it's getting
>> well into the "I have no idea how TTM works" space. However this seems
>> like a bit of defensive programming -- nouveau_vm_map_sg will pass
>> node->pages as a list down, which will be dereferenced by
>> nvc0_vm_map_sg. Perhaps the other arguments should make that
>> dereferencing not happen, but it definitely was happening here, as you
>> can see in the bug.
>>
>> Ben/Maarten, I'll let you judge whether this check is appropriate,
>> since like I hope I was able to convey above, I'm just not really sure :)
> Not it really isn't appropriate..
>
> You'd have to call call nouveau_vm_map_sg_table instead, the only place that
> doesn't handle that correctly
> is where it's not expected to be called.
>
> Here, have a completely untested patch to fix things...
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
> {
> struct nouveau_framebuffer *nouveau_fb;
> struct drm_gem_object *gem;
> + struct nouveau_bo *nvbo;
> int ret = -ENOMEM;
>
> gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
> if (!gem)
> return ERR_PTR(-ENOENT);
>
> + nvbo = nouveau_gem_object(gem);
> + if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
> + nv_warn(nouveau_drm(dev), "Trying to create a fb in vram with"
> + " valid_domains=%08x\n", nvbo->valid_domains);
> + ret = -EINVAL;
> + goto err_unref;
> + }
> +
Definitely the right idea, we can't handle this case right now.
However, we may someday want/need to be able to scan out of system
memory, so this is the wrong place.
I suspect the correct thing to do (which'll also handle the
"defensive" part) is to bail in nouveau_bo_move() on attempts to move
a DMA-BUF backed object into VRAM.
Sound OK?
Ben.
> nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
> if (!nouveau_fb)
> goto err_unref;
>
> - ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd,
> nouveau_gem_object(gem));
> + ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nvbo);
> if (ret)
> goto err;
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 02/19] video: Add Common Display Framework core
Hi Tomi, On Monday 02 September 2013 11:42:00 Tomi Valkeinen wrote: > On 09/08/13 20:14, Laurent Pinchart wrote: > > The Common Display Framework (CDF) splits display devices in entities > > that interact through an abstract API. Each entity is managed by its own > > driver independently of the other entities, with the framework > > orchestrating interactions. > > > > This commit introduces the CDF core with entity (un)registration and > > core control operations support. > > > > Signed-off-by: Laurent Pinchart > > The media entity code used in CDF needs (at least) MEDIA_CAMERA_SUPPORT > and MEDIA_CONTROLLER to be enabled in the kernel config. These are not > selected/depended upon currently. Good point. I'll select MEDIA_CONTROLLER. > And while MEDIA_CONTROLLER makes sense, MEDIA_CAMERA_SUPPORT doesn't, so > maybe there's some tuning needed for the media code. Agreed, I'll fix that. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: i915.disable_pch_pwm overrides PCH_PWM_ENABLE quirk
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Some BIOS configurations of Dell XPS13 are adversely affected by e85843b
("drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight") so provide a
boot param to inhibit the quirk, or force it on.
i915.disable_pch_pwm can be set to
-1: auto (default; allows the disabling of pch_pwm by dmi quirk table match)
0: inhibits the disabling of pch_pwm (overrides dmi quirk table match)
1: forces the disabling of pch_pwm
Signed-off-by: Kamal Mostafa
---
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 11 ---
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 72e2be7..fee05df 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -154,6 +154,10 @@ module_param_named(prefault_disable,
i915_prefault_disable, bool, 0600);
MODULE_PARM_DESC(prefault_disable,
"Disable page prefaulting for pread/pwrite/reloc
(default:false). For developers only.");
+int i915_disable_pch_pwm __read_mostly = -1;
+module_param_named(disable_pch_pwm, i915_disable_pch_pwm, int, 0600);
+MODULE_PARM_DESC(disable_pch_pwm, "disable PCH_PWM (default: -1 (auto))");
+
static struct drm_driver driver;
extern int intel_agp_enabled;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 769c138..e6f2a34 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1726,6 +1726,7 @@ extern bool i915_fastboot __read_mostly;
extern int i915_enable_pc8 __read_mostly;
extern int i915_pc8_timeout __read_mostly;
extern bool i915_prefault_disable __read_mostly;
+extern int i915_disable_pch_pwm __read_mostly;
extern int i915_suspend(struct drm_device *dev, pm_message_t state);
extern int i915_resume(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 30e5946..86fa722 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9948,9 +9948,8 @@ static void quirk_invert_brightness(struct drm_device
*dev)
*/
static void quirk_no_pcm_pwm_enable(struct drm_device *dev)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
- dev_priv->quirks |= QUIRK_NO_PCH_PWM_ENABLE;
- DRM_INFO("applying no-PCH_PWM_ENABLE quirk\n");
+ if (i915_disable_pch_pwm < 0)
+ i915_disable_pch_pwm = 1;
}
struct intel_quirk {
@@ -10048,6 +10047,12 @@ static void intel_init_quirks(struct drm_device *dev)
if (dmi_check_system(*intel_dmi_quirks[i].dmi_id_list) != 0)
intel_dmi_quirks[i].hook(dev);
}
+
+ if (i915_disable_pch_pwm == 1) {
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ dev_priv->quirks |= QUIRK_NO_PCH_PWM_ENABLE;
+ DRM_INFO("applying no-PCH_PWM_ENABLE quirk\n");
+ }
}
/* Disable the VGA plane that we never use */
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: i915.disable_pch_pwm overrides PCH_PWM_ENABLE quirk
On Tue, 2013-09-03 at 19:50 +0200, Daniel Vetter wrote:
> On Tue, Sep 3, 2013 at 7:37 PM, Kamal Mostafa wrote:
> > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
> >
> > Some BIOS configurations of Dell XPS13 are adversely affected by e85843b
> > ("drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight") so provide a
> > boot param to inhibit the quirk, or force it on.
> >
> > i915.disable_pch_pwm can be set to
> > -1: auto (default; allows the disabling of pch_pwm by dmi quirk table
> > match)
> > 0: inhibits the disabling of pch_pwm (overrides dmi quirk table match)
> > 1: forces the disabling of pch_pwm
> >
> > Signed-off-by: Kamal Mostafa
>
> Nack. Piling quirk over quirk isn't the right approach
I understand your reluctance, but this isn't actually any new quirk
functionality, just a way to manually enable/disable the original
PCH_PWM_ENABLE quirk. I think this is the least crazy approach,
because:
Most XPS13 configurations do need the quirk (and maybe some other yet to
be identified machines also), but dmi matching cannot discern the one
particular XPS13 configuration ("Ivy Bridge booting UEFI mode without
Legacy Option ROM") that is adversely affected by it. We could
alternately consider trying to detect that specific configuration with
code in i915, but that seemed a lot crazier (and less generally useful)
than just providing an override switch for rare or yet-to-be-discovered
configurations.
Hmmm. What if we had a pair of boot params "i915.quirks_set" and
"i915.quirks_mask" boot params that could be used to manually set or
mask _all_ the bits in dev_priv->quirks? Such params would surely come
in handy for cases just like this one, and would be useful for testing
future machines easily. (Would you take that if I submitted it?)
> and I think I
> should just revert the pch_pwm enable quirk again.
> -Daniel
But reverting the original quirk would break ALL the XPS13
configurations, which nobody is requesting. Please don't revert the
quirk. At most, you might want to disable the Ivy Bridge dmi match (but
I don't recommend this either):
/* Dell XPS13 HD and XPS13 FHD Ivy Bridge */
{ 0x0166, 0x1028, 0x058b, quirk_no_pcm_pwm_enable },
-Kamal
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
Thanks Sean,
On 3 September 2013 20:15, Sean Paul wrote:
> A few comments.
>
> On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
> wrote:
>> Exynos hdmiphy operations and configs are kept inside
>> the hdmi driver. Hdmiphy related code is tightly coupled
>> with hdmi IP driver.
>>
>> This patche moves hdmiphy related code to hdmiphy driver.
>
> s/patche/patch
>
ok.
>> It will help in cleanly supporting the hdmiphy variations
>> in further SoCs.
>>
>> Signed-off-by: Rahul Sharma
>> ---
>> .../devicetree/bindings/video/exynos_hdmi.txt |2 +
>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 343 +++
>> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
>> +++-
>> drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
>> 5 files changed, 533 insertions(+), 296 deletions(-)
>> create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> index 50decf8..240eca5 100644
>> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> @@ -25,6 +25,7 @@ Required properties:
>> sclk_pixel.
>> - clock-names: aliases as per driver requirements for above clock IDs:
>> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
>> +- phy: it points to hdmiphy dt node.
>> Example:
>>
>> hdmi {
>> @@ -32,4 +33,5 @@ Example:
>> reg = <0x1453 0x10>;
>> interrupts = <0 95 0>;
>> hpd-gpio = <&gpx3 7 1>;
>> + phy = <&hdmiphy>;
>> };
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> index 724cab1..1c839f8 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> @@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct
>> exynos_drm_hdmi_context *ctx);
>> void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
>> void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
>> void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
>> +
>> +int exynos_hdmiphy_driver_register(void);
>> +void exynos_hdmiphy_driver_unregister(void);
>> +
>> +void exynos_hdmiphy_enable(struct device *dev);
>> +void exynos_hdmiphy_disable(struct device *dev);
>> +int exynos_hdmiphy_check_mode(struct device *dev,
>> + struct drm_display_mode *mode);
>> +int exynos_hdmiphy_set_mode(struct device *dev,
>> + struct drm_display_mode *mode);
>> +int exynos_hdmiphy_conf_apply(struct device *dev);
>> #endif
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index f67ffca..3af4e4c 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -34,6 +34,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #include
>>
>> @@ -172,7 +174,6 @@ struct hdmi_v14_conf {
>> };
>>
>> struct hdmi_conf_regs {
>> - int pixel_clock;
>> int cea_video_id;
>> union {
>> struct hdmi_v13_conf v13_conf;
>> @@ -193,9 +194,9 @@ struct hdmi_context {
>> int irq;
>>
>> struct i2c_client *ddc_port;
>> - struct i2c_client *hdmiphy_port;
>> + struct device *hdmiphy_dev;
>>
>> - /* current hdmiphy conf regs */
>> + /* current hdmi ip configuration registers. */
>> struct hdmi_conf_regs mode_conf;
>>
>> struct hdmi_resources res;
>> @@ -205,180 +206,6 @@ struct hdmi_context {
>> enum hdmi_type type;
>> };
>>
>> -struct hdmiphy_config {
>> - int pixel_clock;
>> - u8 conf[32];
>> -};
>> -
>> -/* list of phy config settings */
>> -static const struct hdmiphy_config hdmiphy_v13_configs[] = {
>> - {
>> - .pixel_clock = 2700,
>> - .conf = {
>> - 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
>> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
>> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
>> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
>> - },
>> - },
>> - {
>> - .pixel_clock = 27027000,
>> - .conf = {
>> - 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
>> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
>> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
>> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
>> - },
>> - },
>> -
re: drm/radeon: add audio support for DCE6/8 GPUs (v12)
Hello Alex Deucher, This is a semi-automatic email about new static checker warnings. The patch b530602fd462: "drm/radeon: add audio support for DCE6/8 GPUs (v12)" from Jul 31, 2013, leads to the following Smatch complaint: drivers/gpu/drm/radeon/dce6_afmt.c:91 dce6_afmt_select_pin() warn: variable dereferenced before check 'dig->afmt->pin' (see line 89) drivers/gpu/drm/radeon/dce6_afmt.c 88 u32 offset = dig->afmt->offset; 89 u32 id = dig->afmt->pin->id; ^^ Patch adds dereference. 90 91 if (!dig->afmt->pin) ^^^ Patch adds check. 92 return; 93 regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm/tegra: Changes for v3.12-rc1
Hi Dave, The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b: Linux 3.11-rc2 (2013-07-21 12:05:29 -0700) are available in the git repository at: git://anongit.freedesktop.org/tegra/linux tags/drm/for-3.12-rc1 for you to fetch changes up to 03da0e7ba9e3a1fc700f60913ff6bcb19f7eac2a: drm/tegra: Parse device tree earlier (2013-09-03 10:10:13 +0200) Thanks, Thierry drm/tegra: Changes for v3.12-rc1 Only a couple of small patches this time around. These are mostly fixes for minor bugs that showed up, but there is also some preparatory work that will come in handy for future patches. Dan Carpenter (2): gpu: host1x: fix an integer overflow check gpu: host1x: returning success instead of -ENOMEM Mikko Perttunen (1): drm/tegra: hdmi: Make sure clock is enabled before dumping registers Thierry Reding (3): gpu: host1x: Check for valid host1x pointer gpu: host1x: Sort drivers by probe order drm/tegra: Parse device tree earlier drivers/gpu/host1x/dev.c | 2 +- drivers/gpu/host1x/dev.h | 2 +- drivers/gpu/host1x/drm/hdmi.c | 7 +++ drivers/gpu/host1x/drm/rgb.c | 14 +++--- drivers/gpu/host1x/job.c | 15 +++ 5 files changed, 23 insertions(+), 17 deletions(-) pgpCkyrZymwRT.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60827] X under radeon driver crashes after resuming from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=60827 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher --- Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60827] X under radeon driver crashes after resuming from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=60827 --- Comment #3 from Alex Deucher --- You might also try a newer kernel. It looks like the uvd ring that is failing to resume properly. There are a number of fixes for suspend/resume related problems with uvd in 3.11 (most of which should end up in stable). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote: > Op 28-08-13 08:29, Pasi Kärkkäinen schreef: > > On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote: > >> On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote: > >>> Op 22-08-13 02:10, Ilia Mirkin schreef: > The code expects non-VRAM mem nodes to have a pages list. If that's not > set, it will do a null deref down the line. Warn on that condition and > return an error. > > See https://bugs.freedesktop.org/show_bug.cgi?id=64774 > > Reported-by: Pasi Kärkkäinen > Tested-by: Pasi Kärkkäinen > Signed-off-by: Ilia Mirkin > Cc: # 3.8+ > --- > > I don't exactly understand what's going on, but this is just a > straightforward way to avoid a null deref that you see happens in the > bug. I haven't figured out the root cause of this, but it's getting > well into the "I have no idea how TTM works" space. However this seems > like a bit of defensive programming -- nouveau_vm_map_sg will pass > node->pages as a list down, which will be dereferenced by > nvc0_vm_map_sg. Perhaps the other arguments should make that > dereferencing not happen, but it definitely was happening here, as you > can see in the bug. > > Ben/Maarten, I'll let you judge whether this check is appropriate, > since like I hope I was able to convey above, I'm just not really sure :) > >>> Not it really isn't appropriate.. > >>> > >>> You'd have to call call nouveau_vm_map_sg_table instead, the only place > >>> that doesn't handle that correctly > >>> is where it's not expected to be called. > >>> > >>> Here, have a completely untested patch to fix things... > >>> > >> Maarten: I've been testing this stuff with Linux 3.10.x, so I had to > >> modify the patch a bit to make it apply there.. > >> I've attached the modified copy that applies to 3.10.9, hopefully I did > >> the backport correctly. > >> > >> With Linux 3.10.9 and the patch applied the kernel doesn't crash anymore, > >> and I get this error in dmesg: > >> > >> [ 76.105643] nouveau W[ DRM] Trying to create a fb in vram with > >> valid_domains=0004 > >> > >> Does that help? > >> > > Any comments? > > > > Maarten's patch works for me, I get that warning instead of a kernel crash, > > but it's also a bigger change that doesn't apply to older kernels as-is. > > > > Ilia's original patch in this thread can be applied to older kernels as-is, > > and it also prevents the kernel crash from happening. > > > > Should we get both applied, so Ilia's patch can be CC'd to stable ? > > > You haven't understood the root cause then. You're trying to move an IMPORTED > dma-buf into VRAM. > Doing so would seem to work, but at that point it's no longer a dma-buf so > changes done by the exporter > would not show up in nouveau because they no longer refer to the same piece > of memory. > Yes, that's true, I don't understand the root cause. That's mostly because I'm not familiar with the nouveau code/internals. > Failing is the only right option here. > Sorry but I'm not sure I understand that correctly.. what exactly do you suggest? What should fail? Because I'm not familiar with the code (yet) understanding and finding the root cause will take time for me.. that's why I was suggesting to meanwhile apply Ilia's very simple patch from this thread which actually prevents the hard kernel crash from happening, because it seems like an unharmful fix to have to protect against this kind of bugs (the root cause) ? Or is that unacceptable? (To recap: The kernel crash happens very often when trying to use the nouveau adapter in Optimus mode, with all kernels at least 3.8+, and it's very annoying that your laptop crashes when trying to enable a nouveau output. So Ilia's patch doesn't make the driver working properly, but at least it prevents the hard kernel crash from happening. The crash bug is in many kernel versions, including the long-term v3.10 tree. I've had the crash happening with 3.8.x, 3.9.x and 3.10.x) All comments welcome. Thanks, -- Pasi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
Op 03-09-13 16:20, Pasi Kärkkäinen schreef: > On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote: >> Op 28-08-13 08:29, Pasi Kärkkäinen schreef: >>> On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote: On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote: > Op 22-08-13 02:10, Ilia Mirkin schreef: >> The code expects non-VRAM mem nodes to have a pages list. If that's not >> set, it will do a null deref down the line. Warn on that condition and >> return an error. >> >> See https://bugs.freedesktop.org/show_bug.cgi?id=64774 >> >> Reported-by: Pasi Kärkkäinen >> Tested-by: Pasi Kärkkäinen >> Signed-off-by: Ilia Mirkin >> Cc: # 3.8+ >> --- >> >> I don't exactly understand what's going on, but this is just a >> straightforward way to avoid a null deref that you see happens in the >> bug. I haven't figured out the root cause of this, but it's getting >> well into the "I have no idea how TTM works" space. However this seems >> like a bit of defensive programming -- nouveau_vm_map_sg will pass >> node->pages as a list down, which will be dereferenced by >> nvc0_vm_map_sg. Perhaps the other arguments should make that >> dereferencing not happen, but it definitely was happening here, as you >> can see in the bug. >> >> Ben/Maarten, I'll let you judge whether this check is appropriate, >> since like I hope I was able to convey above, I'm just not really sure :) > Not it really isn't appropriate.. > > You'd have to call call nouveau_vm_map_sg_table instead, the only place > that doesn't handle that correctly > is where it's not expected to be called. > > Here, have a completely untested patch to fix things... > Maarten: I've been testing this stuff with Linux 3.10.x, so I had to modify the patch a bit to make it apply there.. I've attached the modified copy that applies to 3.10.9, hopefully I did the backport correctly. With Linux 3.10.9 and the patch applied the kernel doesn't crash anymore, and I get this error in dmesg: [ 76.105643] nouveau W[ DRM] Trying to create a fb in vram with valid_domains=0004 Does that help? >>> Any comments? >>> >>> Maarten's patch works for me, I get that warning instead of a kernel crash, >>> but it's also a bigger change that doesn't apply to older kernels as-is. >>> >>> Ilia's original patch in this thread can be applied to older kernels as-is, >>> and it also prevents the kernel crash from happening. >>> >>> Should we get both applied, so Ilia's patch can be CC'd to stable ? >>> >> You haven't understood the root cause then. You're trying to move an >> IMPORTED dma-buf into VRAM. >> Doing so would seem to work, but at that point it's no longer a dma-buf so >> changes done by the exporter >> would not show up in nouveau because they no longer refer to the same piece >> of memory. >> > Yes, that's true, I don't understand the root cause. > That's mostly because I'm not familiar with the nouveau code/internals. > > >> Failing is the only right option here. >> > Sorry but I'm not sure I understand that correctly.. what exactly do you > suggest? What should fail? > > > Because I'm not familiar with the code (yet) understanding and finding the > root cause > will take time for me.. that's why I was suggesting to meanwhile apply Ilia's > very simple patch > from this thread which actually prevents the hard kernel crash from > happening, because it seems > like an unharmful fix to have to protect against this kind of bugs (the root > cause) ? > Or is that unacceptable? > > (To recap: The kernel crash happens very often when trying to use the nouveau > adapter in Optimus mode, with all kernels at least 3.8+, and it's very > annoying that your laptop crashes when trying to enable a nouveau output. So > Ilia's patch doesn't make the driver working properly, but at least it > prevents the hard kernel crash from happening. The crash bug is in many > kernel versions, including the long-term v3.10 tree. I've had the crash > happening with 3.8.x, 3.9.x and 3.10.x) The fix probably requires commit fdfb8332651db7a280851dfccfc4f0cff4bcd052 to apply cleanly "drm/nouveau: fix some error-path leaks in fbcon handling code" > All comments welcome. > > Thanks, > > -- Pasi > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/1] ARM: dts: AM33XX: Add LCDC info into am335x-evm
Hi,
I have not received any feedback on this patch.
It has been pending since the end of June (first post).
Can I get an estimate when it will be included/accepted?
Thanks,
Benoit
On Fri, Aug 23, 2013 at 11:13:56AM -0500, Benoit Parrot wrote:
> Add LCDC device node in DT for am33xx
> Add LCDC and Panel info in DT for am335x-evm
>
> Changes in v3:
> - rebase to 3.11-rc6
>
> Changes in v2:
> - remove redundant/unnecessary SoC specific setting in the board dts
>
> Signed-off-by: Benoit Parrot
> ---
> arch/arm/boot/dts/am335x-evm.dts | 72
> ++
> arch/arm/boot/dts/am33xx.dtsi|9 +
> 2 files changed, 81 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-evm.dts
> b/arch/arm/boot/dts/am335x-evm.dts
> index 3aee1a4..b0703f1 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -149,6 +149,40 @@
> 0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> >;
> };
> +
> + lcd_pins_s0: lcd_pins_s0 {
> + pinctrl-single,pins = <
> + 0x20 0x01 /* gpmc_ad8.lcd_data16, OUTPUT
> | MODE1 */
> + 0x24 0x01 /* gpmc_ad9.lcd_data17, OUTPUT
> | MODE1 */
> + 0x28 0x01 /* gpmc_ad10.lcd_data18, OUTPUT
> | MODE1 */
> + 0x2c 0x01 /* gpmc_ad11.lcd_data19, OUTPUT
> | MODE1 */
> + 0x30 0x01 /* gpmc_ad12.lcd_data20, OUTPUT
> | MODE1 */
> + 0x34 0x01 /* gpmc_ad13.lcd_data21, OUTPUT
> | MODE1 */
> + 0x38 0x01 /* gpmc_ad14.lcd_data22, OUTPUT
> | MODE1 */
> + 0x3c 0x01 /* gpmc_ad15.lcd_data23, OUTPUT
> | MODE1 */
> + 0xa0 0x00 /* lcd_data0.lcd_data0, OUTPUT
> | MODE0 */
> + 0xa4 0x00 /* lcd_data1.lcd_data1, OUTPUT
> | MODE0 */
> + 0xa8 0x00 /* lcd_data2.lcd_data2, OUTPUT
> | MODE0 */
> + 0xac 0x00 /* lcd_data3.lcd_data3, OUTPUT
> | MODE0 */
> + 0xb0 0x00 /* lcd_data4.lcd_data4, OUTPUT
> | MODE0 */
> + 0xb4 0x00 /* lcd_data5.lcd_data5, OUTPUT
> | MODE0 */
> + 0xb8 0x00 /* lcd_data6.lcd_data6, OUTPUT
> | MODE0 */
> + 0xbc 0x00 /* lcd_data7.lcd_data7, OUTPUT
> | MODE0 */
> + 0xc0 0x00 /* lcd_data8.lcd_data8, OUTPUT
> | MODE0 */
> + 0xc4 0x00 /* lcd_data9.lcd_data9, OUTPUT
> | MODE0 */
> + 0xc8 0x00 /* lcd_data10.lcd_data10,
> OUTPUT | MODE0 */
> + 0xcc 0x00 /* lcd_data11.lcd_data11,
> OUTPUT | MODE0 */
> + 0xd0 0x00 /* lcd_data12.lcd_data12,
> OUTPUT | MODE0 */
> + 0xd4 0x00 /* lcd_data13.lcd_data13,
> OUTPUT | MODE0 */
> + 0xd8 0x00 /* lcd_data14.lcd_data14,
> OUTPUT | MODE0 */
> + 0xdc 0x00 /* lcd_data15.lcd_data15,
> OUTPUT | MODE0 */
> + 0xe0 0x00 /* lcd_vsync.lcd_vsync, OUTPUT
> | MODE0 */
> + 0xe4 0x00 /* lcd_hsync.lcd_hsync, OUTPUT
> | MODE0 */
> + 0xe8 0x00 /* lcd_pclk.lcd_pclk, OUTPUT |
> MODE0 */
> + 0xec 0x00 /*
> lcd_ac_bias_en.lcd_ac_bias_en, OUTPUT | MODE0 */
> + >;
> + };
> +
> };
>
> ocp {
> @@ -311,6 +345,10 @@
> };
> };
> };
> +
> + lcdc: lcdc@4830e000 {
> + status = "okay";
> + };
> };
>
> vbat: fixedregulator@0 {
> @@ -374,6 +412,40 @@
> brightness-levels = <0 51 53 56 62 75 101 152 255>;
> default-brightness-level = <8>;
> };
> +
> + panel {
> + compatible = "ti,tilcdc,panel";
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pins_s0>;
> + panel-info {
> + ac-bias = <255>;
> + ac-bias-intrpt= <0>;
> + dma-burst-sz = <16>;
> + bpp = <32>;
> + fdd = <0x80>;
> + sync-edge = <0>;
> + sync-ctrl = <1>;
> + raster-order = <0>;
> + fifo-th = <0>;
> + };
> +
> + display-timings {
> + 800x480p62 {
> +
Re: [PATCH 4/7] drm/exynos: add support for exynos5420 hdmiphy
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Exynos5420 hdmiphy device is a platform device, unlike
> predecessor SoCs where it used to be a I2C device. This
> support is added to the hdmiphy driver.
>
Stuffing a platform driver in the same place as your i2c driver seems
weird. I think you should split them up.
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_hdmiphy.c | 224
> ++-
> 1 file changed, 221 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> index b1b8a0f..33e89d9 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> @@ -32,6 +32,7 @@ struct hdmiphy_context {
>
> /* hdmiphy resources */
> void __iomem*phy_pow_ctrl_reg;
> + void __iomem*regs;
>
> struct hdmiphy_config *confs;
> unsigned intnr_confs;
> @@ -48,6 +49,135 @@ struct hdmiphy_drv_data {
> };
>
> /* list of all required phy config settings */
> +static struct hdmiphy_config hdmiphy_5420_configs[] = {
> + {
> + .pixel_clock = 2520,
> + .conf = {
> + 0x01, 0x52, 0x3F, 0x55, 0x40, 0x01, 0x00, 0xC8,
> + 0x82, 0xC8, 0xBD, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x06, 0x80, 0x01, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xF4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 2700,
> + .conf = {
> + 0x01, 0xD1, 0x22, 0x51, 0x40, 0x08, 0xFC, 0xE0,
> + 0x98, 0xE8, 0xCB, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x06, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xE4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 27027000,
> + .conf = {
> + 0x01, 0xD1, 0x2D, 0x72, 0x40, 0x64, 0x12, 0xC8,
> + 0x43, 0xE8, 0x0E, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x06, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xE3, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 3600,
> + .conf = {
> + 0x01, 0x51, 0x2D, 0x55, 0x40, 0x40, 0x00, 0xC8,
> + 0x02, 0xC8, 0x0E, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xAB, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 4000,
> + .conf = {
> + 0x01, 0xD1, 0x21, 0x31, 0x40, 0x3C, 0x28, 0xC8,
> + 0x87, 0xE8, 0xC8, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0x9A, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 6500,
> + .conf = {
> + 0x01, 0xD1, 0x36, 0x34, 0x40, 0x0C, 0x04, 0xC8,
> + 0x82, 0xE8, 0x45, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xBD, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 7100,
> + .conf = {
> + 0x01, 0xD1, 0x3B, 0x35, 0x40, 0x0C, 0x04, 0xC8,
> + 0x85, 0xE8, 0x63, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0x57, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 74176000,
> + .conf = {
> + 0x01, 0xD1, 0x1F, 0x10, 0x40, 0x5B, 0xEF, 0xC8,
> + 0x81, 0xE8, 0xB9, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x56, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xA6, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 7425,
> + .conf = {
> + 0x01, 0xD1, 0x1F, 0x10, 0x40, 0x40, 0xF8, 0xC8,
> + 0x81, 0xE8, 0xBA, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x56, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xA5, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 8350,
> + .conf = {
> + 0x01, 0xD1, 0x
Re: [RFC 01/10] drm: ADV7511 i2c HDMI encoder driver
Hi Lars-Peter, (CC'ing Hans Verkuil and the dri-devel and linux-media mailing lists) On Monday 02 September 2013 17:09:11 Lars-Peter Clausen wrote: > On 09/02/2013 05:01 PM, Laurent Pinchart wrote: > > On Monday 02 September 2013 16:43:25 Lars-Peter Clausen wrote: > >> On 09/02/2013 04:15 PM, Laurent Pinchart wrote: > >>> On Monday 02 September 2013 15:40:22 Lars-Peter Clausen wrote: > On 09/02/2013 03:18 PM, Laurent Pinchart wrote: > > On Friday 30 August 2013 14:37:35 Ulrich Hecht wrote: > >> ADV7511 driver snapshot taken from commit f416e32 of xcomm_zynq_3_10 > >> branch at https://github.com/analogdevicesinc/linux.git > > > > I believe Lars-Peter (CC'ed) was planning to upstream the driver. > > Lars-Peter, could you please share your plans ? > > My plan was to have all this upstream long time ago ;) > > As I said in that other thread, I don't think it is a good idea to have > two drivers for the same device. But if nobody else sees a problem with > this and as long as the v4l driver doesn't have devicetree support I > guess we could get away with it for now. Even if it will probably haunt > us later on. > > There are still a few minor bits and pieces to iron out, but lets try > to aim for 2.6.13. > >>> > >>> If you can make it for 2.6.13 I will be extremely impressed :-) > >> > >> Yea, I know DRM always takes a bit longer... > > > > I think you meant 3.13 ;-) > > > >>> Do you plan to push the driver yourself ? If so, I would appreciate if > >>> you could CC me. If there's just a few minor bits to iron out I can > >>> already review your latest version if that can help. > >> > >> There are a couple of style issues, so if you review the driver ignore > >> these for now, but otherwise feedback is welcome, thanks. And I'm not > >> also quite happy with the ASoC integration yet. I'll thus concentrate on the video part in the review. Any chance to get the video portion to mainline first and then add audio support ? > > Sure. Is the version available from the above branch the latest version ? > > Yes, you can find it here: > https://github.com/analogdevicesinc/linux/tree/xcomm_zynq/drivers/gpu/drm/ > i2c Thank you. > Oh and the DT bindings also still need proper documentation. I've squashed all the patches together and have copied the result below. > From f7c27f204cab3d7dcaa128880c0d9ef1ae0e2fc6 Mon Sep 17 00:00:00 2001 > From: Lars-Peter Clausen > Date: Mon, 5 Mar 2012 16:30:57 +0100 > Subject: [PATCH] DRM: Add adv7511 encoder driver > > This patch adds a driver for the Analog Devices adv7511. The adv7511 is a > standalone HDMI transmitter chip. It features a HDMI output interface on one > end and video and audio input interfaces on the other. > > Signed-off-by: Lars-Peter Clausen > --- > drivers/gpu/drm/Kconfig | 6 + > drivers/gpu/drm/i2c/Makefile| 3 + > drivers/gpu/drm/i2c/adv7511.h | 454 + > drivers/gpu/drm/i2c/adv7511_audio.c | 304 +++ > drivers/gpu/drm/i2c/adv7511_core.c | 979 + > 5 files changed, 1746 insertions(+) > create mode 100644 drivers/gpu/drm/i2c/adv7511.h > create mode 100644 drivers/gpu/drm/i2c/adv7511_audio.c > create mode 100644 drivers/gpu/drm/i2c/adv7511_core.c First of all, please run checkpatch.pl on the code :-) > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 626bc0c..d8862a4 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -200,6 +200,12 @@ config DRM_SAVAGE > Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister > chipset. If M is selected the module will be called savage. > > +config DRM_ENCODER_ADV7511 > + tristate "AV7511 encoder" > + depends on DRM && I2C > + select REGMAP_I2C > + select HDMI Beside adding a help text, you should also depend on and/or select SND_SOC. > + > source "drivers/gpu/drm/exynos/Kconfig" > > source "drivers/gpu/drm/vmwgfx/Kconfig" [snip] > diff --git a/drivers/gpu/drm/i2c/adv7511.h b/drivers/gpu/drm/i2c/adv7511.h > new file mode 100644 > index 000..4631fcd6 > --- /dev/null > +++ b/drivers/gpu/drm/i2c/adv7511.h > @@ -0,0 +1,454 @@ > +/** > + * Analog Devices ADV7511 HDMI transmitter driver > + * > + * Copyright 2012 Analog Devices Inc. > + * > + * Licensed under the GPL-2. > + */ > + > +#ifndef __ADV7511_H__ > +#define __ADV7511_H__ > + > +#include This file should be split in two headers, one with platform data that will go to include/linux/platform_data/, and another one that can stay here. > +#define ADV7511_REG_CHIP_REVISION0x00 > +#define ADV7511_REG_N0 0x01 > +#define ADV7511_REG_N1 0x02 > +#define ADV7511_REG_N2 0x03 > +#define ADV7511_REG_SPDIF_FREQ 0x04 > +#define ADV7511_REG_CTS_AUTOMATIC1 0x05 > +#
Re: [PATCH 3/7] drm/exynos: add hdmiphy pmu bit control in hdmiphy driver
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Before hdmiphy operation like config, start etc, hdmiphy
> bit in PMU block should be enabled. Earlier this happens
> in hdmi drvier through a dummy "hdmiphy" clock.
s/drvier/driver/
>
> Signed-off-by: Rahul Sharma
> ---
> .../devicetree/bindings/video/exynos_hdmiphy.txt |6 ++
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 +
> drivers/gpu/drm/exynos/exynos_hdmi.c |2 +
> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 82
>
> 4 files changed, 92 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> index 162f641..f6bf096 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -6,10 +6,16 @@ Required properties:
> 2) "samsung,exynos4210-hdmiphy".
> 3) "samsung,exynos4212-hdmiphy".
> - reg: I2C address of the hdmiphy device.
> +- phy-power-control: this child node represents phy power control
> + register which is inside the pmu block (power management unit).
Should you include devicetree-discuss on this?
>
> Example:
>
> hdmiphy {
> compatible = "samsung,exynos4210-hdmiphy";
> reg = <0x38>;
> +
> + phy-power-control {
> + reg = <0x10040700 0x04>;
> + };
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> index 1c839f8..9a14f96 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> @@ -68,6 +68,8 @@ void exynos_mixer_ops_register(struct exynos_mixer_ops
> *ops);
> int exynos_hdmiphy_driver_register(void);
> void exynos_hdmiphy_driver_unregister(void);
>
> +void exynos_hdmiphy_poweron(struct device *dev);
> +void exynos_hdmiphy_poweroff(struct device *dev);
> void exynos_hdmiphy_enable(struct device *dev);
> void exynos_hdmiphy_disable(struct device *dev);
> int exynos_hdmiphy_check_mode(struct device *dev,
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index cd1d921..a6234fc 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1131,6 +1131,7 @@ static void hdmiphy_poweron(struct hdmi_context *hdata)
> if (hdata->type == HDMI_TYPE14)
> hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, 0,
> HDMI_PHY_POWER_OFF_EN);
> + exynos_hdmiphy_poweron(hdata->hdmiphy_dev);
> }
>
> static void hdmiphy_poweroff(struct hdmi_context *hdata)
> @@ -1138,6 +1139,7 @@ static void hdmiphy_poweroff(struct hdmi_context *hdata)
> if (hdata->type == HDMI_TYPE14)
> hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, ~0,
> HDMI_PHY_POWER_OFF_EN);
> + exynos_hdmiphy_poweroff(hdata->hdmiphy_dev);
Shouldn't the phy power off before HDMI?
> }
>
> static void hdmi_conf_apply(struct hdmi_context *hdata)
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> index 82daa42..b1b8a0f 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> @@ -30,6 +30,9 @@ struct hdmiphy_context {
> struct device *dev;
> struct hdmiphy_config *current_conf;
>
> + /* hdmiphy resources */
> + void __iomem*phy_pow_ctrl_reg;
> +
> struct hdmiphy_config *confs;
> unsigned intnr_confs;
> };
> @@ -225,6 +228,49 @@ static struct hdmiphy_config *hdmiphy_find_conf(struct
> hdmiphy_context *hdata,
> return NULL;
> }
>
> +static int hdmiphy_dt_parse_power_control(struct hdmiphy_context *hdata)
> +{
> + struct device_node *phy_pow_ctrl_node;
> + u32 buf[2];
> + int ret = 0;
> +
> + phy_pow_ctrl_node = of_get_child_by_name(hdata->dev->of_node,
> + "phy-power-control");
> + if (!phy_pow_ctrl_node) {
> + DRM_ERROR("Failed to find phy power control node\n");
> + ret = -ENODEV;
> + goto fail;
You can just return -ENODEV here.
> + }
> +
> + /* reg property holds two informations: addr of pmu register, size */
> + if (of_property_read_u32_array(phy_pow_ctrl_node, "reg",
> + (u32 *)&buf, 2)) {
Maybe I'm missing something, but this looks bad. I think this should be:
of_property_read_u32_array(phy_pow_ctrl_node, "reg", buf, ARRAY_SIZE(buf))
ie: dereferencing buf won't do what you expect it to.
> + DRM_ERROR("faild to get phy power control reg\n");
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + hdata->phy_pow_ctrl_reg = devm_ioremap(hdata->dev, buf[0], buf[1]);
>
Re: [PATCH 2/7] drm/exynos: remove dummy hdmiphy clock
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> hdmiphy is a dummy clock which actually controls the PMU bit
> to enable/disbale hdmiphy (before CCF). This clock is cleaned
s/disbale/disable/
> from the hdmi driver.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c |8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 3af4e4c..cd1d921 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -84,7 +84,6 @@ struct hdmi_resources {
> struct clk *sclk_hdmi;
> struct clk *sclk_pixel;
> struct clk *sclk_hdmiphy;
> - struct clk *hdmiphy;
> struct clk *mout_hdmi;
> struct regulator_bulk_data *regul_bulk;
> int regul_count;
> @@ -1431,7 +1430,6 @@ static void hdmi_poweron(struct hdmi_context *hdata)
> if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
> DRM_DEBUG_KMS("failed to enable regulator bulk\n");
>
> - clk_prepare_enable(res->hdmiphy);
> clk_prepare_enable(res->hdmi);
> clk_prepare_enable(res->sclk_hdmi);
>
> @@ -1456,7 +1454,6 @@ static void hdmi_poweroff(struct hdmi_context *hdata)
>
> clk_disable_unprepare(res->sclk_hdmi);
> clk_disable_unprepare(res->hdmi);
> - clk_disable_unprepare(res->hdmiphy);
> regulator_bulk_disable(res->regul_count, res->regul_bulk);
>
> mutex_lock(&hdata->hdmi_mutex);
> @@ -1549,11 +1546,6 @@ static int hdmi_resources_init(struct hdmi_context
> *hdata)
> DRM_ERROR("failed to get clock 'sclk_hdmiphy'\n");
> goto fail;
> }
> - res->hdmiphy = devm_clk_get(dev, "hdmiphy");
> - if (IS_ERR(res->hdmiphy)) {
> - DRM_ERROR("failed to get clock 'hdmiphy'\n");
> - goto fail;
> - }
> res->mout_hdmi = devm_clk_get(dev, "mout_hdmi");
> if (IS_ERR(res->mout_hdmi)) {
> DRM_ERROR("failed to get clock 'mout_hdmi'\n");
> --
> 1.7.10.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Tue, Sep 03, 2013 at 04:34:56PM +0200, Maarten Lankhorst wrote: > Op 03-09-13 16:20, Pasi Kärkkäinen schreef: > > On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote: > >> Op 28-08-13 08:29, Pasi Kärkkäinen schreef: > >>> On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote: > On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote: > > Op 22-08-13 02:10, Ilia Mirkin schreef: > >> The code expects non-VRAM mem nodes to have a pages list. If that's not > >> set, it will do a null deref down the line. Warn on that condition and > >> return an error. > >> > >> See https://bugs.freedesktop.org/show_bug.cgi?id=64774 > >> > >> Reported-by: Pasi Kärkkäinen > >> Tested-by: Pasi Kärkkäinen > >> Signed-off-by: Ilia Mirkin > >> Cc: # 3.8+ > >> --- > >> > >> I don't exactly understand what's going on, but this is just a > >> straightforward way to avoid a null deref that you see happens in the > >> bug. I haven't figured out the root cause of this, but it's getting > >> well into the "I have no idea how TTM works" space. However this seems > >> like a bit of defensive programming -- nouveau_vm_map_sg will pass > >> node->pages as a list down, which will be dereferenced by > >> nvc0_vm_map_sg. Perhaps the other arguments should make that > >> dereferencing not happen, but it definitely was happening here, as you > >> can see in the bug. > >> > >> Ben/Maarten, I'll let you judge whether this check is appropriate, > >> since like I hope I was able to convey above, I'm just not really sure > >> :) > > Not it really isn't appropriate.. > > > > You'd have to call call nouveau_vm_map_sg_table instead, the only place > > that doesn't handle that correctly > > is where it's not expected to be called. > > > > Here, have a completely untested patch to fix things... > > > Maarten: I've been testing this stuff with Linux 3.10.x, so I had to > modify the patch a bit to make it apply there.. > I've attached the modified copy that applies to 3.10.9, hopefully I did > the backport correctly. > > With Linux 3.10.9 and the patch applied the kernel doesn't crash > anymore, and I get this error in dmesg: > > [ 76.105643] nouveau W[ DRM] Trying to create a fb in vram with > valid_domains=0004 > > Does that help? > > >>> Any comments? > >>> > >>> Maarten's patch works for me, I get that warning instead of a kernel > >>> crash, > >>> but it's also a bigger change that doesn't apply to older kernels as-is. > >>> > >>> Ilia's original patch in this thread can be applied to older kernels > >>> as-is, > >>> and it also prevents the kernel crash from happening. > >>> > >>> Should we get both applied, so Ilia's patch can be CC'd to stable ? > >>> > >> You haven't understood the root cause then. You're trying to move an > >> IMPORTED dma-buf into VRAM. > >> Doing so would seem to work, but at that point it's no longer a dma-buf so > >> changes done by the exporter > >> would not show up in nouveau because they no longer refer to the same > >> piece of memory. > >> > > Yes, that's true, I don't understand the root cause. > > That's mostly because I'm not familiar with the nouveau code/internals. > > > > > >> Failing is the only right option here. > >> > > Sorry but I'm not sure I understand that correctly.. what exactly do you > > suggest? What should fail? > > > > > > Because I'm not familiar with the code (yet) understanding and finding the > > root cause > > will take time for me.. that's why I was suggesting to meanwhile apply > > Ilia's very simple patch > > from this thread which actually prevents the hard kernel crash from > > happening, because it seems > > like an unharmful fix to have to protect against this kind of bugs (the > > root cause) ? > > Or is that unacceptable? > > > > (To recap: The kernel crash happens very often when trying to use the > > nouveau adapter in Optimus mode, with all kernels at least 3.8+, and it's > > very annoying that your laptop crashes when trying to enable a nouveau > > output. So Ilia's patch doesn't make the driver working properly, but at > > least it prevents the hard kernel crash from happening. The crash bug is in > > many kernel versions, including the long-term v3.10 tree. I've had the > > crash happening with 3.8.x, 3.9.x and 3.10.x) > > The fix probably requires commit fdfb8332651db7a280851dfccfc4f0cff4bcd052 to > apply cleanly "drm/nouveau: fix some error-path leaks in fbcon handling code" > So what you mean is to use fdfb8332651db7a280851dfccfc4f0cff4bcd052 and your patch from this thread? and skip Ilia's patch? -- Pasi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
A few comments.
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Exynos hdmiphy operations and configs are kept inside
> the hdmi driver. Hdmiphy related code is tightly coupled
> with hdmi IP driver.
>
> This patche moves hdmiphy related code to hdmiphy driver.
s/patche/patch
> It will help in cleanly supporting the hdmiphy variations
> in further SoCs.
>
> Signed-off-by: Rahul Sharma
> ---
> .../devicetree/bindings/video/exynos_hdmi.txt |2 +
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
> drivers/gpu/drm/exynos/exynos_hdmi.c | 343 +++
> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
> +++-
> drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
> 5 files changed, 533 insertions(+), 296 deletions(-)
> create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 50decf8..240eca5 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -25,6 +25,7 @@ Required properties:
> sclk_pixel.
> - clock-names: aliases as per driver requirements for above clock IDs:
> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
> +- phy: it points to hdmiphy dt node.
> Example:
>
> hdmi {
> @@ -32,4 +33,5 @@ Example:
> reg = <0x1453 0x10>;
> interrupts = <0 95 0>;
> hpd-gpio = <&gpx3 7 1>;
> + phy = <&hdmiphy>;
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> index 724cab1..1c839f8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> @@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context
> *ctx);
> void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
> void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
> void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
> +
> +int exynos_hdmiphy_driver_register(void);
> +void exynos_hdmiphy_driver_unregister(void);
> +
> +void exynos_hdmiphy_enable(struct device *dev);
> +void exynos_hdmiphy_disable(struct device *dev);
> +int exynos_hdmiphy_check_mode(struct device *dev,
> + struct drm_display_mode *mode);
> +int exynos_hdmiphy_set_mode(struct device *dev,
> + struct drm_display_mode *mode);
> +int exynos_hdmiphy_conf_apply(struct device *dev);
> #endif
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index f67ffca..3af4e4c 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -34,6 +34,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -172,7 +174,6 @@ struct hdmi_v14_conf {
> };
>
> struct hdmi_conf_regs {
> - int pixel_clock;
> int cea_video_id;
> union {
> struct hdmi_v13_conf v13_conf;
> @@ -193,9 +194,9 @@ struct hdmi_context {
> int irq;
>
> struct i2c_client *ddc_port;
> - struct i2c_client *hdmiphy_port;
> + struct device *hdmiphy_dev;
>
> - /* current hdmiphy conf regs */
> + /* current hdmi ip configuration registers. */
> struct hdmi_conf_regs mode_conf;
>
> struct hdmi_resources res;
> @@ -205,180 +206,6 @@ struct hdmi_context {
> enum hdmi_type type;
> };
>
> -struct hdmiphy_config {
> - int pixel_clock;
> - u8 conf[32];
> -};
> -
> -/* list of phy config settings */
> -static const struct hdmiphy_config hdmiphy_v13_configs[] = {
> - {
> - .pixel_clock = 2700,
> - .conf = {
> - 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
> - },
> - },
> - {
> - .pixel_clock = 27027000,
> - .conf = {
> - 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
> - },
> - },
> - {
> - .pixel_clock = 74176000,
> - .conf = {
> - 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef, 0x5B,
> - 0x6D, 0x10, 0x01, 0x51, 0
[Bug 68857] SNU OpenCL NAS Parallel Benchmarks don't work
https://bugs.freedesktop.org/show_bug.cgi?id=68857 --- Comment #1 from Tom Stellard --- I'm having a little trouble figuring out the build system for this suite, could you pick one of the failing examples and give instructions for how to build and execute it? Also, what version of Mesa and LLVM are you using? I recommend using the development versions of both for best results. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68901] New: wine/3DMark2001: shader generation fails
https://bugs.freedesktop.org/show_bug.cgi?id=68901 Priority: medium Bug ID: 68901 Keywords: regression Assignee: dri-devel@lists.freedesktop.org Summary: wine/3DMark2001: shader generation fails Severity: normal Classification: Unclassified OS: Linux (All) Reporter: gurket...@googlemail.com URL: http://www.futuremark.com/support/downloads Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa When running 3DMark2001 in wine (1.7.1), the r600 gallium driver (on RV710) fails to generate some shaders. This is a regression: 3f67251e3d0ce61a0e7fc16de91de6fb49cad768 is the first bad commit commit 3f67251e3d0ce61a0e7fc16de91de6fb49cad768 Author: Christian König Date: Sun Mar 10 14:33:29 2013 +0100 glsl_to_tgsi: allocate arrays separately v2 Instead of allocating everything as temporaries, use the new array allocation functions. v2: fix bug in simplify_cmp, declare arrays on demand Signed-off-by: Christian König :04 04 75a734fc12e314c32a959f4111543ec518cb8a51 57eed35384ed9aadd89adfce1a075b4ad0a745cc Msrc The output when the shader generation fails is: EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_shader.c:1886 r600_shader_from_tgsi - GPR limit exceeded - shader requires 129 registers EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_shader.c:134 r600_pipe_shader_create - translation from TGSI failed ! EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_state_common.c:750 r600_shader_select - Failed to build shader variant (type=0) -12 EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_shader.c:1886 r600_shader_from_tgsi - GPR limit exceeded - shader requires 129 registers EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_shader.c:134 r600_pipe_shader_create - translation from TGSI failed ! EE /mnt/raid0/software/mesa/git/src/gallium/drivers/r600/r600_state_common.c:750 r600_shader_select - Failed to build shader variant (type=0) -12 This is not a dupe of bug 62696 as the problem is still there with git version 6b5c802c30ada043ee31cc5e62249ff99bbc865f. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 2/3] drm/panel: Add simple panel support
On 08/30/2013 09:25 AM, Thierry Reding wrote: > Add a driver for simple panels. Such panels can have a regulator that > provides the supply voltage and a separate GPIO to enable the panel. > Optionally the panels can have a backlight associated with them so it > can be enabled or disabled according to the panel's power management > mode. > diff --git a/Documentation/devicetree/bindings/panel/panel-simple.txt > b/Documentation/devicetree/bindings/panel/panel-simple.txt > +Simple display panel > + > +Required properties: > +- compatible: should be one of: > + - "auo,b101aw03": AU Optronics Corporation 10.1" WSVGA TFT LCD panel > + - "cptt,claa101wb03": Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel > + - "pc,vvx10f004b00": Panasonic Corporation 10.1" WUXGA TFT LCD panel > + > +Optional properties: > +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing > +- power-supply: regulator to provide the supply voltage > +- enable-gpios: GPIO pin to enable or disable the panel > +- backlight: phandle of the backlight device attached to the panel Do we need to represent the timing requirements e.g. between panel enable and backlight enable, or do you expect the driver to hard-code this based on the compatible value? Looking at the driver code, it seems that it has direct knowledge of the video mode that each panel supports, so DDC is actually optional unlike what I asserted/assumed in my previous response. As such, I guess we should have a separate DT binding document for each of the three panels (compatible values) listed above that pretty much just says "go look at simple-panel.txt". ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
