[Bug 65274] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! (non-EFI laptop)
https://bugs.freedesktop.org/show_bug.cgi?id=65274 Christian König changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #7 from Christian König --- Good, so we can probably close this bugreport. -- 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: [PATCH 000/165] radeon drm-next patches
Alex Deucher wrote: On Thu, Jun 27, 2013 at 9:12 AM, Andy Furniss wrote: Alex Deucher wrote: On Wed, Jun 26, 2013 at 9:21 AM, wrote: From: Alex Deucher These are the radeon patches for 3.11. Some of these patches are huge so, it might be easier to review things here: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip Updated branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip-2 Takes into account comments from Jerome a Christian and contains a few DPM fixes. I see there's a 3 now - I tested that (I guess currently it's the same as 2 anyway). On my rv790 there are no regressions so far, but whatever I do it stays low. This should work much better with with wip-5. Yes, this works on my rv790 games get high and using vdpau/gl for video stays low (which is nice as the fan on my card is too noisy on high). One thing which I guess 99.999% of people won't notice is that doing any thing with plain X + fluxbox (so no compositing) very briefly ramps up the speed. As my fan is just audible on low but very quick to respond I can hear every time the screen gets updated eg. switching desktops, browsing+scrolling or switching tabs, even typing dmesg in an xterm which time shows as taking < 0.1 sec results in a fan change. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 000/165] radeon drm-next patches
Hi, > Yes, this works on my rv790 games get high and using vdpau/gl for video stays low (which is nice as the fan on my card is too noisy on high). > > One thing which I guess 99.999% of people won't notice is that doing any thing with plain X + fluxbox (so no compositing) very briefly ramps up the speed. > > As my fan is just audible on low but very quick to respond I can hear every time the screen gets updated eg. switching desktops, browsing+scrolling or switching tabs, even typing dmesg in an xterm which time shows as taking < 0.1 sec results in a fan change. Probably a low-pass filter is needed/has to be configured in front of the freq. scaling engine? Ilyes > > > > ___ > 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: Armada DRM driver on OLPC XO
On Wed, Jun 26, 2013 at 10:42 AM, Jean-Francois Moine wrote: > Do you know that there are 2 drm drivers for the Cubox? I posted mine > (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168732.html) > before Russell, but I got no return about it yet. I thought there was some agreement that you would merge your efforts into Russell's driver. Is that still the plan? Thanks for the links - I think we can learn something about timer handling from your work. I'll send a patch shortly incorporating the basis of something like this into armada_drm. Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Armada DRM driver on OLPC XO
On Fri, Jun 28, 2013 at 01:54:21PM -0600, Daniel Drake wrote: > On Wed, Jun 26, 2013 at 10:42 AM, Jean-Francois Moine wrote: > > Do you know that there are 2 drm drivers for the Cubox? I posted mine > > (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168732.html) > > before Russell, but I got no return about it yet. > > I thought there was some agreement that you would merge your efforts > into Russell's driver. Is that still the plan? > > Thanks for the links - I think we can learn something about timer > handling from your work. I'll send a patch shortly incorporating the > basis of something like this into armada_drm. Note that my driver has changed significantly since the last posting; it's now using drm planes and also dmabuf stuff to limited extents (because dmabuf is technically misdesigned for CPUs with noncoherent DMA.) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
armada_drm clock selection
Hi Russell,
Thanks for pointing me to the most recent version of your driver.
Can you comment on the below patch for improved clock handling?
It is based on the approach in Jean-Francois Moine's driver, and would
serve for the basis of having clock info come from the DT. If you have
something else in mind, maybe you can explain quickly, and I'll try to
implement it.
armada_priv now has a clk array, the indice of each member of the array
corresponds to the id in the SCLK register (so extclk1 goes at clk[3]).
When we need to set up SCLK for a CRTC, we try to find a clock that can
meet the requested rate exactly. If we don't find one, we fall back on the
first clock in the array.
armada510_compute_crtc_clock had a fair amount of stuff that is in danger
of being repeated in a MMP2-equivalent function, and then again for MMP3.
So I took out the clock-hunting code and made that into a function that
would be shared by the 3 platforms.
devm can't be used for clocks as for DT we will use of_clk_get() with an index
and there is no devm equivalent.
Comments appreciated. Compile tested only.
---
drivers/gpu/drm/armada/armada_crtc.c | 31 ---
drivers/gpu/drm/armada/armada_drm.h | 15 +++--
drivers/gpu/drm/armada/armada_drv.c | 104 ---
drivers/gpu/drm/armada/armada_hw.h | 9 +--
4 files changed, 100 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index dadaf63..9705466 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -413,16 +413,31 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
struct armada_private *priv = crtc->dev->dev_private;
struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
struct armada_regs regs[16];
+ struct clk *clk;
uint32_t lm, rm, tm, bm, val, sclk;
unsigned long flags;
unsigned i;
bool interlaced;
+ int clk_idx;
int ret;
- /* First, check that this will succeed. */
- ret = priv->ops->compute_crtc_clock(dcrtc, adj, NULL);
- if (ret)
- return ret;
+ /* First, check that a suitable clock is available. */
+ clk_idx = armada_drm_find_best_clock(priv, adj->clock * 1000);
+ if (clk_idx < 0)
+ return clk_idx;
+
+ clk = priv->clk[clk_idx];
+ if (dcrtc->clk != clk) {
+ if (dcrtc->clk) {
+ clk_disable_unprepare(clk);
+ dcrtc->clk = NULL;
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (ret)
+ return ret;
+ dcrtc->clk = clk;
+ }
drm_framebuffer_reference(crtc->fb);
@@ -459,8 +474,8 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
writel_relaxed(val, dcrtc->base + LCD_SPU_DUMB_CTRL);
}
- /* Now compute the divider for real */
- priv->ops->compute_crtc_clock(dcrtc, adj, &sclk);
+ /* Now compute the divider */
+ sclk = priv->ops->compute_crtc_clock(dcrtc, adj->clock * 1000, clk_idx);
armada_reg_queue_set(regs, i, sclk, LCD_CFG_SCLK_DIV);
@@ -634,7 +649,7 @@ static void armada_drm_crtc_destroy(struct drm_crtc *crtc)
priv->dcrtc[dcrtc->num] = NULL;
drm_crtc_cleanup(&dcrtc->crtc);
- if (!IS_ERR(dcrtc->clk))
+ if (dcrtc->clk)
clk_disable_unprepare(dcrtc->clk);
kfree(dcrtc);
@@ -734,7 +749,7 @@ int armada_drm_crtc_create(struct drm_device *dev, unsigned
num,
dcrtc->base = base;
dcrtc->num = num;
- dcrtc->clk = ERR_PTR(-EINVAL);
+ dcrtc->clk = NULL;
dcrtc->cfg_dma_ctrl0 = CFG_GRA_ENA | CFG_GRA_HSMOOTH;
dcrtc->cfg_dumb_ctrl = DUMB24_RGB888_0;
spin_lock_init(&dcrtc->irq_lock);
diff --git a/drivers/gpu/drm/armada/armada_drm.h
b/drivers/gpu/drm/armada/armada_drm.h
index c2dcde5..b41d77c 100644
--- a/drivers/gpu/drm/armada/armada_drm.h
+++ b/drivers/gpu/drm/armada/armada_drm.h
@@ -41,18 +41,23 @@ struct armada_private;
struct armada_ops {
int (*init)(struct armada_private *, struct device *);
- int (*compute_crtc_clock)(struct armada_crtc *,
- const struct drm_display_mode *,
- uint32_t *);
+ uint32_t (*compute_crtc_clock)(struct armada_crtc *,
+ long rate, int clk_idx);
};
+#define ARMADA_MAX_CLOCK 4
+
struct armada_private {
const struct armada_ops *ops;
struct drm_fb_helper*fbdev;
struct armada_crtc *dcrtc[2];
struct armada_overlay *overlay;
struct drm_mm linear;
- struct clk *extclk[2];
+
+ /* The index of clocks in this array line up with their ID
+* into the SCLK clock selection register. */
+ struct clk *clk[ARMADA
Re: armada_drm clock selection
On Fri, Jun 28, 2013 at 04:11:32PM -0400, Daniel Drake wrote: > Hi Russell, > > Thanks for pointing me to the most recent version of your driver. > Can you comment on the below patch for improved clock handling? Sure... lets add some background info first: the big problem here is the completely different register layouts for the clock register: On Armada 510: 31:30 - select the clock input from 4 possible sources: 0 - AXI, 1 - EXT0, 2 - PLL, 3 - EXT1 29- loads the divider values 27:16 - (broken) fractional divider - you never want to use this 15:0 - integer divider Armada 16x: 31:28 - select clock input from 4 possible sources using bit patterns. 0 - AHB, 1 - PCLK, 2 - AXI, 3 - PLL 27:16 - (broken) fractional divider 15:0 - integer divider >From drivers/video/mmp driver (MMP2/MMP3, aka Armada 610?): 31- clock select 28- disable bit 27:16 - fractional divider 15:12 - apparantly not used 11:8 - DSI divider 7:0 - integer divider So we have at least three rather different layouts of this register to deal with different a divider range and different clock selection methods. Hence why I separated out the functionality into a callback... > It is based on the approach in Jean-Francois Moine's driver, and would > serve for the basis of having clock info come from the DT. If you have > something else in mind, maybe you can explain quickly, and I'll try to > implement it. Yes, I really don't like how you got rid of the initial call to the compute function... we need to have some way to reject mode setting for clock rates which we can't support, and that was it. Ideally, this should be done to limit the available modes, but as DRM doesn't ask the CRTC itself whether a particular mode is valid... that's a shortcoming of DRM. For example, we need to reject the TV modes if there is no clock capable of providing something close enough to the required rate. > armada_priv now has a clk array, the indice of each member of the array > corresponds to the id in the SCLK register (so extclk1 goes at clk[3]). > When we need to set up SCLK for a CRTC, we try to find a clock that can > meet the requested rate exactly. If we don't find one, we fall back on the > first clock in the array. I've steered clear of doing anything like this with Armada 510 because the documentation is too totally and utterly diabolical that it's impossible to really work out what this "AXI" or "PLL" clock is, how they're clocked, what rate they're clocked at, and what clock they correspond to in the kernel. Moreover, according to Sebastian, the internal clocks are totally and utterly useless for HDMI resolutions - and as all I can use on my setup are the TV resolutions... > armada510_compute_crtc_clock had a fair amount of stuff that is in danger > of being repeated in a MMP2-equivalent function, and then again for MMP3. > So I took out the clock-hunting code and made that into a function that > would be shared by the 3 platforms. Well, the solution to that is to provide a helper for the compute function(s) to use, not to bolt the assumptions about clocks into the CRTC part of the driver. Eg, it appears some platforms would only have two clock inputs. > devm can't be used for clocks as for DT we will use of_clk_get() with > an index and there is no devm equivalent. devm_clk_get() should work on DT. I've been through this before with the DT people, and they've come back and told me that it does work with DT. You're telling me it doesn't, which means someone is either mistaken. My guess is you're missing a "clock names" property. Given that these controllers seem to be able to source from many different sources depending on the clock, I think requiring the clock names property is reasonable because there is little consistency between what each clock is used for. > Comments appreciated. Compile tested only. > --- > drivers/gpu/drm/armada/armada_crtc.c | 31 --- > drivers/gpu/drm/armada/armada_drm.h | 15 +++-- > drivers/gpu/drm/armada/armada_drv.c | 104 > --- > drivers/gpu/drm/armada/armada_hw.h | 9 +-- > 4 files changed, 100 insertions(+), 59 deletions(-) > > diff --git a/drivers/gpu/drm/armada/armada_crtc.c > b/drivers/gpu/drm/armada/armada_crtc.c > index dadaf63..9705466 100644 > --- a/drivers/gpu/drm/armada/armada_crtc.c > +++ b/drivers/gpu/drm/armada/armada_crtc.c > @@ -413,16 +413,31 @@ static int armada_drm_crtc_mode_set(struct drm_crtc > *crtc, > struct armada_private *priv = crtc->dev->dev_private; > struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc); > struct armada_regs regs[16]; > + struct clk *clk; > uint32_t lm, rm, tm, bm, val, sclk; > unsigned long flags; > unsigned i; > bool interlaced; > + int clk_idx; > int ret; > > - /* First, check that this will succeed. */ > - ret = priv->ops->compute_crtc_clock(dcrtc, adj, NULL); > - if (ret) > - return ret; >
Re: Armada DRM driver on OLPC XO
On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote: > I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3 > aka PXA2128). After a bit of fighting, I have it running. Could you share your > X driver, or your methodology for testing hardware cursors? I'd like to test > your work there too. BTW... a point on this. As you don't have the LCD_SPU_ADV_REG register, you probably don't have support for ARGB cursors. DRM only supports ARGB cursors. You can't down-convert an ARGB cursor to something which looks reasonable in the kernel, so I'd suggest forgetting hardware cursors. Even converting ARGB to transparency + RGB looks rubbish and wrong. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Armada DRM driver on OLPC XO
On Fri, Jun 28, 2013 at 3:27 PM, Russell King - ARM Linux wrote: > On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote: >> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3 >> aka PXA2128). After a bit of fighting, I have it running. Could you share >> your >> X driver, or your methodology for testing hardware cursors? I'd like to test >> your work there too. > > BTW... a point on this. As you don't have the LCD_SPU_ADV_REG register, > you probably don't have support for ARGB cursors. DRM only supports ARGB > cursors. You can't down-convert an ARGB cursor to something which looks > reasonable in the kernel, so I'd suggest forgetting hardware cursors. > Even converting ARGB to transparency + RGB looks rubbish and wrong. Interesting. Yes, a previous developer battled unsuccessfully with hardware cursors and in the end we ended up using low color depth ones which don't look great. I was wondering if you had found something new, but it sounds like that we really are limited by the hardware. Thanks Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: armada_drm clock selection
On Fri, Jun 28, 2013 at 10:18:48PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jun 28, 2013 at 04:11:32PM -0400, Daniel Drake wrote:
> > +int armada_drm_find_best_clock(struct armada_private *priv, long
> > needed_rate)
> > +{
> > + int i;
> > +
> > + /* check if any clock can meet this rate directly */
> > + for (i = 0; i < ARMADA_MAX_CLOCK; i++) {
> > + struct clk *clk = priv->clk[i];
> > + long ref;
> > +
> > + if (!clk)
> > + continue;
> > +
> > + clk_set_rate(clk, needed_rate);
> > + ref = clk_get_rate(clk);
> > +
> > + if (ref % needed_rate == 0)
> > + return i;
> > + }
> > +
> > + /* fallback: return first available clock */
> > + for (i = 0; i < ARMADA_MAX_CLOCK; i++) {
> > + struct clk *clk = priv->clk[i];
> > + if (clk)
> > + return i;
> > + }
> > +
> > + return -ENOENT;
> > +}
>
> This can be a library function called by the compute_clock implementation.
> However, it's buggy. It's not returning the best clock. If we're going
> to go to the expense of potentially causing the clock tree to recalculate
> for every clock connected to this device, then we'd better do a good job
> here.
>
> That is - compute the source clock which can give us the _best_
> approximation to the required clock. We're almost doing that with the
> "ref % needed_rate" line, so if we're already doing that calculation,
> let's track for each iteration whether the clock gives us a better match
> than our previous one - and return the best approximation.
>
> And why use clk_set_rate()/clk_get_rate()? (a) what if clk_set_rate()
> fails (the API allows it to.) (b) what's wrong with clk_round_rate()?
There's a more fundamental point here.
The AXI and PLL clocks are shared between the two LCD controllers in
the 510. If one LCD controller is using one clock, what happens when
we call clk_set_rate() on that clock due to a change on the other LCD
controller.
That might result in the PLL dividers being modified and changing the
clock input to the other LCD controller. Moreover, we might find that
the rate isn't suitable for us, so we've just disrupted a clock for
no gain what so ever. That's even more reason to use the clk_round_rate(),
but it also opens the bigger question: if we're going to dynamically
select the clock input, we need to take notice of _both_ LCD controller
requirements.
Moreover, the AXI bus clock (yes, it's the actual bus clock) is one
available input to the LCD controller pixel clock. We certainly do
not want to go fiddling with that clock rate without good reason to
(iow, we're pretty sure we want to reprogram its rate _and_ use it,
and disrupt the clock rate that the AXI bus sees.) That will have
a direct impact on the throughput of all masters on the AXI bus -
which includes the CPU and memory.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Armada DRM driver on OLPC XO
On Fri, Jun 28, 2013 at 03:36:37PM -0600, Daniel Drake wrote: > On Fri, Jun 28, 2013 at 3:27 PM, Russell King - ARM Linux > wrote: > > On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote: > >> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3 > >> aka PXA2128). After a bit of fighting, I have it running. Could you share > >> your > >> X driver, or your methodology for testing hardware cursors? I'd like to > >> test > >> your work there too. > > > > BTW... a point on this. As you don't have the LCD_SPU_ADV_REG register, > > you probably don't have support for ARGB cursors. DRM only supports ARGB > > cursors. You can't down-convert an ARGB cursor to something which looks > > reasonable in the kernel, so I'd suggest forgetting hardware cursors. > > Even converting ARGB to transparency + RGB looks rubbish and wrong. > > Interesting. Yes, a previous developer battled unsuccessfully with > hardware cursors and in the end we ended up using low color depth ones > which don't look great. I was wondering if you had found something > new, but it sounds like that we really are limited by the hardware. The "something new" is that the Armada 510 has support for ARGB, not quite in the size that X and DRM prefers (64x64), but nevertheless it's full alpha-blended RGB. 64x32 seems to work and X seems to be happy with it - but there's no way at the moment for DRM to tell X about that kind of capability (so a generic kms driver can't use it.) However, as I say, that's not available on your SoC if you don't have the LCD_SPU_ADV_REG register. My plan is to push the cursor support out to the growing variant backends, and leave it unimplemented on anything but Armada 510. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Packard Bell EasyNote LV need i915.invert_brightness=1
[Daniel Vetter] >> Sounds like. Please file a bug report against ACPI -> Video on >> bugzilla.kernel.org. > > When you file that bug please add me and Jani Nikula to the cc > list. We have a few other inverted brightness quirks all on similar > machines. So this could all be due to the same strange interaction > between drm/i915 and teh specific ACPI implementation on these > machines. Thanks for the pointers. I've now reported the bug as https://bugzilla.kernel.org/show_bug.cgi?id=60221 >. -- Happy hacking Petter Reinholdtsen ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64475] Slow work and low brightness in Euro Track Simulator II game with HD6850
https://bugs.freedesktop.org/show_bug.cgi?id=64475 --- Comment #2 from commiethebeas...@gmail.com --- Created attachment 81676 --> https://bugs.freedesktop.org/attachment.cgi?id=81676&action=edit GALLIUM_HUD -- 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 64475] Slow work and low brightness in Euro Track Simulator II game with HD6850
https://bugs.freedesktop.org/show_bug.cgi?id=64475 --- Comment #3 from commiethebeas...@gmail.com --- Yes, governor is performance, power_profile is high. -- 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: [PATCH 000/165] radeon drm-next patches
On 26.06.2013 23:57, Julian Wollrath wrote: Hi, I just tried the DPM support out on a E-450 APU (HD6320) and it did not work like expected. In the terminal everything seemed ok but when I started a display manager, the screen showed garbage and the system basically locked up. The radeon and drm related parts of the syslog are below. If you need further information, feel free to ask. I have the same problem with the same APU. Disabling power gating (set enable_gfx_power_gating to false in sumo_dpm.c:sumo_dpm_init) fixes it. So this problem may related to power gating. The difference in power consumption seems to be small, but I'd still prefer it working. By the way, the "disable_gfx_power_gating_in_uvd" quirk is not actually used, seems to be some leftover from debugging or such. Best regards Grigori ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.10-rc7
On Sat, Jun 29, 2013 at 8:05 AM, Sergey Meirovich wrote: > > 3.10-rc7 doesn't compile for me > > rathamahata@piledriver /usr/local/src/linux-3.10-rc7 $ make -j1 bzImage > modules > make[1]: Nothing to be done for `all'. > make[1]: Nothing to be done for `relocs'. > CHK include/generated/uapi/linux/version.h > CHK include/generated/utsrelease.h > CALLscripts/checksyscalls.sh > CC scripts/mod/devicetable-offsets.s > GEN scripts/mod/devicetable-offsets.h > HOSTCC scripts/mod/file2alias.o > HOSTLD scripts/mod/modpost > CHK include/generated/compile.h > make[3]: `arch/x86/realmode/rm/realmode.bin' is up to date. > CC drivers/gpu/drm/radeon/r200.o > drivers/gpu/drm/radeon/r200.c: In function ‘r200_set_safe_registers’: > drivers/gpu/drm/radeon/r200.c:546:34: error: ‘r200_reg_safe_bm’ > undeclared (first use in this function) > rdev->config.r100.reg_safe_bm = r200_reg_safe_bm; > ^ > drivers/gpu/drm/radeon/r200.c:546:34: note: each undeclared identifier Hmm. Your config builds here fine. What does your drivers/gpu/drm/radeon/r200_reg_safe.h file look like? It's a generated file, and it sounds like it got mis-generated. There is possibly a broken Makefile rule that leaves it empty on errors or ^C: the rule is quiet_cmd_mkregtable = MKREGTABLE $@ cmd_mkregtable = $(obj)/mkregtable $< > $@ and if the 'mkregtable' binary is buggered, the above will leave an empty file around. And maybe your mkregtable failed to build earlier, leaving that empty file around and it will never fix itself up because of the "up-to-date" empty r200_reg_safe.h file. So removing the generated r200_reg_safe.h file (and possibly the mkregtable binary) and trying again might fix it. Which still leaves us with the question of how this happened, and a potentially fragile Makefile. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
https://bugs.freedesktop.org/show_bug.cgi?id=63935 --- Comment #55 from Grigori Goronzy --- Sorry for the noise, I am seeing a different issue related to DPM. -- 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 66384] New: VDPAU playback hangs when moving window between xrandr monitors
https://bugs.freedesktop.org/show_bug.cgi?id=66384 Priority: medium Bug ID: 66384 Assignee: dri-devel@lists.freedesktop.org Summary: VDPAU playback hangs when moving window between xrandr monitors Severity: normal Classification: Unclassified OS: All Reporter: mgo...@gentoo.org Hardware: Other Status: NEW Version: unspecified Component: Drivers/Gallium/r600 Product: Mesa I'm running live xorg/mesa with Radeon HD5450. I have two monitors connected and set up side-by-side using xrandr like the following: $ xrandr --output VGA-0 --mode 1280x960 --right-of DVI-0 Now, when I play a movie using mplayer2 with VDPAU driver and move the movie onto second monitor without pausing it first, the playback hangs for a minute or two. Then it resumes like nothing happened, no messages neither on console nor in dmesg. What's interesting is that it seems to happen only after moving half of the window. If I have it partially on both monitors, it plays back fine. After the hang it plays fine again, and if I then move it back to the first monitor, it again hangs after moving half of it. -- 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 66384] VDPAU playback hangs when moving window between xrandr monitors
https://bugs.freedesktop.org/show_bug.cgi?id=66384 Michał Górny changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) Version|unspecified |git -- 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 60231] New: DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 Summary: DisplayPort monitor not detected on PowerColor Radeon HD 4850 Product: Drivers Version: 2.5 Kernel Version: 3.10 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: prettyvani...@lavabit.com Regression: No Created an attachment (id=106381) --> (https://bugzilla.kernel.org/attachment.cgi?id=106381) dmesg output with dvi and displayport connected (drm.debug=0xE) I have a dual-monitor setup via my PowerColor Radeon HD 4850 - one monitor is connected via DVI, the other (main) one via DisplayPort. While I was using fglrx that setup worked fine, with the radeon driver/module though only the dvi monitor is detected. DisplayPort is always reported as disconnected, no matter whether it is the only connected monitor at boot or is hotplugged later. The monitors in question are a Samsung SyncMaster 970P via DVI and a Eizo FlexScan EV2333WH via DisplayPort. The Eizo does still work fine via DVI. I'm currently running a 3.10 mainline kernel (+ radeon dpm patches) on Arch Linux. I remember trying this about 2 years ago I think, when it didn't work as well. Trying the 3.0 lts-kernel yields the same results, 3.10 mainline without dpm patches ditto. I've attached the dmesg output with drm.debug=0xE set as kernel parameter. I have found another bug report at launchpad that seems to describe the same issue: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1035556 Since that bug also happens on a PowerColor card, it seems likely to be a brand-/model-specific issue. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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: Linux 3.10-rc7
On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich wrote: >> (and possibly the >> mkregtable binary) and trying again might fix it. > > Removing mkregtable has indeed the compile issue for me. Thanks! Ok, so something failed at an earlier build. That error is probably long gone, though, since the subsequent build failure ends up being just a symptom rather than the underlying cause. >> Which still leaves >> us with the question of how this happened, and a potentially fragile >> Makefile. Radeon/drm people - any ideas how that mkregtable failure happened? Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.10-rc7
On Sun, Jun 30, 2013 at 8:13 AM, Linus Torvalds wrote: > On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich > wrote: >>> (and possibly the >>> mkregtable binary) and trying again might fix it. >> >> Removing mkregtable has indeed the compile issue for me. Thanks! > > Ok, so something failed at an earlier build. That error is probably > long gone, though, since the subsequent build failure ends up being > just a symptom rather than the underlying cause. > >>> Which still leaves >>> us with the question of how this happened, and a potentially fragile >>> Makefile. > > Radeon/drm people - any ideas how that mkregtable failure happened? > I'd care if we can definitely rule out previous power fails or forced reboots. Otherwise just seems like noise, if gcc can produce 0 sized binaries then I'm sure we'd have other issues. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: armada_drm clock selection
On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote: > On 06/29/2013 05:06 PM, Daniel Drake wrote: >> On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux >> wrote: >>> Sure... lets add some background info first: the big problem here is the >>> completely different register layouts for the clock register: >>> >>> On Armada 510: >>> 31:30 - select the clock input from 4 possible sources: >>> 0 - AXI, 1 - EXT0, 2 - PLL, 3 - EXT1 >>> 29- loads the divider values >>> 27:16 - (broken) fractional divider - you never want to use this >>> 15:0 - integer divider > > The reason why I called fractional divider broken is because it skips > clock cycles which renders the clock useless for continuous clocking > requirements. For smart panel SPI, it might work - but as soon as no > board with that pops up, I suggest not to go for it. I think you mean "let's ignore the fractional divider until we have a board which uses a smart panel". >> With your clear explanations I think I can come up with an >> implementation that takes all these factors into account, offering >> access to a great deal of the available functionality. Should not be >> too difficult now that we have had this discussion, and I'd be happy >> to do so. But before I do that, a question popped up into my mind: is >> this complexity really worth it? > > Depends, with per-SoC callbacks we should be safe for every possible > requirement. With DT, the user always will have the option to add/remove > clocks passed by clocks/clock-names matching his requirements. That, I think, is why clock names have to be mandatory for this driver, so we know what each DT clock specified actually is. We can't really go and just specify one or two clocks when they may just be the external clocks and have no way for the driver to know that. >> For OLPC, we only ever use LCD1 with divider 2 for our panel, which >> only has 1 resolution. I think we use the fast AXI clock for HDMI >> path, which has a separate SCLK register. For armada 510, it looks >> like you are quite happy with the EXT1 clock, and you mentioned that >> on the 16x most of the clocks are broken, which might mean there is >> again just one clock of preference? > > As soon as you are required to use EDID provided modes, you will have > to provide the exact clock rate. With broken fractional divider on Dove > above, you are stuck to integer division. And none of the internal > frequencies give you multiple of 74.25MHz which is what you want for TV > applications. So for Dove, you almost always want to use extclk, if > connected to an external pll. Ahem. There is no such thing as an "exact clock rate". Even the world's most accurate clock (caesium fountain) is only accurate to 1 part in 10^14! (I have in the past worked in an equipment calibration laboratory with their own Rubidium standard synchronized to a remote Caesium fountain standard at the UK NPL, so you'll excuse me for being a pedant when it comes to that!) All that's required here is a clock rate which is "good enough". Getting it accurate to 4 significant digits is likely to be "good enough". The problem here is that the internal clocks are be 2GHz divided by an integer divider. The closest to 74.25MHz from the Dove's internal clocks is with a divider of 27, which gives you 74.07MHz, which is off by about 2.4% - far from "good enough", especially when you consider the video/ audio sync issues that would cause (you'd need about 1 additional audio sample per 50). >> So, could we just specify per-CRTC clock preference in platform data, >> DT, or something like that? e.g. we could just specify which SCLK bits >> to set and clear, and which Linux-level struct clk is engaged as a >> result. It adds a little burden for the platform implementor, but it >> would avoid all of the complications that you have mentioned. Or do >> you have a preference for the added flexibility? > > I suggest not to do any sophisticated approach to determine the "best" > clock. Just set the SCLK source determined by the name of first clock > passed either by DT or platform_data. This gives everybody the > flexibility but keeps implementation overhead small. The problem this gives is we need to know what SCLK setting to use, and I don't think specifying raw register values in DT is a particularly good solution to that. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: armada_drm clock selection
Hi, Thanks for all the clear comments and explanations - I'll address all of that in the next patch. On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux wrote: > Sure... lets add some background info first: the big problem here is the > completely different register layouts for the clock register: > > On Armada 510: > 31:30 - select the clock input from 4 possible sources: > 0 - AXI, 1 - EXT0, 2 - PLL, 3 - EXT1 > 29- loads the divider values > 27:16 - (broken) fractional divider - you never want to use this > 15:0 - integer divider > > Armada 16x: > 31:28 - select clock input from 4 possible sources using bit patterns. > 0 - AHB, 1 - PCLK, 2 - AXI, 3 - PLL > 27:16 - (broken) fractional divider > 15:0 - integer divider > > From drivers/video/mmp driver (MMP2/MMP3, aka Armada 610?): > 31- clock select > 28- disable bit > 27:16 - fractional divider > 15:12 - apparantly not used > 11:8 - DSI divider > 7:0 - integer divider MMP2 (Armada 610) and MMP3 (PXA2128, no Armada name) is even a bit more complex than that. On MMP2 the selectable clocks are written in bits 31:30 and are: 0 - AXI, 1 - LCD1, 2 - LCD2, 3 - HDMI On MMP3 the selectable clocks are written in bits 31:29 and are: 0 - AXI or LVDS (depending on bit 12) 1 - LCD1 2 - LCD2 3 - HDMI 7 - DSI When clock 0 is selected, bit 12 comes into effect for the final say on the clock selection. 0 = AXI, 1 = LVDS As you note, handling all this stuff is not trivial. And I also understand the complications that we do not want to change some clocks, if they are in use by another CRTC or are shared with other parts of the system. With your clear explanations I think I can come up with an implementation that takes all these factors into account, offering access to a great deal of the available functionality. Should not be too difficult now that we have had this discussion, and I'd be happy to do so. But before I do that, a question popped up into my mind: is this complexity really worth it? For OLPC, we only ever use LCD1 with divider 2 for our panel, which only has 1 resolution. I think we use the fast AXI clock for HDMI path, which has a separate SCLK register. For armada 510, it looks like you are quite happy with the EXT1 clock, and you mentioned that on the 16x most of the clocks are broken, which might mean there is again just one clock of preference? So, could we just specify per-CRTC clock preference in platform data, DT, or something like that? e.g. we could just specify which SCLK bits to set and clear, and which Linux-level struct clk is engaged as a result. It adds a little burden for the platform implementor, but it would avoid all of the complications that you have mentioned. Or do you have a preference for the added flexibility? Thanks Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: armada_drm clock selection
On 06/29/2013 05:06 PM, Daniel Drake wrote: On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux wrote: Sure... lets add some background info first: the big problem here is the completely different register layouts for the clock register: On Armada 510: 31:30 - select the clock input from 4 possible sources: 0 - AXI, 1 - EXT0, 2 - PLL, 3 - EXT1 29- loads the divider values 27:16 - (broken) fractional divider - you never want to use this 15:0 - integer divider The reason why I called fractional divider broken is because it skips clock cycles which renders the clock useless for continuous clocking requirements. For smart panel SPI, it might work - but as soon as no board with that pops up, I suggest not to go for it. Armada 16x: 31:28 - select clock input from 4 possible sources using bit patterns. 0 - AHB, 1 - PCLK, 2 - AXI, 3 - PLL 27:16 - (broken) fractional divider 15:0 - integer divider From drivers/video/mmp driver (MMP2/MMP3, aka Armada 610?): 31- clock select 28- disable bit 27:16 - fractional divider 15:12 - apparantly not used 11:8 - DSI divider 7:0 - integer divider MMP2 (Armada 610) and MMP3 (PXA2128, no Armada name) is even a bit more complex than that. On MMP2 the selectable clocks are written in bits 31:30 and are: 0 - AXI, 1 - LCD1, 2 - LCD2, 3 - HDMI On MMP3 the selectable clocks are written in bits 31:29 and are: 0 - AXI or LVDS (depending on bit 12) 1 - LCD1 2 - LCD2 3 - HDMI 7 - DSI When clock 0 is selected, bit 12 comes into effect for the final say on the clock selection. 0 = AXI, 1 = LVDS As you note, handling all this stuff is not trivial. And I also understand the complications that we do not want to change some clocks, if they are in use by another CRTC or are shared with other parts of the system. With your clear explanations I think I can come up with an implementation that takes all these factors into account, offering access to a great deal of the available functionality. Should not be too difficult now that we have had this discussion, and I'd be happy to do so. But before I do that, a question popped up into my mind: is this complexity really worth it? Depends, with per-SoC callbacks we should be safe for every possible requirement. With DT, the user always will have the option to add/remove clocks passed by clocks/clock-names matching his requirements. For OLPC, we only ever use LCD1 with divider 2 for our panel, which only has 1 resolution. I think we use the fast AXI clock for HDMI path, which has a separate SCLK register. For armada 510, it looks like you are quite happy with the EXT1 clock, and you mentioned that on the 16x most of the clocks are broken, which might mean there is again just one clock of preference? As soon as you are required to use EDID provided modes, you will have to provide the exact clock rate. With broken fractional divider on Dove above, you are stuck to integer division. And none of the internal frequencies give you multiple of 74.25MHz which is what you want for TV applications. So for Dove, you almost always want to use extclk, if connected to an external pll. So, could we just specify per-CRTC clock preference in platform data, DT, or something like that? e.g. we could just specify which SCLK bits to set and clear, and which Linux-level struct clk is engaged as a result. It adds a little burden for the platform implementor, but it would avoid all of the complications that you have mentioned. Or do you have a preference for the added flexibility? I suggest not to do any sophisticated approach to determine the "best" clock. Just set the SCLK source determined by the name of first clock passed either by DT or platform_data. This gives everybody the flexibility but keeps implementation overhead small. Sebastian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: armada_drm clock selection
On 06/29/2013 08:45 PM, Russell King - ARM Linux wrote: On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote: On 06/29/2013 05:06 PM, Daniel Drake wrote: On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux wrote: Sure... lets add some background info first: the big problem here is the completely different register layouts for the clock register: On Armada 510: 31:30 - select the clock input from 4 possible sources: 0 - AXI, 1 - EXT0, 2 - PLL, 3 - EXT1 29- loads the divider values 27:16 - (broken) fractional divider - you never want to use this 15:0 - integer divider The reason why I called fractional divider broken is because it skips clock cycles which renders the clock useless for continuous clocking requirements. For smart panel SPI, it might work - but as soon as no board with that pops up, I suggest not to go for it. I think you mean "let's ignore the fractional divider until we have a board which uses a smart panel". Yes, thanks for clearing that out. With your clear explanations I think I can come up with an implementation that takes all these factors into account, offering access to a great deal of the available functionality. Should not be too difficult now that we have had this discussion, and I'd be happy to do so. But before I do that, a question popped up into my mind: is this complexity really worth it? Depends, with per-SoC callbacks we should be safe for every possible requirement. With DT, the user always will have the option to add/remove clocks passed by clocks/clock-names matching his requirements. That, I think, is why clock names have to be mandatory for this driver, so we know what each DT clock specified actually is. We can't really go and just specify one or two clocks when they may just be the external clocks and have no way for the driver to know that. True. We should define a set of valid names per SoC and determine the required SCLK setting by that name. For OLPC, we only ever use LCD1 with divider 2 for our panel, which only has 1 resolution. I think we use the fast AXI clock for HDMI path, which has a separate SCLK register. For armada 510, it looks like you are quite happy with the EXT1 clock, and you mentioned that on the 16x most of the clocks are broken, which might mean there is again just one clock of preference? As soon as you are required to use EDID provided modes, you will have to provide the exact clock rate. With broken fractional divider on Dove above, you are stuck to integer division. And none of the internal frequencies give you multiple of 74.25MHz which is what you want for TV applications. So for Dove, you almost always want to use extclk, if connected to an external pll. Ahem. There is no such thing as an "exact clock rate". Even the world's most accurate clock (caesium fountain) is only accurate to 1 part in 10^14! (I have in the past worked in an equipment calibration laboratory with their own Rubidium standard synchronized to a remote Caesium fountain standard at the UK NPL, so you'll excuse me for being a pedant when it comes to that!) All that's required here is a clock rate which is "good enough". Getting it accurate to 4 significant digits is likely to be "good enough". Being an engineer, "exact" and "good enough" are synonymes for me ;) The problem here is that the internal clocks are be 2GHz divided by an integer divider. The closest to 74.25MHz from the Dove's internal clocks is with a divider of 27, which gives you 74.07MHz, which is off by about 2.4% - far from "good enough", especially when you consider the video/ audio sync issues that would cause (you'd need about 1 additional audio sample per 50). For video only and the monitor it should be sufficient but you are right, for audio and video it is not "good enough". So, could we just specify per-CRTC clock preference in platform data, DT, or something like that? e.g. we could just specify which SCLK bits to set and clear, and which Linux-level struct clk is engaged as a result. It adds a little burden for the platform implementor, but it would avoid all of the complications that you have mentioned. Or do you have a preference for the added flexibility? I suggest not to do any sophisticated approach to determine the "best" clock. Just set the SCLK source determined by the name of first clock passed either by DT or platform_data. This gives everybody the flexibility but keeps implementation overhead small. The problem this gives is we need to know what SCLK setting to use, and I don't think specifying raw register values in DT is a particularly good solution to that. I think it is never good style to have raw register values in DT. But different compatible strings for different SoCs plus clock names should give us enough information to setup the clock. Sebastian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo
Re: armada_drm clock selection
On Sat, Jun 29, 2013 at 09:06:47AM -0600, Daniel Drake wrote:
> MMP2 (Armada 610) and MMP3 (PXA2128, no Armada name) is even a bit
> more complex than that.
> On MMP2 the selectable clocks are written in bits 31:30 and are:
> 0 - AXI, 1 - LCD1, 2 - LCD2, 3 - HDMI
>
> On MMP3 the selectable clocks are written in bits 31:29 and are:
> 0 - AXI or LVDS (depending on bit 12)
> 1 - LCD1
> 2 - LCD2
> 3 - HDMI
> 7 - DSI
>
> When clock 0 is selected, bit 12 comes into effect for the final say
> on the clock selection. 0 = AXI, 1 = LVDS
Thanks for the info - I'll update my driver with that information.
> With your clear explanations I think I can come up with an
> implementation that takes all these factors into account, offering
> access to a great deal of the available functionality. Should not be
> too difficult now that we have had this discussion, and I'd be happy
> to do so. But before I do that, a question popped up into my mind: is
> this complexity really worth it?
The complexity question is something which has been bugging me as well.
I don't think we need the complexity of automatic clock selection. If
you have a platform like the Cubox, where you have an external clock
generator tied to the LCD clock input, then you might as well just use
that. If not, you're limited to what's provided on-board by the chip,
using whatever dividers it has.
So, I'd suggest that an initial approach would be something along the
lines of:
- if there is an external clock, can it generate the desired rate?
if yes, use it.
- otherwise, get the clock rate from the internal clocks and calculate
the appropriate divider. Use which ever one gives you the best
approximation that's better than (eg) 1%. If not, fail the mode set.
> For OLPC, we only ever use LCD1 with divider 2 for our panel, which
> only has 1 resolution. I think we use the fast AXI clock for HDMI
> path, which has a separate SCLK register. For armada 510, it looks
> like you are quite happy with the EXT1 clock, and you mentioned that
> on the 16x most of the clocks are broken, which might mean there is
> again just one clock of preference?
I'm not sure I said that on the 16x the clocks were broken - only that
they have different bit settings and probably a different architecture.
Although I have the 16x specs, I don't have hardware for it, and I
haven't spent that long digging in to it.
> So, could we just specify per-CRTC clock preference in platform data,
> DT, or something like that? e.g. we could just specify which SCLK bits
> to set and clear, and which Linux-level struct clk is engaged as a
> result. It adds a little burden for the platform implementor, but it
> would avoid all of the complications that you have mentioned. Or do
> you have a preference for the added flexibility?
We could do that as well, but I'm not keen on encoding register bit
values into DT, especially for a register which seems to have many
different variations.
This now brings me on to another important subject with DT vs DRM.
The way DRM is setup, it expects all resources for a particular
implementation to be known at 'drm_device' creation time. You can't
"hot-plug" additional parts of the "drm system" together. What this
means is that at driver load time (to use DRM terms) all parts must
be known.
However, for something like Dove, you have many different parts to
the system: considering just the scan out parts, you have:
- two identical LCD controller blocks
- a display controller block which routes the LCD controller outputs
- image rotation block
The problem is that a DT description of these would list each block
separately, so they would appear as separate devices, each with the
own separate DT properties. This means that if we have separate
struct device_driver's for each, we need some way to know when we
have collected all the necessary parts to initialize the DRM system.
Moreover, there are system considerations here: is it appropriate to
drive both LCD controller blocks as one DRM device or as two separate
DRM devices? That could be application specific.
And then we come to another issue: what if your setup doesn't have
two LCD controller blocks but only one like on the Armada 16x.
Is it worth having a "super-device" around the parts of each system
which you want to treat separately - iow something like this if you
wish to use them together:
display {
compatible = "marvell,armada-510-display";
clocks = <&axi_clk>, <&ext_clk0>, <&lcd_pll_clk>, <&ext_clk_1>;
lcd0 {
compatible = "marvell,armada-510-lcd";
reg = <0xf182 0x1000>;
interrupts = <47>;
...
};
lcd1 {
compatible = "marvell,armada-510-lcd";
reg = <0xf181 0x1000>;
interrupts = <46>;
...
};
Re: armada_drm clock selection
On Sat, Jun 29, 2013 at 1:26 PM, Russell King - ARM Linux wrote: > So, I'd suggest that an initial approach would be something along the > lines of: > - if there is an external clock, can it generate the desired rate? > if yes, use it. > - otherwise, get the clock rate from the internal clocks and calculate > the appropriate divider. Use which ever one gives you the best > approximation that's better than (eg) 1%. If not, fail the mode set. This sounds sane to me. According to your earlier mail, armada 510 is the only current target platform that has external clocks. For the fallback on internal clocks, we would not try to change the rate of any of them, we would just look at how close they can bring us to what is needed, as you describe. If any clocks are broken or useless on a specific platform, then they can be excluded from the DT or platform data. So this is really not far off from the ideas from Sebastian and me where we would simply pass in the information about the "interesting" clocks and be done with it. I agree that we need the DT have a way of not only providing the clock, but also indicating which clock in the SCLK register it refers to, and I also think the way to do that is by having a fixed, documented clock naming scheme. So that should not be a problem. I'll avoid putting register values in the DT. I think that resolves all the open questions that I had, so I will work on this early next week. > This now brings me on to another important subject with DT vs DRM. > The way DRM is setup, it expects all resources for a particular > implementation to be known at 'drm_device' creation time. You can't > "hot-plug" additional parts of the "drm system" together. What this > means is that at driver load time (to use DRM terms) all parts must > be known. Its unfortunate that we can't hotplug the DRM bits, but at least that is no longer an open question. The super-device approach sounds sane and would seem to reflect on other parts of the DT that I have worked with. It seems reasonable to take the viewpoint that the LCD is a child connected to the display controller parent, which is what the DT layout suggests. I wonder what other DRM drivers do DT-wise? Maybe I will look into that after we've progressed with the clocks. Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v4 0/3] Armada DRM driver
Quite a number of things has changed since the last revision in the core code - notably the move to use drm_plane for overlay, and the limited and restricted use of dma_buf so that gem objects can be passed to the GALCORE code and libbmm contiguous video frames can be imported into DRM. As I thought, this does require quite a number of new system calls, but the case which I care more about (vlc) doesn't pass rendered frames directly to the X server by physical address, it's not something I'm particularly concerned about - for vlc and the "normal" Xv protocol we can cache four DRM gem objects with their framebuffers pre-prepared meaning we just copy the frame and call the DRM set_plane function. What the loss of the create_phys() interface does mean is that the modified gstreamer gstbmmxvimagesink plugin will not work; it will need to be updated. I do *not* intend to support the hacky bidirectional Xv SHM hack which Marvell came up with there! I've left out the TDA998x changes and the final patch which depends on those changes which add the HDMI output for the cubox, so this series will be lacking the final parts of connector support. It is probable that the patch from the previous series can be trivially applied to this (or easily adapted if not.) Other changes: - the crtc exports a few attributes now for setting the colour transform mode. (CCIR601/709 to Computer vs "Studio" RGB). An automatic mode for these settings provided depending on selected resolution. - overlay has working brightness/contrast/saturation settings, but not hue - not worked that bit out yet. - hardware ARGB cursor support only in this version. - backend ops are now called variants, because the structure started to contain other stuff other than just function pointers. Armada510 backend moved to a separate file. - features requiring the SPU_ADV_REG (only present on Armada 510) can be disabled by the variant structure - such as interlace and ARGB cursor. - use of page_alloc() reduced down to 8K, enough to store the hardware cursor. This is all that that allocation was really used for anyway. - now uses a common kfifo queue to free used framebuffers at the appropriate time, both from the crtc code and the drm_plane code, rather than having this logic in several places. kfifo is a weird API and there's a note in the driver about that. - framebuffers now carry their configuration with them, to save having the pixel format decode scattered in several places in the driver. - power down FIFOs and RAMs not being used, and keep them powered down where possible. - minimum framebuffer size added, moved out from the X server driver. - maximum horizontal resolution dropped to 1920 to avoid a potential problem with V scaling (the RAM is apparantly 1920 pixels by 3 lines.) - protection preventing various gem objects being used in unexpected ways added - eg, you can't create a framebuffer from a cursor gem object or an imported object which is non-contiguous. - full range of colorkey modes for video supported (hey, it's just drm plane properties!) - loads of smaller cleanups, and a number of checkpatch fixes. Things left to do, in no particular order: - Creation of planar YUV formatted framebuffers - I suspect the planar YUV formats are not supported for graphic framebuffers even though Marvell document the register settings. (Where do you program the base addresses of the U and V planes?) Not a high priority as Vmeta produces UYVY encoded frames and it's more efficient to keep the native format. - Gamma support if anyone cares. Again, not high priority. - Resolution of the clocking conundrum. - Resolution of the DT specification conundrum (super-device?) - Specification of DRM connectors (DT but how?), their configuration, what they're connected to and what fixed format(s) they support. - CMA or no CMA - I've added a comment pointing out additional concerns about how to get the physical address from CMA. I think for most platforms this driver will be used on, the device address and physical address will be the same, but _conceptually_ they have never been the same in the kernel. - DCON support... I have no use for this, and the information in my documentation is pretty damned poor, so much so that I'm reluctant to try prodding around with it, especially as some of it is self-contradictory. Anyone who really cares about this can look at the issues there. Stuff omitted: - the DRM refcounting bug fix which breaks the i915 driver (but without it, booting with this driver results in a leaked refcount on the framebuffer thanks what I consider to be a bug in the DRM crtc code.) So don't boot this without something reporting itself as being connected with a valid mode. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 2/3] DRM: Armada: Add support for ARGB 32x64 or 64x32 hardware cursors
This patch adds ARGB hardware cursor support to the DRM driver for the
Marvell Armada SoCs. ARGB cursors are supported at either 32x64 or
64x32 resolutions.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_510.c |1 +
drivers/gpu/drm/armada/armada_crtc.c | 244 +-
drivers/gpu/drm/armada/armada_crtc.h |9 ++
drivers/gpu/drm/armada/armada_drm.h |1 +
drivers/gpu/drm/armada/armada_hw.h |6 +-
5 files changed, 255 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_510.c
b/drivers/gpu/drm/armada/armada_510.c
index a016888..59948ef 100644
--- a/drivers/gpu/drm/armada/armada_510.c
+++ b/drivers/gpu/drm/armada/armada_510.c
@@ -80,6 +80,7 @@ static int armada510_crtc_compute_clock(struct armada_crtc
*dcrtc,
const struct armada_variant armada510_ops = {
.has_spu_adv_reg = true,
+ .spu_adv_reg = ADV_HWC32ENABLE | ADV_HWC32ARGB | ADV_HWC32BLEND,
.init = armada510_init,
.crtc_init = armada510_crtc_init,
.crtc_compute_clock = armada510_crtc_compute_clock,
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index f489157..7df1101 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -381,8 +381,21 @@ void armada_drm_crtc_irq(struct armada_crtc *dcrtc, u32
stat)
val = readl_relaxed(base + LCD_SPU_ADV_REG);
val &= ~(ADV_VSYNC_L_OFF | ADV_VSYNC_H_OFF | ADV_VSYNCOFFEN);
val |= dcrtc->v[i].spu_adv_reg;
- writel_relaxed(val, dcrtc->base + LCD_SPU_ADV_REG);
+ writel_relaxed(val, base + LCD_SPU_ADV_REG);
}
+
+ if (stat & DUMB_FRAMEDONE && dcrtc->cursor_update) {
+ writel_relaxed(dcrtc->cursor_hw_pos,
+ base + LCD_SPU_HWC_OVSA_HPXL_VLN);
+ writel_relaxed(dcrtc->cursor_hw_sz,
+ base + LCD_SPU_HWC_HPXL_VLN);
+ armada_updatel(CFG_HWC_ENA,
+ CFG_HWC_ENA | CFG_HWC_1BITMOD | CFG_HWC_1BITENA,
+ base + LCD_SPU_DMA_CTRL0);
+ dcrtc->cursor_update = false;
+ armada_drm_crtc_disable_irq(dcrtc, DUMB_FRAMEDONE_ENA);
+ }
+
spin_unlock(&dcrtc->irq_lock);
if (stat & GRA_FRAME_IRQ) {
@@ -522,7 +535,8 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
adj->crtc_htotal;
dcrtc->v[1].spu_v_porch = tm << 16 | bm;
val = adj->crtc_hsync_start;
- dcrtc->v[1].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN;
+ dcrtc->v[1].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN |
+ priv->variant->spu_adv_reg;
if (interlaced) {
/* Odd interlaced frame */
@@ -530,7 +544,8 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
(1 << 16);
dcrtc->v[0].spu_v_porch = dcrtc->v[1].spu_v_porch + 1;
val = adj->crtc_hsync_start - adj->crtc_htotal / 2;
- dcrtc->v[0].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN;
+ dcrtc->v[0].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN |
+ priv->variant->spu_adv_reg;
} else {
dcrtc->v[0] = dcrtc->v[1];
}
@@ -545,10 +560,11 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
armada_reg_queue_set(regs, i, dcrtc->v[0].spu_v_h_total,
LCD_SPUT_V_H_TOTAL);
- if (priv->variant->has_spu_adv_reg)
+ if (priv->variant->has_spu_adv_reg) {
armada_reg_queue_mod(regs, i, dcrtc->v[0].spu_adv_reg,
ADV_VSYNC_L_OFF | ADV_VSYNC_H_OFF |
ADV_VSYNCOFFEN, LCD_SPU_ADV_REG);
+ }
val = CFG_GRA_ENA | CFG_GRA_HSMOOTH;
val |= CFG_GRA_FMT(drm_fb_to_armada_fb(dcrtc->crtc.fb)->fmt);
@@ -640,11 +656,229 @@ static const struct drm_crtc_helper_funcs
armada_crtc_helper_funcs = {
.disable= armada_drm_crtc_disable,
};
+static void armada_load_cursor_argb(void __iomem *base, uint32_t *pix,
+ unsigned stride, unsigned width, unsigned height)
+{
+ uint32_t addr;
+ unsigned y;
+
+ addr = SRAM_HWC32_RAM1;
+ for (y = 0; y < height; y++) {
+ uint32_t *p = &pix[y * stride];
+ unsigned x;
+
+ for (x = 0; x < width; x++, p++) {
+ uint32_t val = *p;
+
+ val = (val & 0xff00ff00) |
+ (val & 0x00ff) << 16 |
+ (val & 0x00ff) >> 16;
+
+ writel_relaxed(val,
+ base + LCD_SPU_SRAM_WRDAT);
+ writel_relaxed(addr | SRAM_WRITE,
+ base +
[PATCH RFC 3/3] DRM: Armada: support for dma_buf import into gem
Support importing certain dma_bufs back into gem - notably those which
are either contiguous or are our own exports which do not use
dma_map_sg().
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_drv.c |4 +-
drivers/gpu/drm/armada/armada_fb.c |6 +++
drivers/gpu/drm/armada/armada_gem.c | 81 ++-
drivers/gpu/drm/armada/armada_gem.h |4 ++
4 files changed, 92 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index e0a08e9..268ea28 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -311,9 +311,9 @@ static struct drm_driver armada_drm_driver = {
.gem_init_object= NULL,
.gem_free_object= armada_gem_free_object,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = NULL,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = armada_gem_prime_export,
- .gem_prime_import = NULL,
+ .gem_prime_import = armada_gem_prime_import,
.dumb_create= armada_gem_dumb_create,
.dumb_map_offset= armada_gem_dumb_map_offset,
.dumb_destroy = armada_gem_dumb_destroy,
diff --git a/drivers/gpu/drm/armada/armada_fb.c
b/drivers/gpu/drm/armada/armada_fb.c
index 5154f04..28965e3 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -120,6 +120,12 @@ static struct drm_framebuffer *armada_fb_create(struct
drm_device *dev,
return ERR_PTR(-ENOENT);
}
+ if (obj->obj.import_attach && !obj->sgt) {
+ ret = armada_gem_map_import(obj);
+ if (ret)
+ goto unref;
+ }
+
/* Framebuffer objects must have a valid device address for scanout */
if (obj->dev_addr == DMA_ERROR_CODE) {
ret = -EINVAL;
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
index d09fa14..ad517ce 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -70,6 +70,12 @@ void armada_gem_free_object(struct drm_gem_object *obj)
iounmap(dobj->addr);
}
+ if (dobj->obj.import_attach) {
+ /* We only ever display imported data */
+ dma_buf_unmap_attachment(dobj->obj.import_attach, dobj->sgt,
+DMA_TO_DEVICE);
+ drm_prime_gem_destroy(&dobj->obj, NULL);
+ }
drm_gem_object_release(&dobj->obj);
@@ -270,6 +276,12 @@ int armada_gem_dumb_map_offset(struct drm_file *file,
struct drm_device *dev,
goto err_unlock;
}
+ /* Don't allow imported objects to be mapped */
+ if (obj->obj.import_attach) {
+ ret = -EINVAL;
+ goto err_unlock;
+ }
+
if (!obj->obj.map_list.map)
ret = drm_gem_create_mmap_offset(&obj->obj);
@@ -537,5 +549,72 @@ armada_gem_prime_export(struct drm_device *dev, struct
drm_gem_object *obj,
int flags)
{
return dma_buf_export(obj, &armada_gem_prime_dmabuf_ops, obj->size,
- flags);
+ O_RDWR);
+}
+
+struct drm_gem_object *
+armada_gem_prime_import(struct drm_device *dev, struct dma_buf *buf)
+{
+ struct dma_buf_attachment *attach;
+ struct armada_gem_object *dobj;
+
+ if (buf->ops == &armada_gem_prime_dmabuf_ops) {
+ struct drm_gem_object *obj = buf->priv;
+ if (obj->dev == dev) {
+ /*
+* Importing our own dmabuf(s) increases the
+* refcount on the gem object itself.
+*/
+ drm_gem_object_reference(obj);
+ dma_buf_put(buf);
+ return obj;
+ }
+ }
+
+ attach = dma_buf_attach(buf, dev->dev);
+ if (IS_ERR(attach))
+ return ERR_CAST(attach);
+
+ dobj = armada_gem_alloc_private_object(dev, buf->size);
+ if (!dobj) {
+ dma_buf_detach(buf, attach);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ dobj->obj.import_attach = attach;
+
+ /*
+* Don't call dma_buf_map_attachment() here - it maps the
+* scatterlist immediately for DMA, and this is not always
+* an appropriate thing to do.
+*/
+ return &dobj->obj;
+}
+
+int armada_gem_map_import(struct armada_gem_object *dobj)
+{
+ int ret;
+
+ dobj->sgt = dma_buf_map_attachment(dobj->obj.import_attach,
+ DMA_TO_DEVICE);
+ if (!dobj->sgt) {
+ DRM_ERROR("dma_buf_map_attachment() returned NULL\n");
+ return -EINVAL;
+ }
+ if (IS_ERR(dobj->sg
Re: Linux 3.10-rc7
On Sat, Jun 29, 2013 at 4:52 PM, Sergey Meirovich wrote: > > There was overheating issue, that caused forced power off in the > middle of the first compile. Ok, then the thing is easily explained by simply the filesystem being shut down in an incomplete state. Sounds like the mkregtable binary had been created but not written out, and the kernel (or rather, shell) considers an empty executable to the same as "true", so after the machine came back, that counts as a "successful" binary, it just obviously doesn't write anything to stdout, which in turn then explains the empty r200_reg_safe.h file. So basically it boils down to: if the machine shuts down in the middle of a build, without "make" having time to clean up partially built files etc, you can get into strange inconsistent build trees and you might want to do a "git clean -dqfx" to get rid of everything generated. But in your case it was probably just that one file. Might be a good idea to do a clean rebuild anyway. (Side note: I've seen 'ccache' have odd stale caches too after unclean shutdowns, and then it's not sufficient to clean the build tree, you need to do "ccache -C" too). Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: drm init call takes large time
From: Abbas Raza
DRM_INFO calls in the drm init routines are causing a large delay at boot time
due to which imx_drm_init call average takes around 26 ms. Changing DRM_INFO to
DRM_DEBUG reduces startup time to < 3ms.
Signed-off-by: Abbas Raza
CC: David Airlie
Acked-by: Dmitry Eremin-Solenikov
---
drivers/gpu/drm/drm_irq.c | 6 +++---
drivers/gpu/drm/drm_platform.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c798eea..782f5ff 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -252,13 +252,13 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
if (!dev->_vblank_time)
goto err;
- DRM_INFO("Supports vblank timestamp caching Rev 1 (10.10.2010).\n");
+ DRM_DEBUG("Supports vblank timestamp caching Rev 1 (10.10.2010).\n");
/* Driver specific high-precision vblank timestamping supported? */
if (dev->driver->get_vblank_timestamp)
- DRM_INFO("Driver supports precise vblank timestamp query.\n");
+ DRM_DEBUG("Driver supports precise vblank timestamp query.\n");
else
- DRM_INFO("No driver support for vblank timestamp query.\n");
+ DRM_DEBUG("No driver support for vblank timestamp query.\n");
/* Zero per-crtc vblank stuff */
for (i = 0; i < num_crtcs; i++) {
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index 82431dc..7649963 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -92,7 +92,7 @@ int drm_get_platform_dev(struct platform_device *platdev,
mutex_unlock(&drm_global_mutex);
- DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n",
+ DRM_DEBUG("Initialized %s %d.%d.%d %s on minor %d\n",
driver->name, driver->major, driver->minor, driver->patchlevel,
driver->date, dev->primary->index);
--
1.8.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66349] New: Using SB shader optimization caused segfault in Serious Sam 3: BFE
0x0838e785 in ?? () -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/38b59634/attachment-0001.html>
[Bug 65274] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! (non-EFI laptop)
https://bugs.freedesktop.org/show_bug.cgi?id=65274 russianneuromancer at ya.ru changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from russianneuromancer at ya.ru --- Not reproducible anymore on 3.10-rc7. Both UVD modules seems like initialized successfully now: ~$ dmesg | grep UVD [2.650046] [drm] UVD initialized successfully. [ 12.828068] [drm] UVD initialized successfully. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/52a274b9/attachment.html>
[Bug 66352] New: GPU lockup in L4D2 on TURKS with HyperZ
https://bugs.freedesktop.org/show_bug.cgi?id=66352 Priority: medium Bug ID: 66352 Assignee: dri-devel at lists.freedesktop.org Summary: GPU lockup in L4D2 on TURKS with HyperZ Severity: normal Classification: Unclassified OS: FreeBSD Reporter: russianneuromancer at ya.ru Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 81668 --> https://bugs.freedesktop.org/attachment.cgi?id=81668&action=edit dmesg Lockup described in bug 64220 was happen right after campaign start (in first minute) but this lockup usually happen later - in first hour of playing. This lockup is not reproducible when HyperZ is disabled, so probably (like bug 64220) is related to HyperZ. [ 2160.750951] radeon :01:00.0: GPU lockup CP stall for more than 1msec [ 2160.750966] radeon :01:00.0: GPU lockup (waiting for 0x0002525f last fence id 0x0002525c) [ 2160.786068] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00174118 and cpu addr 0xc9000681c118 [ 2160.787147] radeon :01:00.0: Saved 183 dwords of commands on ring 0. [ 2160.787166] radeon :01:00.0: GPU softreset: 0x0019 [ 2160.787175] radeon :01:00.0: GRBM_STATUS = 0xE7730CA0 [ 2160.787177] radeon :01:00.0: GRBM_STATUS_SE0 = 0xFC01 [ 2160.787180] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 2160.787182] radeon :01:00.0: SRBM_STATUS = 0x20C0 [ 2160.787184] radeon :01:00.0: SRBM_STATUS2 = 0x [ 2160.787186] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x0100 [ 2160.787189] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x000D1000 [ 2160.787191] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x00068506 [ 2160.787193] radeon :01:00.0: R_008680_CP_STAT = 0x80878647 [ 2160.787196] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 2160.787356] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [ 2160.787410] radeon :01:00.0: SRBM_SOFT_RESET=0x0100 [ 2160.788559] radeon :01:00.0: GRBM_STATUS = 0x3828 [ 2160.788561] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [ 2160.788563] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 2160.788565] radeon :01:00.0: SRBM_STATUS = 0x20C0 [ 2160.788568] radeon :01:00.0: SRBM_STATUS2 = 0x [ 2160.788570] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 2160.788572] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [ 2160.788574] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [ 2160.788576] radeon :01:00.0: R_008680_CP_STAT = 0x [ 2160.788579] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 2160.788589] radeon :01:00.0: GPU reset succeeded, trying to resume [ 2160.793777] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 2160.793895] radeon :01:00.0: WB enabled [ 2160.793900] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x8801fb519c00 [ 2160.793904] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x8801fb519c0c [ 2160.796145] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00174118 and cpu addr 0xc900079b2118 [ 2160.812389] [drm] ring test on 0 succeeded in 2 usecs [ 2160.812457] [drm] ring test on 3 succeeded in 1 usecs [ 2160.987496] [drm] ring test on 5 succeeded in 1 usecs [ 2160.987512] [drm] UVD initialized successfully. [ 2161.219416] [drm] ib test on ring 0 succeeded in 0 usecs [ 2161.219497] [drm] ib test on ring 3 succeeded in 1 usecs [ 2161.370073] [drm:r600_uvd_ib_test] *ERROR* radeon: failed to get create msg (-22). [ 2161.370094] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-22). ~$ lspci | grep VGA 00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI BeaverCreek [Radeon HD 6620G] 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Whistler [Radeon HD 6600M/6700M/7600M Series] (DRI_PRIME is used to launch game.) Linux 3.10-rc7 libdrm 2.4.45+git20130607.a0178c00 Mesa 9.2.0~git20130627.15085b47 xserver-xorg-video-radeon 7.1.99+git20130531.bd2557ea Xserver 1.13.4~git20130508+server-1.13-branch.10c42f57 Kubuntu 13.04 x86_64 updated from Xorg Edgers PPA. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/d893388a/attachment.html>
[Bug 65274] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! (non-EFI laptop)
https://bugs.freedesktop.org/show_bug.cgi?id=65274 Christian K?nig changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #7 from Christian K?nig --- Good, so we can probably close this bugreport. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/fad9dbe5/attachment.html>
[PATCH 000/165] radeon drm-next patches
Alex Deucher wrote: > On Thu, Jun 27, 2013 at 9:12 AM, Andy Furniss wrote: >> Alex Deucher wrote: >>> >>> On Wed, Jun 26, 2013 at 9:21 AM, wrote: From: Alex Deucher These are the radeon patches for 3.11. Some of these patches are huge so, it might be easier to review things here: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip >>> >>> >>> Updated branch: >>> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip-2 >>> Takes into account comments from Jerome a Christian and contains a few >>> DPM fixes. >> >> >> I see there's a 3 now - I tested that (I guess currently it's the same as 2 >> anyway). >> >> On my rv790 there are no regressions so far, but whatever I do it stays low. > > This should work much better with with wip-5. Yes, this works on my rv790 games get high and using vdpau/gl for video stays low (which is nice as the fan on my card is too noisy on high). One thing which I guess 99.999% of people won't notice is that doing any thing with plain X + fluxbox (so no compositing) very briefly ramps up the speed. As my fan is just audible on low but very quick to respond I can hear every time the screen gets updated eg. switching desktops, browsing+scrolling or switching tabs, even typing dmesg in an xterm which time shows as taking < 0.1 sec results in a fan change.
[PATCH 000/165] radeon drm-next patches
Hi, > Yes, this works on my rv790 games get high and using vdpau/gl for video stays low (which is nice as the fan on my card is too noisy on high). > > One thing which I guess 99.999% of people won't notice is that doing any thing with plain X + fluxbox (so no compositing) very briefly ramps up the speed. > > As my fan is just audible on low but very quick to respond I can hear every time the screen gets updated eg. switching desktops, browsing+scrolling or switching tabs, even typing dmesg in an xterm which time shows as taking < 0.1 sec results in a fan change. Probably a low-pass filter is needed/has to be configured in front of the freq. scaling engine? Ilyes > > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/bfb7d15c/attachment-0001.html>
Packard Bell EasyNote LV need i915.invert_brightness=1
[Daniel Vetter] >> Sounds like. Please file a bug report against ACPI -> Video on >> bugzilla.kernel.org. > > When you file that bug please add me and Jani Nikula to the cc > list. We have a few other inverted brightness quirks all on similar > machines. So this could all be due to the same strange interaction > between drm/i915 and teh specific ACPI implementation on these > machines. Thanks for the pointers. I've now reported the bug as https://bugzilla.kernel.org/show_bug.cgi?id=60221 >. -- Happy hacking Petter Reinholdtsen
[Bug 64475] Slow work and low brightness in Euro Track Simulator II game with HD6850
https://bugs.freedesktop.org/show_bug.cgi?id=64475 --- Comment #2 from commiethebeastie at gmail.com --- Created attachment 81676 --> https://bugs.freedesktop.org/attachment.cgi?id=81676&action=edit GALLIUM_HUD -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/8bcd072d/attachment.html>
[Bug 64475] Slow work and low brightness in Euro Track Simulator II game with HD6850
https://bugs.freedesktop.org/show_bug.cgi?id=64475 --- Comment #3 from commiethebeastie at gmail.com --- Yes, governor is performance, power_profile is high. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/44dc8bc2/attachment.html>
[PATCH 000/165] radeon drm-next patches
On 26.06.2013 23:57, Julian Wollrath wrote: > Hi, > > I just tried the DPM support out on a E-450 APU (HD6320) and it did not > work like expected. In the terminal everything seemed ok but when I > started a display manager, the screen showed garbage and the system > basically locked up. The radeon and drm related parts of the syslog are > below. > > If you need further information, feel free to ask. > I have the same problem with the same APU. Disabling power gating (set enable_gfx_power_gating to false in sumo_dpm.c:sumo_dpm_init) fixes it. So this problem may related to power gating. The difference in power consumption seems to be small, but I'd still prefer it working. By the way, the "disable_gfx_power_gating_in_uvd" quirk is not actually used, seems to be some leftover from debugging or such. Best regards Grigori
Linux 3.10-rc7
On Sat, Jun 29, 2013 at 8:05 AM, Sergey Meirovich wrote: > > 3.10-rc7 doesn't compile for me > > rathamahata at piledriver /usr/local/src/linux-3.10-rc7 $ make -j1 bzImage > modules > make[1]: Nothing to be done for `all'. > make[1]: Nothing to be done for `relocs'. > CHK include/generated/uapi/linux/version.h > CHK include/generated/utsrelease.h > CALLscripts/checksyscalls.sh > CC scripts/mod/devicetable-offsets.s > GEN scripts/mod/devicetable-offsets.h > HOSTCC scripts/mod/file2alias.o > HOSTLD scripts/mod/modpost > CHK include/generated/compile.h > make[3]: `arch/x86/realmode/rm/realmode.bin' is up to date. > CC drivers/gpu/drm/radeon/r200.o > drivers/gpu/drm/radeon/r200.c: In function ?r200_set_safe_registers?: > drivers/gpu/drm/radeon/r200.c:546:34: error: ?r200_reg_safe_bm? > undeclared (first use in this function) > rdev->config.r100.reg_safe_bm = r200_reg_safe_bm; > ^ > drivers/gpu/drm/radeon/r200.c:546:34: note: each undeclared identifier Hmm. Your config builds here fine. What does your drivers/gpu/drm/radeon/r200_reg_safe.h file look like? It's a generated file, and it sounds like it got mis-generated. There is possibly a broken Makefile rule that leaves it empty on errors or ^C: the rule is quiet_cmd_mkregtable = MKREGTABLE $@ cmd_mkregtable = $(obj)/mkregtable $< > $@ and if the 'mkregtable' binary is buggered, the above will leave an empty file around. And maybe your mkregtable failed to build earlier, leaving that empty file around and it will never fix itself up because of the "up-to-date" empty r200_reg_safe.h file. So removing the generated r200_reg_safe.h file (and possibly the mkregtable binary) and trying again might fix it. Which still leaves us with the question of how this happened, and a potentially fragile Makefile. Linus
[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
https://bugs.freedesktop.org/show_bug.cgi?id=63935 --- Comment #55 from Grigori Goronzy --- Sorry for the noise, I am seeing a different issue related to DPM. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/f26502a5/attachment.html>
[Bug 66384] New: VDPAU playback hangs when moving window between xrandr monitors
https://bugs.freedesktop.org/show_bug.cgi?id=66384 Priority: medium Bug ID: 66384 Assignee: dri-devel at lists.freedesktop.org Summary: VDPAU playback hangs when moving window between xrandr monitors Severity: normal Classification: Unclassified OS: All Reporter: mgorny at gentoo.org Hardware: Other Status: NEW Version: unspecified Component: Drivers/Gallium/r600 Product: Mesa I'm running live xorg/mesa with Radeon HD5450. I have two monitors connected and set up side-by-side using xrandr like the following: $ xrandr --output VGA-0 --mode 1280x960 --right-of DVI-0 Now, when I play a movie using mplayer2 with VDPAU driver and move the movie onto second monitor without pausing it first, the playback hangs for a minute or two. Then it resumes like nothing happened, no messages neither on console nor in dmesg. What's interesting is that it seems to happen only after moving half of the window. If I have it partially on both monitors, it plays back fine. After the hang it plays fine again, and if I then move it back to the first monitor, it again hangs after moving half of it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/5625e5f6/attachment.html>
[Bug 66384] VDPAU playback hangs when moving window between xrandr monitors
https://bugs.freedesktop.org/show_bug.cgi?id=66384 Micha? G?rny changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) Version|unspecified |git -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130629/c4552ed6/attachment.html>
[Bug 60231] New: DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 Summary: DisplayPort monitor not detected on PowerColor Radeon HD 4850 Product: Drivers Version: 2.5 Kernel Version: 3.10 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: prettyvanilla at lavabit.com Regression: No Created an attachment (id=106381) --> (https://bugzilla.kernel.org/attachment.cgi?id=106381) dmesg output with dvi and displayport connected (drm.debug=0xE) I have a dual-monitor setup via my PowerColor Radeon HD 4850 - one monitor is connected via DVI, the other (main) one via DisplayPort. While I was using fglrx that setup worked fine, with the radeon driver/module though only the dvi monitor is detected. DisplayPort is always reported as disconnected, no matter whether it is the only connected monitor at boot or is hotplugged later. The monitors in question are a Samsung SyncMaster 970P via DVI and a Eizo FlexScan EV2333WH via DisplayPort. The Eizo does still work fine via DVI. I'm currently running a 3.10 mainline kernel (+ radeon dpm patches) on Arch Linux. I remember trying this about 2 years ago I think, when it didn't work as well. Trying the 3.0 lts-kernel yields the same results, 3.10 mainline without dpm patches ditto. I've attached the dmesg output with drm.debug=0xE set as kernel parameter. I have found another bug report at launchpad that seems to describe the same issue: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1035556 Since that bug also happens on a PowerColor card, it seems likely to be a brand-/model-specific issue. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
Linux 3.10-rc7
On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich wrote: >> (and possibly the >> mkregtable binary) and trying again might fix it. > > Removing mkregtable has indeed the compile issue for me. Thanks! Ok, so something failed at an earlier build. That error is probably long gone, though, since the subsequent build failure ends up being just a symptom rather than the underlying cause. >> Which still leaves >> us with the question of how this happened, and a potentially fragile >> Makefile. Radeon/drm people - any ideas how that mkregtable failure happened? Linus
armada_drm clock selection
On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote: > On 06/29/2013 05:06 PM, Daniel Drake wrote: >> On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux >> wrote: >>> Sure... lets add some background info first: the big problem here is the >>> completely different register layouts for the clock register: >>> >>> On Armada 510: >>> 31:30 - select the clock input from 4 possible sources: >>> 0 - AXI, 1 - EXT0, 2 - PLL, 3 - EXT1 >>> 29- loads the divider values >>> 27:16 - (broken) fractional divider - you never want to use this >>> 15:0 - integer divider > > The reason why I called fractional divider broken is because it skips > clock cycles which renders the clock useless for continuous clocking > requirements. For smart panel SPI, it might work - but as soon as no > board with that pops up, I suggest not to go for it. I think you mean "let's ignore the fractional divider until we have a board which uses a smart panel". >> With your clear explanations I think I can come up with an >> implementation that takes all these factors into account, offering >> access to a great deal of the available functionality. Should not be >> too difficult now that we have had this discussion, and I'd be happy >> to do so. But before I do that, a question popped up into my mind: is >> this complexity really worth it? > > Depends, with per-SoC callbacks we should be safe for every possible > requirement. With DT, the user always will have the option to add/remove > clocks passed by clocks/clock-names matching his requirements. That, I think, is why clock names have to be mandatory for this driver, so we know what each DT clock specified actually is. We can't really go and just specify one or two clocks when they may just be the external clocks and have no way for the driver to know that. >> For OLPC, we only ever use LCD1 with divider 2 for our panel, which >> only has 1 resolution. I think we use the fast AXI clock for HDMI >> path, which has a separate SCLK register. For armada 510, it looks >> like you are quite happy with the EXT1 clock, and you mentioned that >> on the 16x most of the clocks are broken, which might mean there is >> again just one clock of preference? > > As soon as you are required to use EDID provided modes, you will have > to provide the exact clock rate. With broken fractional divider on Dove > above, you are stuck to integer division. And none of the internal > frequencies give you multiple of 74.25MHz which is what you want for TV > applications. So for Dove, you almost always want to use extclk, if > connected to an external pll. Ahem. There is no such thing as an "exact clock rate". Even the world's most accurate clock (caesium fountain) is only accurate to 1 part in 10^14! (I have in the past worked in an equipment calibration laboratory with their own Rubidium standard synchronized to a remote Caesium fountain standard at the UK NPL, so you'll excuse me for being a pedant when it comes to that!) All that's required here is a clock rate which is "good enough". Getting it accurate to 4 significant digits is likely to be "good enough". The problem here is that the internal clocks are be 2GHz divided by an integer divider. The closest to 74.25MHz from the Dove's internal clocks is with a divider of 27, which gives you 74.07MHz, which is off by about 2.4% - far from "good enough", especially when you consider the video/ audio sync issues that would cause (you'd need about 1 additional audio sample per 50). >> So, could we just specify per-CRTC clock preference in platform data, >> DT, or something like that? e.g. we could just specify which SCLK bits >> to set and clear, and which Linux-level struct clk is engaged as a >> result. It adds a little burden for the platform implementor, but it >> would avoid all of the complications that you have mentioned. Or do >> you have a preference for the added flexibility? > > I suggest not to do any sophisticated approach to determine the "best" > clock. Just set the SCLK source determined by the name of first clock > passed either by DT or platform_data. This gives everybody the > flexibility but keeps implementation overhead small. The problem this gives is we need to know what SCLK setting to use, and I don't think specifying raw register values in DT is a particularly good solution to that.
armada_drm clock selection
On Sat, Jun 29, 2013 at 09:06:47AM -0600, Daniel Drake wrote:
> MMP2 (Armada 610) and MMP3 (PXA2128, no Armada name) is even a bit
> more complex than that.
> On MMP2 the selectable clocks are written in bits 31:30 and are:
> 0 - AXI, 1 - LCD1, 2 - LCD2, 3 - HDMI
>
> On MMP3 the selectable clocks are written in bits 31:29 and are:
> 0 - AXI or LVDS (depending on bit 12)
> 1 - LCD1
> 2 - LCD2
> 3 - HDMI
> 7 - DSI
>
> When clock 0 is selected, bit 12 comes into effect for the final say
> on the clock selection. 0 = AXI, 1 = LVDS
Thanks for the info - I'll update my driver with that information.
> With your clear explanations I think I can come up with an
> implementation that takes all these factors into account, offering
> access to a great deal of the available functionality. Should not be
> too difficult now that we have had this discussion, and I'd be happy
> to do so. But before I do that, a question popped up into my mind: is
> this complexity really worth it?
The complexity question is something which has been bugging me as well.
I don't think we need the complexity of automatic clock selection. If
you have a platform like the Cubox, where you have an external clock
generator tied to the LCD clock input, then you might as well just use
that. If not, you're limited to what's provided on-board by the chip,
using whatever dividers it has.
So, I'd suggest that an initial approach would be something along the
lines of:
- if there is an external clock, can it generate the desired rate?
if yes, use it.
- otherwise, get the clock rate from the internal clocks and calculate
the appropriate divider. Use which ever one gives you the best
approximation that's better than (eg) 1%. If not, fail the mode set.
> For OLPC, we only ever use LCD1 with divider 2 for our panel, which
> only has 1 resolution. I think we use the fast AXI clock for HDMI
> path, which has a separate SCLK register. For armada 510, it looks
> like you are quite happy with the EXT1 clock, and you mentioned that
> on the 16x most of the clocks are broken, which might mean there is
> again just one clock of preference?
I'm not sure I said that on the 16x the clocks were broken - only that
they have different bit settings and probably a different architecture.
Although I have the 16x specs, I don't have hardware for it, and I
haven't spent that long digging in to it.
> So, could we just specify per-CRTC clock preference in platform data,
> DT, or something like that? e.g. we could just specify which SCLK bits
> to set and clear, and which Linux-level struct clk is engaged as a
> result. It adds a little burden for the platform implementor, but it
> would avoid all of the complications that you have mentioned. Or do
> you have a preference for the added flexibility?
We could do that as well, but I'm not keen on encoding register bit
values into DT, especially for a register which seems to have many
different variations.
This now brings me on to another important subject with DT vs DRM.
The way DRM is setup, it expects all resources for a particular
implementation to be known at 'drm_device' creation time. You can't
"hot-plug" additional parts of the "drm system" together. What this
means is that at driver load time (to use DRM terms) all parts must
be known.
However, for something like Dove, you have many different parts to
the system: considering just the scan out parts, you have:
- two identical LCD controller blocks
- a display controller block which routes the LCD controller outputs
- image rotation block
The problem is that a DT description of these would list each block
separately, so they would appear as separate devices, each with the
own separate DT properties. This means that if we have separate
struct device_driver's for each, we need some way to know when we
have collected all the necessary parts to initialize the DRM system.
Moreover, there are system considerations here: is it appropriate to
drive both LCD controller blocks as one DRM device or as two separate
DRM devices? That could be application specific.
And then we come to another issue: what if your setup doesn't have
two LCD controller blocks but only one like on the Armada 16x.
Is it worth having a "super-device" around the parts of each system
which you want to treat separately - iow something like this if you
wish to use them together:
display {
compatible = "marvell,armada-510-display";
clocks = <&axi_clk>, <&ext_clk0>, <&lcd_pll_clk>, <&ext_clk_1>;
lcd0 {
compatible = "marvell,armada-510-lcd";
reg = <0xf182 0x1000>;
interrupts = <47>;
...
};
lcd1 {
compatible = "marvell,armada-510-lcd";
reg = <0xf181 0x1000>;
interrupts = <46>;
...
};
armada_drm clock selection
Hi, Thanks for all the clear comments and explanations - I'll address all of that in the next patch. On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux wrote: > Sure... lets add some background info first: the big problem here is the > completely different register layouts for the clock register: > > On Armada 510: > 31:30 - select the clock input from 4 possible sources: > 0 - AXI, 1 - EXT0, 2 - PLL, 3 - EXT1 > 29- loads the divider values > 27:16 - (broken) fractional divider - you never want to use this > 15:0 - integer divider > > Armada 16x: > 31:28 - select clock input from 4 possible sources using bit patterns. > 0 - AHB, 1 - PCLK, 2 - AXI, 3 - PLL > 27:16 - (broken) fractional divider > 15:0 - integer divider > > From drivers/video/mmp driver (MMP2/MMP3, aka Armada 610?): > 31- clock select > 28- disable bit > 27:16 - fractional divider > 15:12 - apparantly not used > 11:8 - DSI divider > 7:0 - integer divider MMP2 (Armada 610) and MMP3 (PXA2128, no Armada name) is even a bit more complex than that. On MMP2 the selectable clocks are written in bits 31:30 and are: 0 - AXI, 1 - LCD1, 2 - LCD2, 3 - HDMI On MMP3 the selectable clocks are written in bits 31:29 and are: 0 - AXI or LVDS (depending on bit 12) 1 - LCD1 2 - LCD2 3 - HDMI 7 - DSI When clock 0 is selected, bit 12 comes into effect for the final say on the clock selection. 0 = AXI, 1 = LVDS As you note, handling all this stuff is not trivial. And I also understand the complications that we do not want to change some clocks, if they are in use by another CRTC or are shared with other parts of the system. With your clear explanations I think I can come up with an implementation that takes all these factors into account, offering access to a great deal of the available functionality. Should not be too difficult now that we have had this discussion, and I'd be happy to do so. But before I do that, a question popped up into my mind: is this complexity really worth it? For OLPC, we only ever use LCD1 with divider 2 for our panel, which only has 1 resolution. I think we use the fast AXI clock for HDMI path, which has a separate SCLK register. For armada 510, it looks like you are quite happy with the EXT1 clock, and you mentioned that on the 16x most of the clocks are broken, which might mean there is again just one clock of preference? So, could we just specify per-CRTC clock preference in platform data, DT, or something like that? e.g. we could just specify which SCLK bits to set and clear, and which Linux-level struct clk is engaged as a result. It adds a little burden for the platform implementor, but it would avoid all of the complications that you have mentioned. Or do you have a preference for the added flexibility? Thanks Daniel
armada_drm clock selection
On 06/29/2013 05:06 PM, Daniel Drake wrote: > On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux > wrote: >> Sure... lets add some background info first: the big problem here is the >> completely different register layouts for the clock register: >> >> On Armada 510: >> 31:30 - select the clock input from 4 possible sources: >> 0 - AXI, 1 - EXT0, 2 - PLL, 3 - EXT1 >> 29- loads the divider values >> 27:16 - (broken) fractional divider - you never want to use this >> 15:0 - integer divider The reason why I called fractional divider broken is because it skips clock cycles which renders the clock useless for continuous clocking requirements. For smart panel SPI, it might work - but as soon as no board with that pops up, I suggest not to go for it. >> Armada 16x: >> 31:28 - select clock input from 4 possible sources using bit patterns. >> 0 - AHB, 1 - PCLK, 2 - AXI, 3 - PLL >> 27:16 - (broken) fractional divider >> 15:0 - integer divider >> >> From drivers/video/mmp driver (MMP2/MMP3, aka Armada 610?): >> 31- clock select >> 28- disable bit >> 27:16 - fractional divider >> 15:12 - apparantly not used >> 11:8 - DSI divider >> 7:0 - integer divider > > MMP2 (Armada 610) and MMP3 (PXA2128, no Armada name) is even a bit > more complex than that. > On MMP2 the selectable clocks are written in bits 31:30 and are: > 0 - AXI, 1 - LCD1, 2 - LCD2, 3 - HDMI > > On MMP3 the selectable clocks are written in bits 31:29 and are: > 0 - AXI or LVDS (depending on bit 12) > 1 - LCD1 > 2 - LCD2 > 3 - HDMI > 7 - DSI > > When clock 0 is selected, bit 12 comes into effect for the final say > on the clock selection. 0 = AXI, 1 = LVDS > > As you note, handling all this stuff is not trivial. And I also > understand the complications that we do not want to change some > clocks, if they are in use by another CRTC or are shared with other > parts of the system. > > With your clear explanations I think I can come up with an > implementation that takes all these factors into account, offering > access to a great deal of the available functionality. Should not be > too difficult now that we have had this discussion, and I'd be happy > to do so. But before I do that, a question popped up into my mind: is > this complexity really worth it? Depends, with per-SoC callbacks we should be safe for every possible requirement. With DT, the user always will have the option to add/remove clocks passed by clocks/clock-names matching his requirements. > For OLPC, we only ever use LCD1 with divider 2 for our panel, which > only has 1 resolution. I think we use the fast AXI clock for HDMI > path, which has a separate SCLK register. For armada 510, it looks > like you are quite happy with the EXT1 clock, and you mentioned that > on the 16x most of the clocks are broken, which might mean there is > again just one clock of preference? As soon as you are required to use EDID provided modes, you will have to provide the exact clock rate. With broken fractional divider on Dove above, you are stuck to integer division. And none of the internal frequencies give you multiple of 74.25MHz which is what you want for TV applications. So for Dove, you almost always want to use extclk, if connected to an external pll. > So, could we just specify per-CRTC clock preference in platform data, > DT, or something like that? e.g. we could just specify which SCLK bits > to set and clear, and which Linux-level struct clk is engaged as a > result. It adds a little burden for the platform implementor, but it > would avoid all of the complications that you have mentioned. Or do > you have a preference for the added flexibility? I suggest not to do any sophisticated approach to determine the "best" clock. Just set the SCLK source determined by the name of first clock passed either by DT or platform_data. This gives everybody the flexibility but keeps implementation overhead small. Sebastian
armada_drm clock selection
On 06/29/2013 08:45 PM, Russell King - ARM Linux wrote: > On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote: >> On 06/29/2013 05:06 PM, Daniel Drake wrote: >>> On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux >>>wrote: Sure... lets add some background info first: the big problem here is the completely different register layouts for the clock register: On Armada 510: 31:30 - select the clock input from 4 possible sources: 0 - AXI, 1 - EXT0, 2 - PLL, 3 - EXT1 29- loads the divider values 27:16 - (broken) fractional divider - you never want to use this 15:0 - integer divider >> >> The reason why I called fractional divider broken is because it skips >> clock cycles which renders the clock useless for continuous clocking >> requirements. For smart panel SPI, it might work - but as soon as no >> board with that pops up, I suggest not to go for it. > > I think you mean "let's ignore the fractional divider until we have a > board which uses a smart panel". Yes, thanks for clearing that out. >>> With your clear explanations I think I can come up with an >>> implementation that takes all these factors into account, offering >>> access to a great deal of the available functionality. Should not be >>> too difficult now that we have had this discussion, and I'd be happy >>> to do so. But before I do that, a question popped up into my mind: is >>> this complexity really worth it? >> >> Depends, with per-SoC callbacks we should be safe for every possible >> requirement. With DT, the user always will have the option to add/remove >> clocks passed by clocks/clock-names matching his requirements. > > That, I think, is why clock names have to be mandatory for this driver, > so we know what each DT clock specified actually is. We can't really > go and just specify one or two clocks when they may just be the external > clocks and have no way for the driver to know that. True. We should define a set of valid names per SoC and determine the required SCLK setting by that name. >>> For OLPC, we only ever use LCD1 with divider 2 for our panel, which >>> only has 1 resolution. I think we use the fast AXI clock for HDMI >>> path, which has a separate SCLK register. For armada 510, it looks >>> like you are quite happy with the EXT1 clock, and you mentioned that >>> on the 16x most of the clocks are broken, which might mean there is >>> again just one clock of preference? >> >> As soon as you are required to use EDID provided modes, you will have >> to provide the exact clock rate. With broken fractional divider on Dove >> above, you are stuck to integer division. And none of the internal >> frequencies give you multiple of 74.25MHz which is what you want for TV >> applications. So for Dove, you almost always want to use extclk, if >> connected to an external pll. > > Ahem. There is no such thing as an "exact clock rate". Even the world's > most accurate clock (caesium fountain) is only accurate to 1 part in 10^14! > (I have in the past worked in an equipment calibration laboratory with > their own Rubidium standard synchronized to a remote Caesium fountain > standard at the UK NPL, so you'll excuse me for being a pedant when it > comes to that!) > > All that's required here is a clock rate which is "good enough". Getting > it accurate to 4 significant digits is likely to be "good enough". Being an engineer, "exact" and "good enough" are synonymes for me ;) > The problem here is that the internal clocks are be 2GHz divided by an > integer divider. The closest to 74.25MHz from the Dove's internal clocks > is with a divider of 27, which gives you 74.07MHz, which is off by about > 2.4% - far from "good enough", especially when you consider the video/ > audio sync issues that would cause (you'd need about 1 additional audio > sample per 50). For video only and the monitor it should be sufficient but you are right, for audio and video it is not "good enough". >>> So, could we just specify per-CRTC clock preference in platform data, >>> DT, or something like that? e.g. we could just specify which SCLK bits >>> to set and clear, and which Linux-level struct clk is engaged as a >>> result. It adds a little burden for the platform implementor, but it >>> would avoid all of the complications that you have mentioned. Or do >>> you have a preference for the added flexibility? >> >> I suggest not to do any sophisticated approach to determine the "best" >> clock. Just set the SCLK source determined by the name of first clock >> passed either by DT or platform_data. This gives everybody the >> flexibility but keeps implementation overhead small. > > The problem this gives is we need to know what SCLK setting to use, > and I don't think specifying raw register values in DT is a particularly > good solution to that. I think it is never good style to have raw register values in DT. But different compatible strings for different SoCs plus clock na
armada_drm clock selection
On Sat, Jun 29, 2013 at 1:26 PM, Russell King - ARM Linux wrote: > So, I'd suggest that an initial approach would be something along the > lines of: > - if there is an external clock, can it generate the desired rate? > if yes, use it. > - otherwise, get the clock rate from the internal clocks and calculate > the appropriate divider. Use which ever one gives you the best > approximation that's better than (eg) 1%. If not, fail the mode set. This sounds sane to me. According to your earlier mail, armada 510 is the only current target platform that has external clocks. For the fallback on internal clocks, we would not try to change the rate of any of them, we would just look at how close they can bring us to what is needed, as you describe. If any clocks are broken or useless on a specific platform, then they can be excluded from the DT or platform data. So this is really not far off from the ideas from Sebastian and me where we would simply pass in the information about the "interesting" clocks and be done with it. I agree that we need the DT have a way of not only providing the clock, but also indicating which clock in the SCLK register it refers to, and I also think the way to do that is by having a fixed, documented clock naming scheme. So that should not be a problem. I'll avoid putting register values in the DT. I think that resolves all the open questions that I had, so I will work on this early next week. > This now brings me on to another important subject with DT vs DRM. > The way DRM is setup, it expects all resources for a particular > implementation to be known at 'drm_device' creation time. You can't > "hot-plug" additional parts of the "drm system" together. What this > means is that at driver load time (to use DRM terms) all parts must > be known. Its unfortunate that we can't hotplug the DRM bits, but at least that is no longer an open question. The super-device approach sounds sane and would seem to reflect on other parts of the DT that I have worked with. It seems reasonable to take the viewpoint that the LCD is a child connected to the display controller parent, which is what the DT layout suggests. I wonder what other DRM drivers do DT-wise? Maybe I will look into that after we've progressed with the clocks. Daniel
[PATCH RFC v4 0/3] Armada DRM driver
Quite a number of things has changed since the last revision in the core code - notably the move to use drm_plane for overlay, and the limited and restricted use of dma_buf so that gem objects can be passed to the GALCORE code and libbmm contiguous video frames can be imported into DRM. As I thought, this does require quite a number of new system calls, but the case which I care more about (vlc) doesn't pass rendered frames directly to the X server by physical address, it's not something I'm particularly concerned about - for vlc and the "normal" Xv protocol we can cache four DRM gem objects with their framebuffers pre-prepared meaning we just copy the frame and call the DRM set_plane function. What the loss of the create_phys() interface does mean is that the modified gstreamer gstbmmxvimagesink plugin will not work; it will need to be updated. I do *not* intend to support the hacky bidirectional Xv SHM hack which Marvell came up with there! I've left out the TDA998x changes and the final patch which depends on those changes which add the HDMI output for the cubox, so this series will be lacking the final parts of connector support. It is probable that the patch from the previous series can be trivially applied to this (or easily adapted if not.) Other changes: - the crtc exports a few attributes now for setting the colour transform mode. (CCIR601/709 to Computer vs "Studio" RGB). An automatic mode for these settings provided depending on selected resolution. - overlay has working brightness/contrast/saturation settings, but not hue - not worked that bit out yet. - hardware ARGB cursor support only in this version. - backend ops are now called variants, because the structure started to contain other stuff other than just function pointers. Armada510 backend moved to a separate file. - features requiring the SPU_ADV_REG (only present on Armada 510) can be disabled by the variant structure - such as interlace and ARGB cursor. - use of page_alloc() reduced down to 8K, enough to store the hardware cursor. This is all that that allocation was really used for anyway. - now uses a common kfifo queue to free used framebuffers at the appropriate time, both from the crtc code and the drm_plane code, rather than having this logic in several places. kfifo is a weird API and there's a note in the driver about that. - framebuffers now carry their configuration with them, to save having the pixel format decode scattered in several places in the driver. - power down FIFOs and RAMs not being used, and keep them powered down where possible. - minimum framebuffer size added, moved out from the X server driver. - maximum horizontal resolution dropped to 1920 to avoid a potential problem with V scaling (the RAM is apparantly 1920 pixels by 3 lines.) - protection preventing various gem objects being used in unexpected ways added - eg, you can't create a framebuffer from a cursor gem object or an imported object which is non-contiguous. - full range of colorkey modes for video supported (hey, it's just drm plane properties!) - loads of smaller cleanups, and a number of checkpatch fixes. Things left to do, in no particular order: - Creation of planar YUV formatted framebuffers - I suspect the planar YUV formats are not supported for graphic framebuffers even though Marvell document the register settings. (Where do you program the base addresses of the U and V planes?) Not a high priority as Vmeta produces UYVY encoded frames and it's more efficient to keep the native format. - Gamma support if anyone cares. Again, not high priority. - Resolution of the clocking conundrum. - Resolution of the DT specification conundrum (super-device?) - Specification of DRM connectors (DT but how?), their configuration, what they're connected to and what fixed format(s) they support. - CMA or no CMA - I've added a comment pointing out additional concerns about how to get the physical address from CMA. I think for most platforms this driver will be used on, the device address and physical address will be the same, but _conceptually_ they have never been the same in the kernel. - DCON support... I have no use for this, and the information in my documentation is pretty damned poor, so much so that I'm reluctant to try prodding around with it, especially as some of it is self-contradictory. Anyone who really cares about this can look at the issues there. Stuff omitted: - the DRM refcounting bug fix which breaks the i915 driver (but without it, booting with this driver results in a leaked refcount on the framebuffer thanks what I consider to be a bug in the DRM crtc code.) So don't boot this without something reporting itself as being connected with a valid mode.
[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver
This patch adds support for the pair of LCD controllers on the Marvell Armada 510 SoCs. This driver supports: - multiple contiguous scanout buffers for video and graphics - shm backed cacheable buffer objects for X pixmaps for Vivante GPU acceleration - dual lcd0 and lcd1 crt operation - video overlay on each LCD crt - page flipping of the main scanout buffers Included in this commit is the core driver with no output support; output support is platform and encoder driver dependent. Signed-off-by: Russell King --- drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile|1 + drivers/gpu/drm/armada/Kconfig | 15 + drivers/gpu/drm/armada/Makefile |7 + drivers/gpu/drm/armada/armada_510.c | 86 +++ drivers/gpu/drm/armada/armada_crtc.c| 861 +++ drivers/gpu/drm/armada/armada_crtc.h| 74 +++ drivers/gpu/drm/armada/armada_debugfs.c | 187 +++ drivers/gpu/drm/armada/armada_drm.h | 112 drivers/gpu/drm/armada/armada_drv.c | 381 ++ drivers/gpu/drm/armada/armada_fb.c | 155 ++ drivers/gpu/drm/armada/armada_fb.h | 24 + drivers/gpu/drm/armada/armada_fbdev.c | 206 drivers/gpu/drm/armada/armada_gem.c | 541 +++ drivers/gpu/drm/armada/armada_gem.h | 48 ++ drivers/gpu/drm/armada/armada_hw.h | 316 +++ drivers/gpu/drm/armada/armada_ioctl.h | 45 ++ drivers/gpu/drm/armada/armada_ioctlP.h | 18 + drivers/gpu/drm/armada/armada_output.c | 159 ++ drivers/gpu/drm/armada/armada_output.h | 39 ++ drivers/gpu/drm/armada/armada_overlay.c | 478 + drivers/gpu/drm/armada/armada_slave.c | 139 + drivers/gpu/drm/armada/armada_slave.h | 26 + drivers/gpu/drm/armada/drm_helper.h | 31 ++ 24 files changed, 3951 insertions(+), 0 deletions(-) create mode 100644 drivers/gpu/drm/armada/Kconfig create mode 100644 drivers/gpu/drm/armada/Makefile create mode 100644 drivers/gpu/drm/armada/armada_510.c create mode 100644 drivers/gpu/drm/armada/armada_crtc.c create mode 100644 drivers/gpu/drm/armada/armada_crtc.h create mode 100644 drivers/gpu/drm/armada/armada_debugfs.c create mode 100644 drivers/gpu/drm/armada/armada_drm.h create mode 100644 drivers/gpu/drm/armada/armada_drv.c create mode 100644 drivers/gpu/drm/armada/armada_fb.c create mode 100644 drivers/gpu/drm/armada/armada_fb.h create mode 100644 drivers/gpu/drm/armada/armada_fbdev.c create mode 100644 drivers/gpu/drm/armada/armada_gem.c create mode 100644 drivers/gpu/drm/armada/armada_gem.h create mode 100644 drivers/gpu/drm/armada/armada_hw.h create mode 100644 drivers/gpu/drm/armada/armada_ioctl.h create mode 100644 drivers/gpu/drm/armada/armada_ioctlP.h create mode 100644 drivers/gpu/drm/armada/armada_output.c create mode 100644 drivers/gpu/drm/armada/armada_output.h create mode 100644 drivers/gpu/drm/armada/armada_overlay.c create mode 100644 drivers/gpu/drm/armada/armada_slave.c create mode 100644 drivers/gpu/drm/armada/armada_slave.h create mode 100644 drivers/gpu/drm/armada/drm_helper.h diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 1e82882..ae8a57f 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -213,6 +213,8 @@ source "drivers/gpu/drm/mgag200/Kconfig" source "drivers/gpu/drm/cirrus/Kconfig" +source "drivers/gpu/drm/armada/Kconfig" + source "drivers/gpu/drm/shmobile/Kconfig" source "drivers/gpu/drm/tegra/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 0d59b24..b458168 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -48,6 +48,7 @@ obj-$(CONFIG_DRM_EXYNOS) +=exynos/ obj-$(CONFIG_DRM_GMA500) += gma500/ obj-$(CONFIG_DRM_UDL) += udl/ obj-$(CONFIG_DRM_AST) += ast/ +obj-$(CONFIG_DRM_ARMADA) += armada/ obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/ obj-$(CONFIG_DRM_TEGRA) += tegra/ obj-$(CONFIG_DRM_OMAP) += omapdrm/ diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig new file mode 100644 index 000..c7a0a94 --- /dev/null +++ b/drivers/gpu/drm/armada/Kconfig @@ -0,0 +1,15 @@ +config DRM_ARMADA + tristate "DRM support for Marvell Armada SoCs" + depends on DRM && HAVE_CLK + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + select DRM_KMS_HELPER + help + Support the "LCD" controllers found on the Marvell Armada 510 + devices. There are two controllers on the device, each controller + supports graphics and video overlays. + + This driver provides no built-in acceleration; acceleration is + performed by other IP found on the SoC. This driver provides + kernel mode setting and buffer management to userspace. diff --git a/drivers/gpu/drm/armada/Makefile b/drivers/gpu/drm/armada/Makefile new file mode 100644 index 000..d6f43e0 --- /dev/null +++ b/drivers/gpu/drm/ar
[PATCH RFC 2/3] DRM: Armada: Add support for ARGB 32x64 or 64x32 hardware cursors
This patch adds ARGB hardware cursor support to the DRM driver for the
Marvell Armada SoCs. ARGB cursors are supported at either 32x64 or
64x32 resolutions.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_510.c |1 +
drivers/gpu/drm/armada/armada_crtc.c | 244 +-
drivers/gpu/drm/armada/armada_crtc.h |9 ++
drivers/gpu/drm/armada/armada_drm.h |1 +
drivers/gpu/drm/armada/armada_hw.h |6 +-
5 files changed, 255 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_510.c
b/drivers/gpu/drm/armada/armada_510.c
index a016888..59948ef 100644
--- a/drivers/gpu/drm/armada/armada_510.c
+++ b/drivers/gpu/drm/armada/armada_510.c
@@ -80,6 +80,7 @@ static int armada510_crtc_compute_clock(struct armada_crtc
*dcrtc,
const struct armada_variant armada510_ops = {
.has_spu_adv_reg = true,
+ .spu_adv_reg = ADV_HWC32ENABLE | ADV_HWC32ARGB | ADV_HWC32BLEND,
.init = armada510_init,
.crtc_init = armada510_crtc_init,
.crtc_compute_clock = armada510_crtc_compute_clock,
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index f489157..7df1101 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -381,8 +381,21 @@ void armada_drm_crtc_irq(struct armada_crtc *dcrtc, u32
stat)
val = readl_relaxed(base + LCD_SPU_ADV_REG);
val &= ~(ADV_VSYNC_L_OFF | ADV_VSYNC_H_OFF | ADV_VSYNCOFFEN);
val |= dcrtc->v[i].spu_adv_reg;
- writel_relaxed(val, dcrtc->base + LCD_SPU_ADV_REG);
+ writel_relaxed(val, base + LCD_SPU_ADV_REG);
}
+
+ if (stat & DUMB_FRAMEDONE && dcrtc->cursor_update) {
+ writel_relaxed(dcrtc->cursor_hw_pos,
+ base + LCD_SPU_HWC_OVSA_HPXL_VLN);
+ writel_relaxed(dcrtc->cursor_hw_sz,
+ base + LCD_SPU_HWC_HPXL_VLN);
+ armada_updatel(CFG_HWC_ENA,
+ CFG_HWC_ENA | CFG_HWC_1BITMOD | CFG_HWC_1BITENA,
+ base + LCD_SPU_DMA_CTRL0);
+ dcrtc->cursor_update = false;
+ armada_drm_crtc_disable_irq(dcrtc, DUMB_FRAMEDONE_ENA);
+ }
+
spin_unlock(&dcrtc->irq_lock);
if (stat & GRA_FRAME_IRQ) {
@@ -522,7 +535,8 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
adj->crtc_htotal;
dcrtc->v[1].spu_v_porch = tm << 16 | bm;
val = adj->crtc_hsync_start;
- dcrtc->v[1].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN;
+ dcrtc->v[1].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN |
+ priv->variant->spu_adv_reg;
if (interlaced) {
/* Odd interlaced frame */
@@ -530,7 +544,8 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
(1 << 16);
dcrtc->v[0].spu_v_porch = dcrtc->v[1].spu_v_porch + 1;
val = adj->crtc_hsync_start - adj->crtc_htotal / 2;
- dcrtc->v[0].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN;
+ dcrtc->v[0].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN |
+ priv->variant->spu_adv_reg;
} else {
dcrtc->v[0] = dcrtc->v[1];
}
@@ -545,10 +560,11 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
armada_reg_queue_set(regs, i, dcrtc->v[0].spu_v_h_total,
LCD_SPUT_V_H_TOTAL);
- if (priv->variant->has_spu_adv_reg)
+ if (priv->variant->has_spu_adv_reg) {
armada_reg_queue_mod(regs, i, dcrtc->v[0].spu_adv_reg,
ADV_VSYNC_L_OFF | ADV_VSYNC_H_OFF |
ADV_VSYNCOFFEN, LCD_SPU_ADV_REG);
+ }
val = CFG_GRA_ENA | CFG_GRA_HSMOOTH;
val |= CFG_GRA_FMT(drm_fb_to_armada_fb(dcrtc->crtc.fb)->fmt);
@@ -640,11 +656,229 @@ static const struct drm_crtc_helper_funcs
armada_crtc_helper_funcs = {
.disable= armada_drm_crtc_disable,
};
+static void armada_load_cursor_argb(void __iomem *base, uint32_t *pix,
+ unsigned stride, unsigned width, unsigned height)
+{
+ uint32_t addr;
+ unsigned y;
+
+ addr = SRAM_HWC32_RAM1;
+ for (y = 0; y < height; y++) {
+ uint32_t *p = &pix[y * stride];
+ unsigned x;
+
+ for (x = 0; x < width; x++, p++) {
+ uint32_t val = *p;
+
+ val = (val & 0xff00ff00) |
+ (val & 0x00ff) << 16 |
+ (val & 0x00ff) >> 16;
+
+ writel_relaxed(val,
+ base + LCD_SPU_SRAM_WRDAT);
+ writel_relaxed(addr | SRAM_WRITE,
+ base + LCD_SP
[PATCH RFC 3/3] DRM: Armada: support for dma_buf import into gem
Support importing certain dma_bufs back into gem - notably those which
are either contiguous or are our own exports which do not use
dma_map_sg().
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_drv.c |4 +-
drivers/gpu/drm/armada/armada_fb.c |6 +++
drivers/gpu/drm/armada/armada_gem.c | 81 ++-
drivers/gpu/drm/armada/armada_gem.h |4 ++
4 files changed, 92 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index e0a08e9..268ea28 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -311,9 +311,9 @@ static struct drm_driver armada_drm_driver = {
.gem_init_object= NULL,
.gem_free_object= armada_gem_free_object,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = NULL,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = armada_gem_prime_export,
- .gem_prime_import = NULL,
+ .gem_prime_import = armada_gem_prime_import,
.dumb_create= armada_gem_dumb_create,
.dumb_map_offset= armada_gem_dumb_map_offset,
.dumb_destroy = armada_gem_dumb_destroy,
diff --git a/drivers/gpu/drm/armada/armada_fb.c
b/drivers/gpu/drm/armada/armada_fb.c
index 5154f04..28965e3 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -120,6 +120,12 @@ static struct drm_framebuffer *armada_fb_create(struct
drm_device *dev,
return ERR_PTR(-ENOENT);
}
+ if (obj->obj.import_attach && !obj->sgt) {
+ ret = armada_gem_map_import(obj);
+ if (ret)
+ goto unref;
+ }
+
/* Framebuffer objects must have a valid device address for scanout */
if (obj->dev_addr == DMA_ERROR_CODE) {
ret = -EINVAL;
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
index d09fa14..ad517ce 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -70,6 +70,12 @@ void armada_gem_free_object(struct drm_gem_object *obj)
iounmap(dobj->addr);
}
+ if (dobj->obj.import_attach) {
+ /* We only ever display imported data */
+ dma_buf_unmap_attachment(dobj->obj.import_attach, dobj->sgt,
+DMA_TO_DEVICE);
+ drm_prime_gem_destroy(&dobj->obj, NULL);
+ }
drm_gem_object_release(&dobj->obj);
@@ -270,6 +276,12 @@ int armada_gem_dumb_map_offset(struct drm_file *file,
struct drm_device *dev,
goto err_unlock;
}
+ /* Don't allow imported objects to be mapped */
+ if (obj->obj.import_attach) {
+ ret = -EINVAL;
+ goto err_unlock;
+ }
+
if (!obj->obj.map_list.map)
ret = drm_gem_create_mmap_offset(&obj->obj);
@@ -537,5 +549,72 @@ armada_gem_prime_export(struct drm_device *dev, struct
drm_gem_object *obj,
int flags)
{
return dma_buf_export(obj, &armada_gem_prime_dmabuf_ops, obj->size,
- flags);
+ O_RDWR);
+}
+
+struct drm_gem_object *
+armada_gem_prime_import(struct drm_device *dev, struct dma_buf *buf)
+{
+ struct dma_buf_attachment *attach;
+ struct armada_gem_object *dobj;
+
+ if (buf->ops == &armada_gem_prime_dmabuf_ops) {
+ struct drm_gem_object *obj = buf->priv;
+ if (obj->dev == dev) {
+ /*
+* Importing our own dmabuf(s) increases the
+* refcount on the gem object itself.
+*/
+ drm_gem_object_reference(obj);
+ dma_buf_put(buf);
+ return obj;
+ }
+ }
+
+ attach = dma_buf_attach(buf, dev->dev);
+ if (IS_ERR(attach))
+ return ERR_CAST(attach);
+
+ dobj = armada_gem_alloc_private_object(dev, buf->size);
+ if (!dobj) {
+ dma_buf_detach(buf, attach);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ dobj->obj.import_attach = attach;
+
+ /*
+* Don't call dma_buf_map_attachment() here - it maps the
+* scatterlist immediately for DMA, and this is not always
+* an appropriate thing to do.
+*/
+ return &dobj->obj;
+}
+
+int armada_gem_map_import(struct armada_gem_object *dobj)
+{
+ int ret;
+
+ dobj->sgt = dma_buf_map_attachment(dobj->obj.import_attach,
+ DMA_TO_DEVICE);
+ if (!dobj->sgt) {
+ DRM_ERROR("dma_buf_map_attachment() returned NULL\n");
+ return -EINVAL;
+ }
+ if (IS_ERR(dobj->sgt)) {
Linux 3.10-rc7
On Sat, Jun 29, 2013 at 4:52 PM, Sergey Meirovich wrote: > > There was overheating issue, that caused forced power off in the > middle of the first compile. Ok, then the thing is easily explained by simply the filesystem being shut down in an incomplete state. Sounds like the mkregtable binary had been created but not written out, and the kernel (or rather, shell) considers an empty executable to the same as "true", so after the machine came back, that counts as a "successful" binary, it just obviously doesn't write anything to stdout, which in turn then explains the empty r200_reg_safe.h file. So basically it boils down to: if the machine shuts down in the middle of a build, without "make" having time to clean up partially built files etc, you can get into strange inconsistent build trees and you might want to do a "git clean -dqfx" to get rid of everything generated. But in your case it was probably just that one file. Might be a good idea to do a clean rebuild anyway. (Side note: I've seen 'ccache' have odd stale caches too after unclean shutdowns, and then it's not sufficient to clean the build tree, you need to do "ccache -C" too). Linus
