[PATCH 1/2] drm/edid: Use ARRAY_SIZE in drm_add_modes_noedid
Spotted while reading code for random reasons. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_edid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 4a403eb90ded..4780b1924bef 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -3810,7 +3810,7 @@ int drm_add_modes_noedid(struct drm_connector *connector, struct drm_display_mode *mode; struct drm_device *dev = connector->dev; - count = sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode); + count = ARRAY_SIZE(drm_dmt_modes); if (hdisplay < 0) hdisplay = 0; if (vdisplay < 0) -- 2.5.0
[PATCH 1/9] drm: bridge/dw_hdmi-ahb-audio: add audio driver
On Mon, Aug 10, 2015 at 12:05:07PM +0200, Takashi Iwai wrote:
> On Sat, 08 Aug 2015 18:10:06 +0200,
> Russell King wrote:
> > +static irqreturn_t snd_dw_hdmi_irq(int irq, void *data)
> > +{
> > + struct snd_dw_hdmi *dw = data;
> > + struct snd_pcm_substream *substream;
> > + unsigned stat;
> > +
> > + stat = readb_relaxed(dw->data.base + HDMI_IH_AHBDMAAUD_STAT0);
> > + if (!stat)
> > + return IRQ_NONE;
> > +
> > + writeb_relaxed(stat, dw->data.base + HDMI_IH_AHBDMAAUD_STAT0);
> > +
> > + substream = dw->substream;
> > + if (stat & HDMI_IH_AHBDMAAUD_STAT0_DONE && substream) {
> > + snd_pcm_period_elapsed(substream);
> > + if (dw->substream)
> > + dw_hdmi_start_dma(dw);
> > + }
>
> Don't we need locking?
Possibly.
> In theory, the trigger can be issued while the irq is being handled.
Well, we can't have a lock around the whole of the above, because that
results in deadlock (as snd_pcm_period_elapsed() can end up calling into
the trigger method.) I'm not happy to throw a spinlock around this
because of the in-built format conversion (something else I'm really not
happy about - which has to exist here because alsalib is soo painful
to add custom sample reformatting to - such modules have to be built
as part of alsalib itself rather than an add-on module.)
> > +static int dw_hdmi_trigger(struct snd_pcm_substream *substream, int cmd)
> > +{
> > + struct snd_dw_hdmi *dw = substream->private_data;
> > + int ret = 0;
> > +
> > + switch (cmd) {
> > + case SNDRV_PCM_TRIGGER_START:
> > + dw->buf_offset = 0;
> > + dw->substream = substream;
> > + dw_hdmi_start_dma(dw);
> > + dw_hdmi_audio_enable(dw->data.hdmi);
> > + substream->runtime->delay = substream->runtime->period_size;
> > + break;
> > +
> > + case SNDRV_PCM_TRIGGER_STOP:
> > + dw_hdmi_stop_dma(dw);
> > + dw_hdmi_audio_disable(dw->data.hdmi);
> > + break;
> > +
> > + default:
> > + ret = -EINVAL;
> > + break;
>
> SNDRV_PCM_TRIGGER_SUSPEND may be passed at suspend, too.
I think rather than adding code which would be difficult for me to test,
I'd instead remove the suspend/resume callbacks, or at least disable them
until someone can test that feature, or is willing to implement it.
> > +static snd_pcm_uframes_t dw_hdmi_pointer(struct snd_pcm_substream
> > *substream)
> > +{
> > + struct snd_pcm_runtime *runtime = substream->runtime;
> > + struct snd_dw_hdmi *dw = substream->private_data;
> > +
> > + return bytes_to_frames(runtime, dw->buf_offset);
>
> So, this returns the offset that has been reformatted. Does the
> hardware support any better position reporting? We may give the delay
> from the driver if possible.
Basically, no. Reading a 32-bit DMA position as separate bytes while
DMA is active is racy.
This is the best we can do, and the way we report the position has been
arrived at after what's getting on for two years of testing with
pulseaudio, vlc direct access & spdif pass-through, aplay, etc:
Author: Russell King
Date: Thu Nov 7 16:01:45 2013 +
drm: bridge/dw_hdmi-ahb-audio: add audio driver
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
[Bug 91588] [LLVM] (bisected) Unigine Valley: High + AA = incorrect rendering
https://bugs.freedesktop.org/show_bug.cgi?id=91588 --- Comment #5 from smoki --- Created attachment 117611 --> https://bugs.freedesktop.org/attachment.cgi?id=117611=edit stderrs.7z 7z compressed both -- 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/20150810/7aaee53f/attachment.html>
[Intel-gfx] [PATCH mesa v3] i965/gen8+: bo in state base address must be in 32-bit address range
Hi,
Thanks for the comments,
On 8/7/2015 11:46 PM, Kristian Høgsberg wrote:
> On Fri, Aug 7, 2015 at 2:45 AM, Michel Thierry
> wrote:
>> Gen8+ supports 48-bit virtual addresses, but some objects must always be
>> allocated inside the 32-bit address range.
>>
>> In specific, any resource used with flat/heapless (0x-0xf000)
>> General State Heap or Intruction State Heap must be in a 32-bit range
>> (GSH / ISH), because the General State Offset and Instruction State Offset
>> are limited to 32-bits.
>
> This doesn't look right. From the workaround text, it doesn't sound
> like this is a HW problem, it only affects GMM. In mesa, we don't use
> "heapless" (which I assume means setting the base to 0 and max range)
It is a hw problem, specifically in the state base address command.
General State Base Address and Instruction Base Address shouldn't be > 4GB.
> for instructions, dynamic state or surface state. Surface state and
> dynamic state is always in our batch bo which is limited to 8k.
> Provided STATE_BASE_ADDRESS works correctly in the HW, the batch bo
> can be places anywhere in the aperture. Offsets to dynamic or surface
> state is relative to the beginning of the batch bo and will always be
> less than 4g. Instructions are in their own bo (brw->cache.bo), but
> again, we point instruction state base to it and all our shader stage
> setup code references the instructions relative to the beginning of
> the instruction bo.
I've seen the issue when the driver allocates mapped objects from bottom
to top and the other bo's from top to bottom (gpu hangs). So I say this
wa is needed.
-Michel
>
> Kristian
>
>> Use drm_intel_bo_emit_reloc_48bit when the 4GB limit is not necessary, and
>> the bo can be in the full address space.
>>
>> This commit introduces a dependency of libdrm 2.4.63, which introduces the
>> drm_intel_bo_emit_reloc_48bit function.
>>
>> v2: s/48baddress/48b_address/,
>> Only use in OUT_RELOC64 cases, OUT_RELOC implies a 32-bit address offset
>> is needed (Ben)
>> v3: Added OUT_RELOC64_INSIDE_4G, so it stands out when a 64-bit relocation
>> needs the 32-bit workaround (Chris)
>>
>> References:
>> http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
>> Cc: Ben Widawsky
>> Cc: Chris Wilson
>> Signed-off-by: Michel Thierry
>> ---
>> configure.ac | 2 +-
>> src/mesa/drivers/dri/i965/gen8_misc_state.c | 19 +++
>> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 20
>> src/mesa/drivers/dri/i965/intel_batchbuffer.h | 10 --
>> 4 files changed, 36 insertions(+), 15 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index af61aa2..c92ca44 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -68,7 +68,7 @@ AC_SUBST([OSMESA_VERSION])
>> dnl Versions for external dependencies
>> LIBDRM_REQUIRED=2.4.38
>> LIBDRM_RADEON_REQUIRED=2.4.56
>> -LIBDRM_INTEL_REQUIRED=2.4.60
>> +LIBDRM_INTEL_REQUIRED=2.4.63
>> LIBDRM_NVVIEUX_REQUIRED=2.4.33
>> LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
>> LIBDRM_FREEDRENO_REQUIRED=2.4.57
>> diff --git a/src/mesa/drivers/dri/i965/gen8_misc_state.c
>> b/src/mesa/drivers/dri/i965/gen8_misc_state.c
>> index b20038e..73eba06 100644
>> --- a/src/mesa/drivers/dri/i965/gen8_misc_state.c
>> +++ b/src/mesa/drivers/dri/i965/gen8_misc_state.c
>> @@ -28,6 +28,10 @@
>>
>> /**
>>* Define the base addresses which some state is referenced from.
>> + *
>> + * Use OUT_RELOC64_INSIDE_4G instead of OUT_RELOC64, the General State
>> + * Offset and Instruction State Offset are limited to 32-bits by hardware,
>> + * and must be located in the first 4GBs (32-bit offset).
>>*/
>> void gen8_upload_state_base_address(struct brw_context *brw)
>> {
>> @@ -41,19 +45,18 @@ void gen8_upload_state_base_address(struct brw_context
>> *brw)
>> OUT_BATCH(0);
>> OUT_BATCH(mocs_wb << 16);
>> /* Surface state base address: */
>> - OUT_RELOC64(brw->batch.bo, I915_GEM_DOMAIN_SAMPLER, 0,
>> - mocs_wb << 4 | 1);
>> + OUT_RELOC64_INSIDE_4G(brw->batch.bo, I915_GEM_DOMAIN_SAMPLER, 0,
>> + mocs_wb << 4 | 1);
>> /* Dynamic state base address: */
>> - OUT_RELOC64(brw->batch.bo,
>> - I915_GEM_DOMAIN_RENDER | I915_GEM_DOMAIN_INSTRUCTION, 0,
>> - mocs_wb << 4 | 1);
>> + OUT_RELOC64_INSIDE_4G(brw->batch.bo,
>> + I915_GEM_DOMAIN_RENDER |
>> I915_GEM_DOMAIN_INSTRUCTION, 0,
>> + mocs_wb << 4 | 1);
>> /* Indirect object base address: MEDIA_OBJECT data */
>> OUT_BATCH(mocs_wb << 4 | 1);
>> OUT_BATCH(0);
>> /* Instruction base address: shader kernels (incl. SIP) */
>> - OUT_RELOC64(brw->cache.bo, I915_GEM_DOMAIN_INSTRUCTION, 0,
>> - mocs_wb << 4 | 1);
>> -
>> + OUT_RELOC64_INSIDE_4G(brw->cache.bo, I915_GEM_DOMAIN_INSTRUCTION, 0,
>> + mocs_wb << 4
[Bug 91588] [LLVM] (bisected) Unigine Valley: High + AA = incorrect rendering
https://bugs.freedesktop.org/show_bug.cgi?id=91588 --- Comment #4 from Michel Dänzer --- Please generate a unified diff with "diff -u" or even better just attach both versions. -- 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/20150810/a32fab5f/attachment-0001.html>
[Bug 91595] RV410 white screen after resume
https://bugs.freedesktop.org/show_bug.cgi?id=91595 --- Comment #3 from José Jorge --- Created attachment 117606 --> https://bugs.freedesktop.org/attachment.cgi?id=117606=edit radeontool registers ok after hibernate and resume -- 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/20150810/c221fe7e/attachment.html>
[Bug 91595] RV410 white screen after resume
https://bugs.freedesktop.org/show_bug.cgi?id=91595 --- Comment #2 from José Jorge --- Created attachment 117605 --> https://bugs.freedesktop.org/attachment.cgi?id=117605=edit radeontool registers when screen is white -- 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/20150810/6809aba4/attachment.html>
[Bug 91595] RV410 white screen after resume
https://bugs.freedesktop.org/show_bug.cgi?id=91595 --- Comment #1 from José Jorge --- Created attachment 117604 --> https://bugs.freedesktop.org/attachment.cgi?id=117604=edit radeontool registers ok Just after a simple boot -- 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/20150810/b2922ef2/attachment.html>
[Bug 91595] RV410 white screen after resume
https://bugs.freedesktop.org/show_bug.cgi?id=91595 Bug ID: 91595 Summary: RV410 white screen after resume Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: lists.jjorge at free.fr This is a Fujitsu Amilo M1437G with X700Mobile. Suspended/resumed well with UMS with a 2009 distro, but after upgrading the system to a 2015 Mageia 5 and a KMS only driver, screen is white after suspend. If then I hibernate the system through ssh, screen is ok. Looks like the sbios does something that KMS does not, is there a way to debug this? I join the reg dumps. -- 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/20150810/504e8825/attachment.html>
[Intel-gfx] [PATCH libdrm v3 1/2] intel: Add EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag
On Fri, 2015-08-07 at 12:36 +0100, Michel Thierry wrote: > Hi MichaÅ, > > Ben suggested having the set/clear in emit reloc as this is the only > place mesa cares about these wa. > > But I see your point, this will be used not only by mesa, so we > should > have something that is good for all the other projects. > > -Michel If there are no comments from anyone else then I'm fine with public API from last version. But comments about the error handling and implementation details could still be addressed. -MichaÅ
[Bug 91588] [LLVM] (bisected) Unigine Valley: High + AA = incorrect rendering
https://bugs.freedesktop.org/show_bug.cgi?id=91588 --- Comment #3 from smoki --- Created attachment 117602 --> https://bugs.freedesktop.org/attachment.cgi?id=117602=edit good_vs_bad.diff Yeah, i attached good vs bad diff (v97 is good and v89 bad) -- 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/20150810/6fadcc35/attachment.html>
[Bug 91588] [LLVM] (bisected) Unigine Valley: High + AA = incorrect rendering
https://bugs.freedesktop.org/show_bug.cgi?id=91588 --- Comment #2 from Michel Dänzer --- You know the drill. Please provide the stderr output with R600_DEBUG=vs,gs,ps from a good and bad LLVM commit. -- 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/20150810/7a2a3959/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #113 from Alex Deucher --- (In reply to Paul Menzel from comment #112) > Could somebody please reference the corresponding commits, so it can be > checked, if they are marked to go into the stable Linux kernels? http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f28d1281b6c54cc98746ae61e44e7f540758ed4 -- 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/20150810/7d23d468/attachment.html>
