Re: WARNING in amdgpu_sync_keep_later / dma_fence_is_later should be rate limited

[Rafał Miłecki]

On 21.09.2023 21:52, Deucher, Alexander wrote:

backporting commit 187916e6ed9d ("drm/amdgpu: install stub fence into
potential unused fence pointers") to stable kernels resulted in lots of
WARNINGs on some devices. In my case I was getting 3 WARNINGs per
second (~150 lines logged every second). Commit ended up being reverted for
stable but it exposed a potential problem. My messages log size was reaching
gigabytes and was running my /tmp/ out of space.

Could someone take a look at amdgpu_sync_keep_later / dma_fence_is_later
and make sure its logging is rate limited to avoid such situations in the 
future,
please?

Revert in linux-5.15.x:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=li
nux-5.15.y&id=fae2d591f3cb31f722c7f065acf586830eab8c2a

openSUSE bug report:
https://bugzilla.opensuse.org/show_bug.cgi?id=1215523


These patches were never intended for stable.  They were picked up by Sasha's 
stable autoselect tools and automatically applied to stable kernels.


Are you saying massive WARNINGs in dma_fence_is_later() can't happen
in any other case? I understand it was an incorrect backport action but
I thought we may learn from it and still add some rate limit.

WARNING in amdgpu_sync_keep_later / dma_fence_is_later should be rate limited

[Rafał Miłecki]

Hi,

backporting commit 187916e6ed9d ("drm/amdgpu: install stub fence into
potential unused fence pointers") to stable kernels resulted in lots
of WARNINGs on some devices. In my case I was getting 3 WARNINGs per
second (~150 lines logged every second). Commit ended up being
reverted for stable but it exposed a potential problem. My messages
log size was reaching gigabytes and was running my /tmp/ out of space.

Could someone take a look at amdgpu_sync_keep_later /
dma_fence_is_later and make sure its logging is rate limited to avoid
such situations in the future, please?

Revert in linux-5.15.x:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.15.y&id=fae2d591f3cb31f722c7f065acf586830eab8c2a

openSUSE bug report:
https://bugzilla.opensuse.org/show_bug.cgi?id=1215523

-- 
Rafał

Re: [PATCH 1/1] backlight: apple_bl_usb: Add Apple Studio Display support

[Rafał Miłecki]

On 1.07.2023 14:08, Julius Zint wrote:

The Apple Studio Display does not have any physical buttons and the only
way to get or set the brightness is by sending USB control transfers to a
HID device exposed by the display.

These control transfers take the form of a HID_(GET|SET)_REPORT request
and the payload looks like this:

 struct brightness_ctrl_message_data {
u8 unknown_1;
__le16 brightness;
u8 unkown_2[4];
 } __packed;

When compiled as a module this driver needs to be part of the early boot
environment, otherwise the generic USB HID driver will claim the device.

Signed-off-by: Julius Zint 


Few comments below.



---
  drivers/video/backlight/Kconfig|   8 +
  drivers/video/backlight/Makefile   |   1 +
  drivers/video/backlight/apple_bl_usb.c | 264 +
  3 files changed, 273 insertions(+)
  create mode 100644 drivers/video/backlight/apple_bl_usb.c

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 51387b1ef012..9383d402ebed 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -290,6 +290,14 @@ config BACKLIGHT_APPLE
  If you have an Intel-based Apple say Y to enable a driver for its
  backlight.
  
+config BACKLIGHT_APPLE_USB

+   tristate "Apple USB Backlight Driver"
+   depends on USB
+   help
+ If you have an external display from Apple that is attached via USB
+ say Y to enable a driver for its backlight. Currently it supports the
+ Apple Studio Display.
+
  config BACKLIGHT_QCOM_WLED
tristate "Qualcomm PMIC WLED Driver"
select REGMAP
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index f72e1c3c59e9..c42880655113 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_BACKLIGHT_ADP5520)   += adp5520_bl.o
  obj-$(CONFIG_BACKLIGHT_ADP8860)   += adp8860_bl.o
  obj-$(CONFIG_BACKLIGHT_ADP8870)   += adp8870_bl.o
  obj-$(CONFIG_BACKLIGHT_APPLE) += apple_bl.o
+obj-$(CONFIG_BACKLIGHT_APPLE_USB)  += apple_bl_usb.o
  obj-$(CONFIG_BACKLIGHT_AS3711)+= as3711_bl.o
  obj-$(CONFIG_BACKLIGHT_BD6107)+= bd6107.o
  obj-$(CONFIG_BACKLIGHT_CARILLO_RANCH) += cr_bllcd.o
diff --git a/drivers/video/backlight/apple_bl_usb.c 
b/drivers/video/backlight/apple_bl_usb.c
new file mode 100644
index ..b746b7822974
--- /dev/null
+++ b/drivers/video/backlight/apple_bl_usb.c
@@ -0,0 +1,264 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define APPLE_STUDIO_DISPLAY_VENDOR_ID  0x05ac
+#define APPLE_STUDIO_DISPLAY_PRODUCT_ID 0x1114
+
+#define HID_GET_REPORT 0x01
+#define HID_SET_REPORT 0x09
+
+#define HID_REPORT_TYPE_FEATURE 0x0300
+
+struct apple_bl_usb_data {
+   struct usb_interface *usb_interface;
+   struct usb_device *usb_dev;
+};
+
+struct brightness_ctrl_message_data {
+   u8 unknown_1;
+   __le16 brightness;
+   u8 unkown_2[4];


Typo



+} __packed;
+
+void init_ctrl_msg_data(struct brightness_ctrl_message_data *msg)
+{
+   memset(msg, 0, sizeof(struct brightness_ctrl_message_data));
+   msg->unknown_1 = 0x01;
+}
+
+void set_ctrl_message_brightness(struct brightness_ctrl_message_data *msg,
+u16 brightness_value)
+{
+   msg->brightness = cpu_to_le16(brightness_value + 400);
+}
+
+u16 get_ctrl_message_brightness(struct brightness_ctrl_message_data *msg)
+{
+   return le16_to_cpu(msg->brightness) - 400;
+}
+
+int apple_bl_usb_usb_get_brightness(struct usb_interface *interface,
+   struct usb_device *usb_dev,
+   int *brightness)
+{
+   int err;
+   u16 interface_nr;
+   int msg_data_size;
+   struct brightness_ctrl_message_data *msg_data;
+
+   msg_data_size = sizeof(struct brightness_ctrl_message_data);
+   msg_data = kzalloc(msg_data_size, GFP_KERNEL);


Check for NULL as kzalloc() may fail



+   memset(msg_data, 0x00, msg_data_size);
+   interface_nr = interface->cur_altsetting->desc.bInterfaceNumber;
+
+   err = usb_control_msg(usb_dev,
+ usb_rcvctrlpipe(usb_dev, 0),
+ HID_GET_REPORT,
+ USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
+ /* wValue: HID-Report Type and Report ID */
+ HID_REPORT_TYPE_FEATURE | 0x01,
+ interface_nr /* wIndex */,
+ msg_data,
+ msg_data_size,
+ HZ);
+   if (err < 0) {
+   dev_err(&interface->dev,
+   "get: usb control message err: %d\n",
+   err);


Shouldn't you kfree() and 

make dt_binding_check broken by drm & lvds-codec

[Rafał Miłecki]

Hi,

I just noticed that "make dt_binding_check" doesn't work in linux-next:

  SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
Traceback (most recent call last):
  File "/home/rmilecki/.local/bin/dt-mk-schema", line 38, in 
schemas = dtschema.process_schemas(args.schemas, core_schema=(not 
args.useronly))
  File "/home/rmilecki/.local/lib/python3.6/site-packages/dtschema/lib.py", 
line 587, in process_schemas
sch = process_schema(os.path.abspath(filename))
  File "/home/rmilecki/.local/lib/python3.6/site-packages/dtschema/lib.py", 
line 561, in process_schema
schema = load_schema(filename)
  File "/home/rmilecki/.local/lib/python3.6/site-packages/dtschema/lib.py", 
line 126, in load_schema
return do_load(os.path.join(schema_basedir, schema))
  File "/home/rmilecki/.local/lib/python3.6/site-packages/dtschema/lib.py", 
line 112, in do_load
return yaml.load(tmp)
  File "/usr/lib/python3.6/site-packages/ruamel/yaml/main.py", line 343, in load
return constructor.get_single_data()
  File "/usr/lib/python3.6/site-packages/ruamel/yaml/constructor.py", line 113, 
in get_single_data
return self.construct_document(node)
  File "/usr/lib/python3.6/site-packages/ruamel/yaml/constructor.py", line 123, 
in construct_document
for _dummy in generator:
  File "/usr/lib/python3.6/site-packages/ruamel/yaml/constructor.py", line 723, 
in construct_yaml_map
value = self.construct_mapping(node)
  File "/usr/lib/python3.6/site-packages/ruamel/yaml/constructor.py", line 440, 
in construct_mapping
return BaseConstructor.construct_mapping(self, node, deep=deep)
  File "/usr/lib/python3.6/site-packages/ruamel/yaml/constructor.py", line 257, 
in construct_mapping
if self.check_mapping_key(node, key_node, mapping, key, value):
  File "/usr/lib/python3.6/site-packages/ruamel/yaml/constructor.py", line 295, 
in check_mapping_key
raise DuplicateKeyError(*args)
ruamel.yaml.constructor.DuplicateKeyError: while constructing a mapping
  in "", line 4, column 1
found duplicate key "if" with value "{}" (original value: "{}")
  in "", line 113, column 1

It's caused by two commits:
ba3e86789eaf ("dt-bindings: display: bridge: lvds-codec: Document LVDS data mapping 
select")
d7df3948eb49 ("dt-bindings: display: bridge: lvds-codec: Document pixel data 
sampling edge select")

Both commits add "if" and "then" at YAML "root" level.

Can you take a look at that, please?

[PATCH 2/3] radeon: Fix VCE ring test for Big-Endian systems

[Rafał Miłecki]

On 8 December 2015 at 04:00, Michel Dänzer  wrote:
> On 08.12.2015 02:49, Oded Gabbay wrote:
>> On Mon, Dec 7, 2015 at 9:51 AM, Michel Dänzer  wrote:
>>> On 05.12.2015 06:09, Oded Gabbay wrote:

 @@ -765,7 +765,7 @@ int radeon_vce_ring_test(struct radeon_device *rdev, 
 struct radeon_ring *ring)
 ring->idx, r);
   return r;
   }
 - radeon_ring_write(ring, VCE_CMD_END);
 + radeon_ring_write(ring, cpu_to_le32(VCE_CMD_END));
   radeon_ring_unlock_commit(rdev, ring, false);

   for (i = 0; i < rdev->usec_timeout; i++) {

>>>
>>> A new helper function such as
>>>
>>> static inline void radeon_ring_write_le(struct radeon_ring *ring, uint32_t 
>>> v)
>>> {
>>> radeon_ring_write(ring, cpu_to_le32(v));
>>> }
>>>
>>> might be nice for this.
>>
>> IMHO, I don't think this gives any benefit.
>> You would just need to replace every:
>>
>> radeon_ring_write(ring, cpu_to_le32(SOME_DEFINE));
>>
>> with
>>
>> radeon_ring_write_le(ring, SOME_DEFINE);
>>
>> So no reduce in code size. Also, if you change it in my code, I think
>> you need to change it in the entire driver for consistency.
>>
>> What's even more important, is that when I look at the above, it seems
>> to me this change even makes the code *less* clear as you now need to
>> go into radeon_ring_write_le  to actually understand how the value is
>> written.
>
> Sprinkling cpu_to_le32 all over the place just seems a bit ugly to me,
> but I don't feel strongly about it. I.e. I'm fine with the patch as is,
> it was just a suggestion.

I agree, having cpu_to_le32 repeated over and over makes code messy,
harder to read, harder to fit 80 chars (which is already often
violated in radeon code). radeon_ring_write_le sounds self
explanatory.

-- 
Rafał

Is my Radeon HD 6970M dying? Hangs & init problems

[Rafał Miłecki]

My notebook Samsung NP700G7A-S01PL was working stable for more than 2 years.
I was using 3.11, 3.17, 3.18, 3.19 (since rc1) and many more successfully.
First hang has happened on 2015-02-08 (23:30) with 3.19-rc5 I was
using for 3 weeks.

So what I'm seeing are two possibly related problems:

1) Random hangs
I don't have to be doing anything unusual. A single display, no UVD,
just writing some code in kate. And then it randomly happens. My
screen goes all white or green vertical lines or blue vertical lines.
I can't use/access my machine, sound goes into a loop (last second).
Sometimes it happens after hours, sometimes 30 minutes, sometimes few
minutes. So far I got 5-7 hangs like this.

2) Init problems
Unfortunately rebooting does not always help. Even cold boot (removing
power & battery, keeping power button pressed for few seconds) isn't
helpful.
a) First I get UVD init errors:
*ERROR* UVD not responding, trying to reset the VCPU!!!
b) Then machine hangs after displaying "pitch is 7680"
I've tracked it to be somewhere near register_framebuffer
(see attached bad.txt)

As long as I don't use radeon (booting with "nomodeset") it works stable.

I tested my RAM with MemTest86 (one pass, took 1 hour), no errors, CPU
temperature didn't exceed 70 degrees.

This evening as the last hope I installed fglrx. It hangs my machine
as well with following messages:
[   36.472526] console [netcon0] enabled
[   36.473106] netconsole: network logging started
[   48.192215] fglrx_pci :01:00.0: irq 56 for MSI/MSI-X
[   48.192726] <6>[fglrx] Firegl kernel thread PID: 1481
[   48.192833] <6>[fglrx] Firegl kernel thread PID: 1482
[   48.192954] <6>[fglrx] Firegl kernel thread PID: 1483
[   48.193077] <6>[fglrx] IRQ 56 Enabled
[   48.240118] <6>[fglrx] Reserved FB block: Shared offset:0, size:100
[   48.240122] <6>[fglrx] Reserved FB block: Unshared offset:3fab4000, size:4000
[   48.240124] <6>[fglrx] Reserved FB block: Unshared offset:3fab8000,
size:548000
[   48.240126] <6>[fglrx] Reserved FB block: Unshared offset:7fff3000, size:d000
However if I drop fglrx.ko and just use Xorg driver fglrx_drv.so it
works stable.

Any ideas? Is GPU on my motherboard just dying? :|

-- 
Rafał
-- next part --
[   35.114273] [drm] radeon kernel modesetting enabled.
[   35.114709] [drm] initializing kernel modesetting (BARTS 0x1002:0x6720 
0x144D:0xC0AD).
[   35.114871] [drm] register mmio base: 0xF7E2
[   35.115012] [drm] register mmio size: 131072
[   35.115195] ATOM BIOS: Samsung
[   35.115465] radeon :01:00.0: VRAM: 2048M 0x - 
0x7FFF (2048M used)
[   35.115693] radeon :01:00.0: GTT: 1024M 0x8000 - 
0xBFFF
[   35.115908] [drm] Detected VRAM RAM=2048M, BAR=1024M
[   35.116043] [drm] RAM width 256bits DDR
[   35.116262] [TTM] Zone  kernel: Available graphics memory: 4079754 kiB
[   35.116406] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[   35.116542] [TTM] Initializing pool allocator
[   35.116693] [TTM] Initializing DMA pool allocator
[   35.116845] [drm] radeon: 2048M of VRAM memory ready
[   35.116987] [drm] radeon: 1024M of GTT memory ready.
[   35.117134] [drm] Loading BARTS Microcode
[   35.197992] [drm] Internal thermal controller with fan control
[   35.198758] [drm] radeon: power management initialized
[   35.206487] [drm] GART: num cpu pages 262144, num gpu pages 262144
[   35.207542] [drm] enabling PCIE gen 2 link speeds, disable with 
radeon.pcie_gen2=0
[   35.213991] [drm] PCIE GART of 1024M enabled (table at 0x00274000).
[   35.214171] radeon :01:00.0: WB enabled
[   35.214254] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x8c00 and cpu addr 0x88026ad30c00
[   35.214364] radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x8c0c and cpu addr 0x88026ad30c0c
[   35.214892] radeon :01:00.0: fence driver on ring 5 use gpu addr 
0x00072118 and cpu addr 0xc90007a32118
[   35.215003] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   35.215083] [drm] Driver supports precise vblank timestamp query.
[   35.215163] radeon :01:00.0: radeon: MSI limited to 32-bit
[   35.215281] radeon :01:00.0: radeon: using MSI.
[   35.215382] [drm] radeon: irq initialized.
[   35.232059] [drm] ring test on 0 succeeded in 1 usecs
[   35.232145] [drm] ring test on 3 succeeded in 2 usecs
[   36.423302] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, trying 
to reset the VCPU!!!
[   37.447064] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, trying 
to reset the VCPU!!!
[   38.143477] nf_conntrack: automatic helper assignment is deprecated and it 
will be removed soon. Use the iptables CT target to attach helpers instead.
[   38.470826] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, trying 
to reset the VCPU!!!
[   39.494585] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, trying 
to reset the VCPU!!!
[   40.5183

[PATCH 3/5] drm/radeon: Setup HDMI_CONTROL for hdmi deep color gcp's.

[Rafał Miłecki]

On 21 May 2014 15:51, Alex Deucher  wrote:
> On Wed, May 21, 2014 at 1:58 AM, Rafa? Mi?ecki  wrote:
>> What about using helper:
>>
>> WREG32_P(HDMI_CONTROL + offset,
>> val,
>> ~(HDMI_DEEP_COLOR_ENABLE | HDMI_DEEP_COLOR_DEPTH_MASK));
>
> We could.  I don't think it really makes much difference one way or
> the other though.  I don't really have a strong preference.

OK. It's up to you.

-- 
Rafa?

[PATCH 3/5] drm/radeon: Setup HDMI_CONTROL for hdmi deep color gcp's.

[Rafał Miłecki]

On 21 May 2014 01:17, Alex Deucher  wrote:
> +   val = RREG32(HDMI_CONTROL + offset);
> +   val &= ~HDMI_DEEP_COLOR_ENABLE;
> +   val &= ~HDMI_DEEP_COLOR_DEPTH_MASK;
> +

> +   switch (bpc) {
> (...)
> +   }
> +
> +   WREG32(HDMI_CONTROL + offset, val);

What about using helper:

WREG32_P(HDMI_CONTROL + offset,
val,
~(HDMI_DEEP_COLOR_ENABLE | HDMI_DEEP_COLOR_DEPTH_MASK));

[deathsimple/drm-next-3.16][PATCH V3 2/4] drm/radeon/hdmi: DCE3: clean ACR control

[Rafał Miłecki]

On 17 May 2014 02:14, Rafa? Mi?ecki  wrote:
> So it's the fact:
> DCE2 uses 0x74dc
> DCE2 uses 0x740c

I meant:
DCE2 uses 0x74dc
DCE3 uses 0x740c

[deathsimple/drm-next-3.16][PATCH V3 2/4] drm/radeon/hdmi: DCE3: clean ACR control

[Rafał Miłecki]

On 17 May 2014 01:34, Rafa? Mi?ecki  wrote:
> On 17 May 2014 00:00, Alex Deucher  wrote:
>> On Fri, May 16, 2014 at 5:10 AM, Rafa? Mi?ecki  wrote:
>>> +#define DCE3_HDMI0_AUDIO_CRC_CONTROL   0x74dc
>>
>> They aren't swapped in hw, the register defines were just accidentally
>> swapped in the header (probably a copy paste typo).  Just swap the
>> defines.  No need to keep the old values.
>
> Are you sure about this? I've doubts because fglrx indeed uses
> 0x74dc for DCE2
> 0x740c for DCE3
>
> Previously you wrote: "On DCE3, they should be ...".
>
> I suspect we may still need old defines to support DCE2.

I was right. I've just compiled radeon with:
acr_ctl = 0x740c;
and tested it on DCE2. Audio didn't work.

Some debugging:
# avivotool regsrange 0x740c 0x740c
740c 1100 (4352)
# avivotool regsrange 0x74dc 0x74dc
74dc  (0)

As expected, audio was fixed by exeuting:
# avivotool regset 0x74dc 0x1100

So it's the fact:
DCE2 uses 0x74dc
DCE2 uses 0x740c

So I believe my patch is OK.

-- 
Rafa?

[deathsimple/drm-next-3.16][PATCH V3 2/4] drm/radeon/hdmi: DCE3: clean ACR control

[Rafał Miłecki]

On 17 May 2014 00:00, Alex Deucher  wrote:
> On Fri, May 16, 2014 at 5:10 AM, Rafa? Mi?ecki  wrote:
>> +#define DCE3_HDMI0_AUDIO_CRC_CONTROL   0x74dc
>
> They aren't swapped in hw, the register defines were just accidentally
> swapped in the header (probably a copy paste typo).  Just swap the
> defines.  No need to keep the old values.

Are you sure about this? I've doubts because fglrx indeed uses
0x74dc for DCE2
0x740c for DCE3

Previously you wrote: "On DCE3, they should be ...".

I suspect we may still need old defines to support DCE2.

[deathsimple/drm-next-3.16][PATCH V4 1/4] drm/radeon/hdmi: use separated file for DCE 3.1/3.2 code

[Rafał Miłecki]

DCE 3.1 and 3.2 should be programmed in a different way than DCE 2 and
DCE 3. The order of setting registers and sets of registers are
different.
It's still unsure how we will handle DCE 3.1 vs. DCE 3.2, since they
have few differences as well.
For now separate DCE 2 and DCE 3 path, so we can work on it without a
risk of breaking DCE 3.1+.

This has been tested for possible regressions on DCE32 HD4550 (RV710).

Signed-off-by: Rafa? Mi?ecki 
---
V4: Add Copyright header. Alex is an author of
dce3_2_afmt_write_speaker_allocation
dce3_2_afmt_write_sad_regs
and I'm pretty much an author of
dce3_1_hdmi_setmode
---
 drivers/gpu/drm/radeon/Makefile  |   2 +-
 drivers/gpu/drm/radeon/dce3_1_afmt.c | 244 +++
 drivers/gpu/drm/radeon/r600_hdmi.c   | 149 ++---
 drivers/gpu/drm/radeon/radeon_asic.c |   2 +-
 drivers/gpu/drm/radeon/radeon_asic.h |   7 +
 5 files changed, 263 insertions(+), 141 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/dce3_1_afmt.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 0943353..dbcbfe8 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
radeon_cs.o radeon_bios.o radeon_benchmark.o r100.o r300.o r420.o \
rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \
r200.o radeon_legacy_tv.o r600_cs.o r600_blit_shaders.o \
-   radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
+   radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o dce3_1_afmt.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c 
b/drivers/gpu/drm/radeon/dce3_1_afmt.c
new file mode 100644
index 000..51800e3
--- /dev/null
+++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
@@ -0,0 +1,244 @@
+/*
+ * Copyright 2013 Advanced Micro Devices, Inc.
+ * Copyright 2014 Rafa? Mi?ecki
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+#include 
+#include 
+#include "radeon.h"
+#include "radeon_asic.h"
+#include "r600d.h"
+
+static void dce3_2_afmt_write_speaker_allocation(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
+   u32 tmp;
+   u8 *sadb;
+   int sad_count;
+
+   list_for_each_entry(connector, 
&encoder->dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder) {
+   radeon_connector = to_radeon_connector(connector);
+   break;
+   }
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Couldn't find encoder's connector\n");
+   return;
+   }
+
+   sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
&sadb);
+   if (sad_count < 0) {
+   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sad_count);
+   return;
+   }
+
+   /* program the speaker allocation */
+   tmp = RREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER);
+   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
+   /* set HDMI mode */
+   tmp |= HDMI_CONNECTION;
+   if (sad_count)
+   tmp |= SPEAKER_ALLOCATION(sadb[0]);
+   else
+   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
+   WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp);
+
+   kfree(sadb);
+}
+
+static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_c

[deathsimple/drm-next-3.16][PATCH V3 4/4] drm/radeon/hdmi: DCE2: simplify audio workaround

[Rafał Miłecki]

Thanks to advanced RE of fglrx we finally know what exactly needs to be
handled of AFMT change.

This has been tested for possible regressions on:
1) DCE2 HD2400 (RV610)
2) DCE3 HD3470 (RV620)

For a reference and details see:
https://bugzilla.kernel.org/show_bug.cgi?id=76231

Signed-off-by: Rafa? Mi?ecki 
---
V2: Move r600d.h changes to 0003 (from 0004) to don't break compilation
Fix typo in commit message
---
 drivers/gpu/drm/radeon/r600_hdmi.c | 82 ++
 1 file changed, 22 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index a90914f..26ef8ce 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -442,14 +442,16 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode *mod
WREG32(HDMI0_RAMP_CONTROL2 + offset, 0x0001);
WREG32(HDMI0_RAMP_CONTROL3 + offset, 0x0001);

-   r600_hdmi_audio_workaround(encoder);
-
/* enable audio after to setting up hw */
r600_audio_enable(rdev, dig->afmt->pin, true);
 }

-/*
- * update settings with current parameters from audio engine
+/**
+ * r600_hdmi_update_audio_settings - Update audio infoframe
+ *
+ * @encoder: drm encoder
+ *
+ * Gets info about current audio stream and updates audio infoframe.
  */
 void r600_hdmi_update_audio_settings(struct drm_encoder *encoder)
 {
@@ -461,7 +463,7 @@ void r600_hdmi_update_audio_settings(struct drm_encoder 
*encoder)
uint8_t buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_AUDIO_INFOFRAME_SIZE];
struct hdmi_audio_infoframe frame;
uint32_t offset;
-   uint32_t iec;
+   uint32_t value;
ssize_t err;

if (!dig->afmt || !dig->afmt->enabled)
@@ -474,60 +476,6 @@ void r600_hdmi_update_audio_settings(struct drm_encoder 
*encoder)
DRM_DEBUG("0x%02X IEC60958 status bits and 0x%02X category code\n",
  (int)audio.status_bits, (int)audio.category_code);

-   iec = 0;
-   if (audio.status_bits & AUDIO_STATUS_PROFESSIONAL)
-   iec |= 1 << 0;
-   if (audio.status_bits & AUDIO_STATUS_NONAUDIO)
-   iec |= 1 << 1;
-   if (audio.status_bits & AUDIO_STATUS_COPYRIGHT)
-   iec |= 1 << 2;
-   if (audio.status_bits & AUDIO_STATUS_EMPHASIS)
-   iec |= 1 << 3;
-
-   iec |= HDMI0_60958_CS_CATEGORY_CODE(audio.category_code);
-
-   switch (audio.rate) {
-   case 32000:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0x3);
-   break;
-   case 44100:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0x0);
-   break;
-   case 48000:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0x2);
-   break;
-   case 88200:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0x8);
-   break;
-   case 96000:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0xa);
-   break;
-   case 176400:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0xc);
-   break;
-   case 192000:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0xe);
-   break;
-   }
-
-   WREG32(HDMI0_60958_0 + offset, iec);
-
-   iec = 0;
-   switch (audio.bits_per_sample) {
-   case 16:
-   iec |= HDMI0_60958_CS_WORD_LENGTH(0x2);
-   break;
-   case 20:
-   iec |= HDMI0_60958_CS_WORD_LENGTH(0x3);
-   break;
-   case 24:
-   iec |= HDMI0_60958_CS_WORD_LENGTH(0xb);
-   break;
-   }
-   if (audio.status_bits & AUDIO_STATUS_V)
-   iec |= 0x5 << 16;
-   WREG32_P(HDMI0_60958_1 + offset, iec, ~0x5000f);
-
err = hdmi_audio_infoframe_init(&frame);
if (err < 0) {
DRM_ERROR("failed to setup audio infoframe\n");
@@ -542,8 +490,22 @@ void r600_hdmi_update_audio_settings(struct drm_encoder 
*encoder)
return;
}

+   value = RREG32(HDMI0_AUDIO_PACKET_CONTROL + offset);
+   if (value & HDMI0_AUDIO_TEST_EN)
+   WREG32(HDMI0_AUDIO_PACKET_CONTROL + offset,
+  value & ~HDMI0_AUDIO_TEST_EN);
+
+   WREG32_OR(HDMI0_CONTROL + offset,
+ HDMI0_ERROR_ACK);
+
+   WREG32_AND(HDMI0_INFOFRAME_CONTROL0 + offset,
+  ~HDMI0_AUDIO_INFO_SOURCE);
+
r600_hdmi_update_audio_infoframe(encoder, buffer, sizeof(buffer));
-   r600_hdmi_audio_workaround(encoder);
+
+   WREG32_OR(HDMI0_INFOFRAME_CONTROL0 + offset,
+ HDMI0_AUDIO_INFO_CONT |
+ HDMI0_AUDIO_INFO_UPDATE);
 }

 /*
-- 
1.8.4.5

[deathsimple/drm-next-3.16][PATCH V3 3/4] drm/radeon/hdmi: DCE2: update setmode

[Rafał Miłecki]

Recent RE efforts revealed ops performed by fglrx during HDMI setup.
This mostly adds masks to r/w ops plus few single missing bits.

This has been tested for possible regressions on:
1) DCE2 HD2400 (RV610)
2) DCE3 HD3470 (RV620)

For a reference and details see:
https://bugzilla.kernel.org/show_bug.cgi?id=76231

Signed-off-by: Rafa? Mi?ecki 
---
V2: Move r600d.h changes to 0003 (from 0004) to don't break compilation
Fix typo in commit message
Leave comment about DCE 3.0 and ACR control
V3: Rebase
---
 drivers/gpu/drm/radeon/r600_hdmi.c | 112 +
 drivers/gpu/drm/radeon/r600d.h |  15 +
 2 files changed, 90 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index a828222e..a90914f 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -142,14 +142,26 @@ void r600_hdmi_update_ACR(struct drm_encoder *encoder, 
uint32_t clock)
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t offset = dig->afmt->offset;

-   WREG32(HDMI0_ACR_32_0 + offset, HDMI0_ACR_CTS_32(acr.cts_32khz));
-   WREG32(HDMI0_ACR_32_1 + offset, acr.n_32khz);
-
-   WREG32(HDMI0_ACR_44_0 + offset, HDMI0_ACR_CTS_44(acr.cts_44_1khz));
-   WREG32(HDMI0_ACR_44_1 + offset, acr.n_44_1khz);
-
-   WREG32(HDMI0_ACR_48_0 + offset, HDMI0_ACR_CTS_48(acr.cts_48khz));
-   WREG32(HDMI0_ACR_48_1 + offset, acr.n_48khz);
+   WREG32_P(HDMI0_ACR_32_0 + offset,
+HDMI0_ACR_CTS_32(acr.cts_32khz),
+~HDMI0_ACR_CTS_32_MASK);
+   WREG32_P(HDMI0_ACR_32_1 + offset,
+HDMI0_ACR_N_32(acr.n_32khz),
+~HDMI0_ACR_N_32_MASK);
+
+   WREG32_P(HDMI0_ACR_44_0 + offset,
+HDMI0_ACR_CTS_44(acr.cts_44_1khz),
+~HDMI0_ACR_CTS_44_MASK);
+   WREG32_P(HDMI0_ACR_44_1 + offset,
+HDMI0_ACR_N_44(acr.n_44_1khz),
+~HDMI0_ACR_N_44_MASK);
+
+   WREG32_P(HDMI0_ACR_48_0 + offset,
+HDMI0_ACR_CTS_48(acr.cts_48khz),
+~HDMI0_ACR_CTS_48_MASK);
+   WREG32_P(HDMI0_ACR_48_1 + offset,
+HDMI0_ACR_N_48(acr.n_48khz),
+~HDMI0_ACR_N_48_MASK);
 }

 /*
@@ -349,39 +361,44 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode *mod

r600_audio_set_dto(encoder, mode->clock);

-   WREG32(HDMI0_VBI_PACKET_CONTROL + offset,
-  HDMI0_NULL_SEND); /* send null packets when required */
-
-   WREG32(HDMI0_AUDIO_PACKET_CONTROL + offset,
-  HDMI0_AUDIO_SAMPLE_SEND | /* send audio packets */
-  HDMI0_AUDIO_DELAY_EN(1) | /* default audio delay */
-  HDMI0_AUDIO_PACKETS_PER_LINE(3) | /* should be suffient for all 
audio modes and small enough for all hblanks */
-  HDMI0_60958_CS_UPDATE); /* allow 60958 channel status fields to 
be updated */
+   WREG32_P(HDMI0_AUDIO_PACKET_CONTROL + offset,
+HDMI0_AUDIO_SAMPLE_SEND | /* send audio packets */
+HDMI0_AUDIO_DELAY_EN(1) | /* default audio delay */
+HDMI0_AUDIO_PACKETS_PER_LINE(3) | /* should be suffient for 
all audio modes and small enough for all hblanks */
+HDMI0_60958_CS_UPDATE, /* allow 60958 channel status fields to 
be updated */
+~(HDMI0_AUDIO_SAMPLE_SEND |
+  HDMI0_AUDIO_DELAY_EN_MASK |
+  HDMI0_AUDIO_PACKETS_PER_LINE_MASK |
+  HDMI0_60958_CS_UPDATE));

/* DCE 3.0 uses register that's normally for CRC_CONTROL */
acr_ctl = ASIC_IS_DCE3(rdev) ? DCE3_HDMI0_ACR_PACKET_CONTROL :
   HDMI0_ACR_PACKET_CONTROL;
-   WREG32(acr_ctl + offset,
-  HDMI0_ACR_SOURCE | /* select SW CTS value - XXX verify that hw 
CTS works on all families */
-  HDMI0_ACR_AUTO_SEND); /* allow hw to sent ACR packets when 
required */
-
-   WREG32(HDMI0_VBI_PACKET_CONTROL + offset,
-  HDMI0_NULL_SEND | /* send null packets when required */
-  HDMI0_GC_SEND | /* send general control packets */
-  HDMI0_GC_CONT); /* send general control packets every frame */
-
-   /* TODO: HDMI0_AUDIO_INFO_UPDATE */
-   WREG32(HDMI0_INFOFRAME_CONTROL0 + offset,
-  HDMI0_AVI_INFO_SEND | /* enable AVI info frames */
-  HDMI0_AVI_INFO_CONT | /* send AVI info frames every frame/field 
*/
-  HDMI0_AUDIO_INFO_SEND | /* enable audio info frames (frames 
won't be set until audio is enabled) */
-  HDMI0_AUDIO_INFO_CONT); /* send audio info frames every 
frame/field */
-
-   WREG32(HDMI0_INFOFRAME_CONTROL1 + offset,
-  HDMI0_AVI_INFO_LINE(2) | /* anything other than 0 */
-  HDMI0_AUDIO_INFO_LINE(2)); /* anything other than 0 */
-
-   WREG32(HDMI0_GC + offset, 0); /* unset HDMI0_GC_AVMUTE */

[deathsimple/drm-next-3.16][PATCH V3 2/4] drm/radeon/hdmi: DCE3: clean ACR control

[Rafał Miłecki]

What initially seemed to be a typo in fglrx (using register 0x740c
instead of 0x74dc) appeared to be a correct behavior. DCE3 has ACR and
CRC registers swapped which explains why we needed
WREG32(HDMI0_AUDIO_CRC_CONTROL + offset, 0x1000);

This has been tested for possible regressions on DCE3 HD3470 (RV620).

Signed-off-by: Rafa? Mi?ecki 
---
V2: Use defines for swapped regs, update commit message.
---
 drivers/gpu/drm/radeon/r600_hdmi.c | 8 +---
 drivers/gpu/drm/radeon/r600d.h | 2 ++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index b8b2efa..a828222e 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -332,6 +332,7 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, struct 
drm_display_mode *mod
u8 buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_AVI_INFOFRAME_SIZE];
struct hdmi_avi_infoframe frame;
uint32_t offset;
+   uint32_t acr_ctl;
ssize_t err;

if (!dig || !dig->afmt)
@@ -351,15 +352,16 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode *mod
WREG32(HDMI0_VBI_PACKET_CONTROL + offset,
   HDMI0_NULL_SEND); /* send null packets when required */

-   WREG32(HDMI0_AUDIO_CRC_CONTROL + offset, 0x1000);
-
WREG32(HDMI0_AUDIO_PACKET_CONTROL + offset,
   HDMI0_AUDIO_SAMPLE_SEND | /* send audio packets */
   HDMI0_AUDIO_DELAY_EN(1) | /* default audio delay */
   HDMI0_AUDIO_PACKETS_PER_LINE(3) | /* should be suffient for all 
audio modes and small enough for all hblanks */
   HDMI0_60958_CS_UPDATE); /* allow 60958 channel status fields to 
be updated */

-   WREG32(HDMI0_ACR_PACKET_CONTROL + offset,
+   /* DCE 3.0 uses register that's normally for CRC_CONTROL */
+   acr_ctl = ASIC_IS_DCE3(rdev) ? DCE3_HDMI0_ACR_PACKET_CONTROL :
+  HDMI0_ACR_PACKET_CONTROL;
+   WREG32(acr_ctl + offset,
   HDMI0_ACR_SOURCE | /* select SW CTS value - XXX verify that hw 
CTS works on all families */
   HDMI0_ACR_AUTO_SEND); /* allow hw to sent ACR packets when 
required */

diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index 37455f6..10380c5 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -1038,6 +1038,7 @@
 #   define HDMI0_AZ_FORMAT_WTRIG_ACK   (1 << 29)
 #define HDMI0_AUDIO_CRC_CONTROL  0x740c
 #   define HDMI0_AUDIO_CRC_EN(1 << 0)
+#define DCE3_HDMI0_ACR_PACKET_CONTROL  0x740c
 #define HDMI0_VBI_PACKET_CONTROL 0x7410
 #   define HDMI0_NULL_SEND   (1 << 0)
 #   define HDMI0_GC_SEND (1 << 4)
@@ -1166,6 +1167,7 @@
 #   define HDMI0_ACR_48  3
 #   define HDMI0_ACR_SOURCE  (1 << 8) /* 0 - hw; 1 - cts value */
 #   define HDMI0_ACR_AUTO_SEND   (1 << 12)
+#define DCE3_HDMI0_AUDIO_CRC_CONTROL   0x74dc
 #define HDMI0_RAMP_CONTROL0  0x74e0
 #   define HDMI0_RAMP_MAX_COUNT(x)   (((x) & 0xff) << 0)
 #define HDMI0_RAMP_CONTROL1  0x74e4
-- 
1.8.4.5

[deathsimple/drm-next-3.16][PATCH V3 1/4] drm/radeon/hdmi: use separated file for DCE 3.1/3.2 code

[Rafał Miłecki]

DCE 3.1 and 3.2 should be programmed in a different way than DCE 2 and
DCE 3. The order of setting registers and sets of registers are
different.
It's still unsure how we will handle DCE 3.1 vs. DCE 3.2, since they
have few differences as well.
For now separate DCE 2 and DCE 3 path, so we can work on it without a
risk of breaking DCE 3.1+.

This has been tested for possible regressions on DCE32 HD4550 (RV710).

Signed-off-by: Rafa? Mi?ecki 
---
 drivers/gpu/drm/radeon/Makefile  |   2 +-
 drivers/gpu/drm/radeon/dce3_1_afmt.c | 222 +++
 drivers/gpu/drm/radeon/r600_hdmi.c   | 149 ++-
 drivers/gpu/drm/radeon/radeon_asic.c |   2 +-
 drivers/gpu/drm/radeon/radeon_asic.h |   7 ++
 5 files changed, 241 insertions(+), 141 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/dce3_1_afmt.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 0943353..dbcbfe8 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
radeon_cs.o radeon_bios.o radeon_benchmark.o r100.o r300.o r420.o \
rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \
r200.o radeon_legacy_tv.o r600_cs.o r600_blit_shaders.o \
-   radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
+   radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o dce3_1_afmt.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c 
b/drivers/gpu/drm/radeon/dce3_1_afmt.c
new file mode 100644
index 000..39cb922
--- /dev/null
+++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
@@ -0,0 +1,222 @@
+#include 
+#include 
+#include "radeon.h"
+#include "radeon_asic.h"
+#include "r600d.h"
+
+static void dce3_2_afmt_write_speaker_allocation(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
+   u32 tmp;
+   u8 *sadb;
+   int sad_count;
+
+   list_for_each_entry(connector, 
&encoder->dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder) {
+   radeon_connector = to_radeon_connector(connector);
+   break;
+   }
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Couldn't find encoder's connector\n");
+   return;
+   }
+
+   sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
&sadb);
+   if (sad_count < 0) {
+   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sad_count);
+   return;
+   }
+
+   /* program the speaker allocation */
+   tmp = RREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER);
+   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
+   /* set HDMI mode */
+   tmp |= HDMI_CONNECTION;
+   if (sad_count)
+   tmp |= SPEAKER_ALLOCATION(sadb[0]);
+   else
+   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
+   WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp);
+
+   kfree(sadb);
+}
+
+static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
+   struct cea_sad *sads;
+   int i, sad_count;
+
+   static const u16 eld_reg_to_type[][2] = {
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR0, 
HDMI_AUDIO_CODING_TYPE_PCM },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR1, 
HDMI_AUDIO_CODING_TYPE_AC3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR2, 
HDMI_AUDIO_CODING_TYPE_MPEG1 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR3, 
HDMI_AUDIO_CODING_TYPE_MP3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR4, 
HDMI_AUDIO_CODING_TYPE_MPEG2 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR5, 
HDMI_AUDIO_CODING_TYPE_AAC_LC },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR6, 
HDMI_AUDIO_CODING_TYPE_DTS },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR7, 
HDMI_AUDIO_CODING_TYPE_ATRAC },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR9, 
HDMI_AUDIO_CODING_TYPE_EAC3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR10, 
HDMI_AUDIO_CODING_TYPE_DTS_HD },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR11, 
HDMI_AUDIO_CODING_TYPE_MLP },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR13, 
HDMI_AUDIO_CODING_TYPE_WMA_PRO },
+   };
+
+   list_for_each_entry(connector, 
&encoder->dev->mode_config.connector_list, head) {
+   

[deathsimple/drm-next-3.16][PATCH V2 4/4] drm/radeon/hdmi: DCE2: simplify audio workaround

[Rafał Miłecki]

Thanks to advanced RE of fglrx we finally know what exactly needs to be
handled of AFMT change.

This has been tested for possible regressions on:
1) DCE2 HD2400 (RV610)
2) DCE3 HD3470 (RV620)

For a reference and details see:
https://bugzilla.kernel.org/show_bug.cgi?id=76231

Signed-off-by: Rafa? Mi?ecki 
---
V2: Move r600d.h changes to 0003 (from 0004) to don't break compilation
Fix typo in commit message
---
 drivers/gpu/drm/radeon/r600_hdmi.c | 82 ++
 1 file changed, 22 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index a611dd4..91f0e07 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -441,14 +441,16 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode *mod
WREG32(HDMI0_RAMP_CONTROL2 + offset, 0x0001);
WREG32(HDMI0_RAMP_CONTROL3 + offset, 0x0001);

-   r600_hdmi_audio_workaround(encoder);
-
/* enable audio after to setting up hw */
r600_audio_enable(rdev, dig->afmt->pin, true);
 }

-/*
- * update settings with current parameters from audio engine
+/**
+ * r600_hdmi_update_audio_settings - Update audio infoframe
+ *
+ * @encoder: drm encoder
+ *
+ * Gets info about current audio stream and updates audio infoframe.
  */
 void r600_hdmi_update_audio_settings(struct drm_encoder *encoder)
 {
@@ -460,7 +462,7 @@ void r600_hdmi_update_audio_settings(struct drm_encoder 
*encoder)
uint8_t buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_AUDIO_INFOFRAME_SIZE];
struct hdmi_audio_infoframe frame;
uint32_t offset;
-   uint32_t iec;
+   uint32_t value;
ssize_t err;

if (!dig->afmt || !dig->afmt->enabled)
@@ -473,60 +475,6 @@ void r600_hdmi_update_audio_settings(struct drm_encoder 
*encoder)
DRM_DEBUG("0x%02X IEC60958 status bits and 0x%02X category code\n",
  (int)audio.status_bits, (int)audio.category_code);

-   iec = 0;
-   if (audio.status_bits & AUDIO_STATUS_PROFESSIONAL)
-   iec |= 1 << 0;
-   if (audio.status_bits & AUDIO_STATUS_NONAUDIO)
-   iec |= 1 << 1;
-   if (audio.status_bits & AUDIO_STATUS_COPYRIGHT)
-   iec |= 1 << 2;
-   if (audio.status_bits & AUDIO_STATUS_EMPHASIS)
-   iec |= 1 << 3;
-
-   iec |= HDMI0_60958_CS_CATEGORY_CODE(audio.category_code);
-
-   switch (audio.rate) {
-   case 32000:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0x3);
-   break;
-   case 44100:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0x0);
-   break;
-   case 48000:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0x2);
-   break;
-   case 88200:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0x8);
-   break;
-   case 96000:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0xa);
-   break;
-   case 176400:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0xc);
-   break;
-   case 192000:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0xe);
-   break;
-   }
-
-   WREG32(HDMI0_60958_0 + offset, iec);
-
-   iec = 0;
-   switch (audio.bits_per_sample) {
-   case 16:
-   iec |= HDMI0_60958_CS_WORD_LENGTH(0x2);
-   break;
-   case 20:
-   iec |= HDMI0_60958_CS_WORD_LENGTH(0x3);
-   break;
-   case 24:
-   iec |= HDMI0_60958_CS_WORD_LENGTH(0xb);
-   break;
-   }
-   if (audio.status_bits & AUDIO_STATUS_V)
-   iec |= 0x5 << 16;
-   WREG32_P(HDMI0_60958_1 + offset, iec, ~0x5000f);
-
err = hdmi_audio_infoframe_init(&frame);
if (err < 0) {
DRM_ERROR("failed to setup audio infoframe\n");
@@ -541,8 +489,22 @@ void r600_hdmi_update_audio_settings(struct drm_encoder 
*encoder)
return;
}

+   value = RREG32(HDMI0_AUDIO_PACKET_CONTROL + offset);
+   if (value & HDMI0_AUDIO_TEST_EN)
+   WREG32(HDMI0_AUDIO_PACKET_CONTROL + offset,
+  value & ~HDMI0_AUDIO_TEST_EN);
+
+   WREG32_OR(HDMI0_CONTROL + offset,
+ HDMI0_ERROR_ACK);
+
+   WREG32_AND(HDMI0_INFOFRAME_CONTROL0 + offset,
+  ~HDMI0_AUDIO_INFO_SOURCE);
+
r600_hdmi_update_audio_infoframe(encoder, buffer, sizeof(buffer));
-   r600_hdmi_audio_workaround(encoder);
+
+   WREG32_OR(HDMI0_INFOFRAME_CONTROL0 + offset,
+ HDMI0_AUDIO_INFO_CONT |
+ HDMI0_AUDIO_INFO_UPDATE);
 }

 /*
-- 
1.8.4.5

[deathsimple/drm-next-3.16][PATCH V2 3/4] drm/radeon/hdmi: DCE2: update setmode

[Rafał Miłecki]

Recent RE efforts revealed ops performed by fglrx during HDMI setup.
This mostly adds masks to r/w ops plus few single missing bits.

This has been tested for possible regressions on:
1) DCE2 HD2400 (RV610)
2) DCE3 HD3470 (RV620)

For a reference and details see:
https://bugzilla.kernel.org/show_bug.cgi?id=76231

Signed-off-by: Rafa? Mi?ecki 
---
V2: Move r600d.h changes to 0003 (from 0004) to don't break compilation
Fix typo in commit message
Leave comment about DCE 3.0 and ACR control
---
 drivers/gpu/drm/radeon/r600_hdmi.c | 112 +
 drivers/gpu/drm/radeon/r600d.h |  15 +
 2 files changed, 90 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index d4c13a0..a611dd4 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -142,14 +142,26 @@ void r600_hdmi_update_ACR(struct drm_encoder *encoder, 
uint32_t clock)
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t offset = dig->afmt->offset;

-   WREG32(HDMI0_ACR_32_0 + offset, HDMI0_ACR_CTS_32(acr.cts_32khz));
-   WREG32(HDMI0_ACR_32_1 + offset, acr.n_32khz);
-
-   WREG32(HDMI0_ACR_44_0 + offset, HDMI0_ACR_CTS_44(acr.cts_44_1khz));
-   WREG32(HDMI0_ACR_44_1 + offset, acr.n_44_1khz);
-
-   WREG32(HDMI0_ACR_48_0 + offset, HDMI0_ACR_CTS_48(acr.cts_48khz));
-   WREG32(HDMI0_ACR_48_1 + offset, acr.n_48khz);
+   WREG32_P(HDMI0_ACR_32_0 + offset,
+HDMI0_ACR_CTS_32(acr.cts_32khz),
+~HDMI0_ACR_CTS_32_MASK);
+   WREG32_P(HDMI0_ACR_32_1 + offset,
+HDMI0_ACR_N_32(acr.n_32khz),
+~HDMI0_ACR_N_32_MASK);
+
+   WREG32_P(HDMI0_ACR_44_0 + offset,
+HDMI0_ACR_CTS_44(acr.cts_44_1khz),
+~HDMI0_ACR_CTS_44_MASK);
+   WREG32_P(HDMI0_ACR_44_1 + offset,
+HDMI0_ACR_N_44(acr.n_44_1khz),
+~HDMI0_ACR_N_44_MASK);
+
+   WREG32_P(HDMI0_ACR_48_0 + offset,
+HDMI0_ACR_CTS_48(acr.cts_48khz),
+~HDMI0_ACR_CTS_48_MASK);
+   WREG32_P(HDMI0_ACR_48_1 + offset,
+HDMI0_ACR_N_48(acr.n_48khz),
+~HDMI0_ACR_N_48_MASK);
 }

 /*
@@ -349,38 +361,43 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode *mod

r600_audio_set_dto(encoder, mode->clock);

-   WREG32(HDMI0_VBI_PACKET_CONTROL + offset,
-  HDMI0_NULL_SEND); /* send null packets when required */
-
-   WREG32(HDMI0_AUDIO_PACKET_CONTROL + offset,
-  HDMI0_AUDIO_SAMPLE_SEND | /* send audio packets */
-  HDMI0_AUDIO_DELAY_EN(1) | /* default audio delay */
-  HDMI0_AUDIO_PACKETS_PER_LINE(3) | /* should be suffient for all 
audio modes and small enough for all hblanks */
-  HDMI0_60958_CS_UPDATE); /* allow 60958 channel status fields to 
be updated */
+   WREG32_P(HDMI0_AUDIO_PACKET_CONTROL + offset,
+HDMI0_AUDIO_SAMPLE_SEND | /* send audio packets */
+HDMI0_AUDIO_DELAY_EN(1) | /* default audio delay */
+HDMI0_AUDIO_PACKETS_PER_LINE(3) | /* should be suffient for 
all audio modes and small enough for all hblanks */
+HDMI0_60958_CS_UPDATE, /* allow 60958 channel status fields to 
be updated */
+~(HDMI0_AUDIO_SAMPLE_SEND |
+  HDMI0_AUDIO_DELAY_EN_MASK |
+  HDMI0_AUDIO_PACKETS_PER_LINE_MASK |
+  HDMI0_60958_CS_UPDATE));

/* DCE 3.0 uses register that's normally for CRC_CONTROL */
acr_ctl = ASIC_IS_DCE3(rdev) ? 0x740c : HDMI0_ACR_PACKET_CONTROL;
-   WREG32(acr_ctl + offset,
-  HDMI0_ACR_SOURCE | /* select SW CTS value - XXX verify that hw 
CTS works on all families */
-  HDMI0_ACR_AUTO_SEND); /* allow hw to sent ACR packets when 
required */
-
-   WREG32(HDMI0_VBI_PACKET_CONTROL + offset,
-  HDMI0_NULL_SEND | /* send null packets when required */
-  HDMI0_GC_SEND | /* send general control packets */
-  HDMI0_GC_CONT); /* send general control packets every frame */
-
-   /* TODO: HDMI0_AUDIO_INFO_UPDATE */
-   WREG32(HDMI0_INFOFRAME_CONTROL0 + offset,
-  HDMI0_AVI_INFO_SEND | /* enable AVI info frames */
-  HDMI0_AVI_INFO_CONT | /* send AVI info frames every frame/field 
*/
-  HDMI0_AUDIO_INFO_SEND | /* enable audio info frames (frames 
won't be set until audio is enabled) */
-  HDMI0_AUDIO_INFO_CONT); /* send audio info frames every 
frame/field */
-
-   WREG32(HDMI0_INFOFRAME_CONTROL1 + offset,
-  HDMI0_AVI_INFO_LINE(2) | /* anything other than 0 */
-  HDMI0_AUDIO_INFO_LINE(2)); /* anything other than 0 */
-
-   WREG32(HDMI0_GC + offset, 0); /* unset HDMI0_GC_AVMUTE */
+   WREG32_P(acr_ctl + offset,
+HDMI0_ACR_SOURCE | /*

[deathsimple/drm-next-3.16][4/4] drm/radeon/hdmi: DCE2: simplify audio workaround

[Rafał Miłecki]

Thanks to advanced RE of fglrx we finally know what exactly needs to be
handled of AFMT change.

This has been tested for possible regressions on:
1) DCE2 D2400 (RV610)
2) DCE3 HD3470 (RV620)

For a reference and details see:
https://bugzilla.kernel.org/show_bug.cgi?id=76231

Signed-off-by: Rafa? Mi?ecki 
---
 drivers/gpu/drm/radeon/r600_hdmi.c | 82 ++
 drivers/gpu/drm/radeon/r600d.h | 15 +++
 2 files changed, 37 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 8c36587..033a88d 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -440,14 +440,16 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode *mod
WREG32(HDMI0_RAMP_CONTROL2 + offset, 0x0001);
WREG32(HDMI0_RAMP_CONTROL3 + offset, 0x0001);

-   r600_hdmi_audio_workaround(encoder);
-
/* enable audio after to setting up hw */
r600_audio_enable(rdev, dig->afmt->pin, true);
 }

-/*
- * update settings with current parameters from audio engine
+/**
+ * r600_hdmi_update_audio_settings - Update audio infoframe
+ *
+ * @encoder: drm encoder
+ *
+ * Gets info about current audio stream and updates audio infoframe.
  */
 void r600_hdmi_update_audio_settings(struct drm_encoder *encoder)
 {
@@ -459,7 +461,7 @@ void r600_hdmi_update_audio_settings(struct drm_encoder 
*encoder)
uint8_t buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_AUDIO_INFOFRAME_SIZE];
struct hdmi_audio_infoframe frame;
uint32_t offset;
-   uint32_t iec;
+   uint32_t value;
ssize_t err;

if (!dig->afmt || !dig->afmt->enabled)
@@ -472,60 +474,6 @@ void r600_hdmi_update_audio_settings(struct drm_encoder 
*encoder)
DRM_DEBUG("0x%02X IEC60958 status bits and 0x%02X category code\n",
  (int)audio.status_bits, (int)audio.category_code);

-   iec = 0;
-   if (audio.status_bits & AUDIO_STATUS_PROFESSIONAL)
-   iec |= 1 << 0;
-   if (audio.status_bits & AUDIO_STATUS_NONAUDIO)
-   iec |= 1 << 1;
-   if (audio.status_bits & AUDIO_STATUS_COPYRIGHT)
-   iec |= 1 << 2;
-   if (audio.status_bits & AUDIO_STATUS_EMPHASIS)
-   iec |= 1 << 3;
-
-   iec |= HDMI0_60958_CS_CATEGORY_CODE(audio.category_code);
-
-   switch (audio.rate) {
-   case 32000:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0x3);
-   break;
-   case 44100:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0x0);
-   break;
-   case 48000:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0x2);
-   break;
-   case 88200:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0x8);
-   break;
-   case 96000:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0xa);
-   break;
-   case 176400:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0xc);
-   break;
-   case 192000:
-   iec |= HDMI0_60958_CS_SAMPLING_FREQUENCY(0xe);
-   break;
-   }
-
-   WREG32(HDMI0_60958_0 + offset, iec);
-
-   iec = 0;
-   switch (audio.bits_per_sample) {
-   case 16:
-   iec |= HDMI0_60958_CS_WORD_LENGTH(0x2);
-   break;
-   case 20:
-   iec |= HDMI0_60958_CS_WORD_LENGTH(0x3);
-   break;
-   case 24:
-   iec |= HDMI0_60958_CS_WORD_LENGTH(0xb);
-   break;
-   }
-   if (audio.status_bits & AUDIO_STATUS_V)
-   iec |= 0x5 << 16;
-   WREG32_P(HDMI0_60958_1 + offset, iec, ~0x5000f);
-
err = hdmi_audio_infoframe_init(&frame);
if (err < 0) {
DRM_ERROR("failed to setup audio infoframe\n");
@@ -540,8 +488,22 @@ void r600_hdmi_update_audio_settings(struct drm_encoder 
*encoder)
return;
}

+   value = RREG32(HDMI0_AUDIO_PACKET_CONTROL + offset);
+   if (value & HDMI0_AUDIO_TEST_EN)
+   WREG32(HDMI0_AUDIO_PACKET_CONTROL + offset,
+  value & ~HDMI0_AUDIO_TEST_EN);
+
+   WREG32_OR(HDMI0_CONTROL + offset,
+ HDMI0_ERROR_ACK);
+
+   WREG32_AND(HDMI0_INFOFRAME_CONTROL0 + offset,
+  ~HDMI0_AUDIO_INFO_SOURCE);
+
r600_hdmi_update_audio_infoframe(encoder, buffer, sizeof(buffer));
-   r600_hdmi_audio_workaround(encoder);
+
+   WREG32_OR(HDMI0_INFOFRAME_CONTROL0 + offset,
+ HDMI0_AUDIO_INFO_CONT |
+ HDMI0_AUDIO_INFO_UPDATE);
 }

 /*
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index 37455f6..b140c93 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -1029,9 +1029,11 @@
 #define HDMI0_AUDIO_PACKET_CONTROL   0x7408
 #   define HDMI0_AUDIO_SAMPLE_SEND  (1 << 0)
 #   define HDMI0_AUDIO_DELAY_EN(x)  ((

[deathsimple/drm-next-3.16][3/4] drm/radeon/hdmi: DCE2: update setmode

[Rafał Miłecki]

Recent RE efforts revealed ops performed by fglrx during HDMI setup.
This mostly adds masks to r/w ops plus few single missing bits.

This has been tested for possible regressions on:
1) DCE2 D2400 (RV610)
2) DCE3 HD3470 (RV620)

For a reference and details see:
https://bugzilla.kernel.org/show_bug.cgi?id=76231

Signed-off-by: Rafa? Mi?ecki 
---
 drivers/gpu/drm/radeon/r600_hdmi.c | 113 -
 1 file changed, 75 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index d4c13a0..8c36587 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -142,14 +142,26 @@ void r600_hdmi_update_ACR(struct drm_encoder *encoder, 
uint32_t clock)
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t offset = dig->afmt->offset;

-   WREG32(HDMI0_ACR_32_0 + offset, HDMI0_ACR_CTS_32(acr.cts_32khz));
-   WREG32(HDMI0_ACR_32_1 + offset, acr.n_32khz);
-
-   WREG32(HDMI0_ACR_44_0 + offset, HDMI0_ACR_CTS_44(acr.cts_44_1khz));
-   WREG32(HDMI0_ACR_44_1 + offset, acr.n_44_1khz);
-
-   WREG32(HDMI0_ACR_48_0 + offset, HDMI0_ACR_CTS_48(acr.cts_48khz));
-   WREG32(HDMI0_ACR_48_1 + offset, acr.n_48khz);
+   WREG32_P(HDMI0_ACR_32_0 + offset,
+HDMI0_ACR_CTS_32(acr.cts_32khz),
+~HDMI0_ACR_CTS_32_MASK);
+   WREG32_P(HDMI0_ACR_32_1 + offset,
+HDMI0_ACR_N_32(acr.n_32khz),
+~HDMI0_ACR_N_32_MASK);
+
+   WREG32_P(HDMI0_ACR_44_0 + offset,
+HDMI0_ACR_CTS_44(acr.cts_44_1khz),
+~HDMI0_ACR_CTS_44_MASK);
+   WREG32_P(HDMI0_ACR_44_1 + offset,
+HDMI0_ACR_N_44(acr.n_44_1khz),
+~HDMI0_ACR_N_44_MASK);
+
+   WREG32_P(HDMI0_ACR_48_0 + offset,
+HDMI0_ACR_CTS_48(acr.cts_48khz),
+~HDMI0_ACR_CTS_48_MASK);
+   WREG32_P(HDMI0_ACR_48_1 + offset,
+HDMI0_ACR_N_48(acr.n_48khz),
+~HDMI0_ACR_N_48_MASK);
 }

 /*
@@ -349,38 +361,42 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode *mod

r600_audio_set_dto(encoder, mode->clock);

-   WREG32(HDMI0_VBI_PACKET_CONTROL + offset,
-  HDMI0_NULL_SEND); /* send null packets when required */
-
-   WREG32(HDMI0_AUDIO_PACKET_CONTROL + offset,
-  HDMI0_AUDIO_SAMPLE_SEND | /* send audio packets */
-  HDMI0_AUDIO_DELAY_EN(1) | /* default audio delay */
-  HDMI0_AUDIO_PACKETS_PER_LINE(3) | /* should be suffient for all 
audio modes and small enough for all hblanks */
-  HDMI0_60958_CS_UPDATE); /* allow 60958 channel status fields to 
be updated */
+   WREG32_P(HDMI0_AUDIO_PACKET_CONTROL + offset,
+HDMI0_AUDIO_SAMPLE_SEND | /* send audio packets */
+HDMI0_AUDIO_DELAY_EN(1) | /* default audio delay */
+HDMI0_AUDIO_PACKETS_PER_LINE(3) | /* should be suffient for 
all audio modes and small enough for all hblanks */
+HDMI0_60958_CS_UPDATE, /* allow 60958 channel status fields to 
be updated */
+~(HDMI0_AUDIO_SAMPLE_SEND |
+  HDMI0_AUDIO_DELAY_EN_MASK |
+  HDMI0_AUDIO_PACKETS_PER_LINE_MASK |
+  HDMI0_60958_CS_UPDATE));

-   /* DCE 3.0 uses register that's normally for CRC_CONTROL */
acr_ctl = ASIC_IS_DCE3(rdev) ? 0x740c : HDMI0_ACR_PACKET_CONTROL;
-   WREG32(acr_ctl + offset,
-  HDMI0_ACR_SOURCE | /* select SW CTS value - XXX verify that hw 
CTS works on all families */
-  HDMI0_ACR_AUTO_SEND); /* allow hw to sent ACR packets when 
required */
-
-   WREG32(HDMI0_VBI_PACKET_CONTROL + offset,
-  HDMI0_NULL_SEND | /* send null packets when required */
-  HDMI0_GC_SEND | /* send general control packets */
-  HDMI0_GC_CONT); /* send general control packets every frame */
-
-   /* TODO: HDMI0_AUDIO_INFO_UPDATE */
-   WREG32(HDMI0_INFOFRAME_CONTROL0 + offset,
-  HDMI0_AVI_INFO_SEND | /* enable AVI info frames */
-  HDMI0_AVI_INFO_CONT | /* send AVI info frames every frame/field 
*/
-  HDMI0_AUDIO_INFO_SEND | /* enable audio info frames (frames 
won't be set until audio is enabled) */
-  HDMI0_AUDIO_INFO_CONT); /* send audio info frames every 
frame/field */
-
-   WREG32(HDMI0_INFOFRAME_CONTROL1 + offset,
-  HDMI0_AVI_INFO_LINE(2) | /* anything other than 0 */
-  HDMI0_AUDIO_INFO_LINE(2)); /* anything other than 0 */
-
-   WREG32(HDMI0_GC + offset, 0); /* unset HDMI0_GC_AVMUTE */
+   WREG32_P(acr_ctl + offset,
+HDMI0_ACR_SOURCE | /* select SW CTS value - XXX verify that hw 
CTS works on all families */
+HDMI0_ACR_AUTO_SEND, /* allow hw to sent ACR packets when 
required */
+~(HDMI0_ACR_SOURCE |
+  

[deathsimple/drm-next-3.16][2/4] drm/radeon/hdmi: DCE3: clean ACR control

[Rafał Miłecki]

What initially seemed to be a typo in fglrx (using register 0x740c
instead of 74dc) appeared to be a correct behavior. Without this
0x740c reg operation DCE 3 doesn't work and it seems we got code for
that already in place.
Recent RE effors allowed to finally understand this magic:
WREG32(HDMI0_AUDIO_CRC_CONTROL + offset, 0x1000);

This has been tested for possible regressions on DCE3 HD3470 (RV620).

Signed-off-by: Rafa? Mi?ecki 
---
 drivers/gpu/drm/radeon/r600_hdmi.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index b8b2efa..d4c13a0 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -332,6 +332,7 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, struct 
drm_display_mode *mod
u8 buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_AVI_INFOFRAME_SIZE];
struct hdmi_avi_infoframe frame;
uint32_t offset;
+   uint32_t acr_ctl;
ssize_t err;

if (!dig || !dig->afmt)
@@ -351,15 +352,15 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode *mod
WREG32(HDMI0_VBI_PACKET_CONTROL + offset,
   HDMI0_NULL_SEND); /* send null packets when required */

-   WREG32(HDMI0_AUDIO_CRC_CONTROL + offset, 0x1000);
-
WREG32(HDMI0_AUDIO_PACKET_CONTROL + offset,
   HDMI0_AUDIO_SAMPLE_SEND | /* send audio packets */
   HDMI0_AUDIO_DELAY_EN(1) | /* default audio delay */
   HDMI0_AUDIO_PACKETS_PER_LINE(3) | /* should be suffient for all 
audio modes and small enough for all hblanks */
   HDMI0_60958_CS_UPDATE); /* allow 60958 channel status fields to 
be updated */

-   WREG32(HDMI0_ACR_PACKET_CONTROL + offset,
+   /* DCE 3.0 uses register that's normally for CRC_CONTROL */
+   acr_ctl = ASIC_IS_DCE3(rdev) ? 0x740c : HDMI0_ACR_PACKET_CONTROL;
+   WREG32(acr_ctl + offset,
   HDMI0_ACR_SOURCE | /* select SW CTS value - XXX verify that hw 
CTS works on all families */
   HDMI0_ACR_AUTO_SEND); /* allow hw to sent ACR packets when 
required */

-- 
1.8.4.5

[deathsimple/drm-next-3.16][1/4] drm/radeon/hdmi: use separated file for DCE 3.1/3.2 code

[Rafał Miłecki]

DCE 3.1 and 3.2 should be programmed in a different way than DCE 2 and
DCE 3. The order of setting registers and sets of registers are
different.
It's still unsure how we will handle DCE 3.1 vs. DCE 3.2, since they
have few differences as well.
For now separate DCE 2 and DCE 3 path, so we can work on it without a
risk of breaking DCE 3.1+.

This has been tested for possible regressions on DCE32 HD4550 (RV710).

Signed-off-by: Rafa? Mi?ecki 
---
 drivers/gpu/drm/radeon/Makefile  |   2 +-
 drivers/gpu/drm/radeon/dce3_1_afmt.c | 222 +++
 drivers/gpu/drm/radeon/r600_hdmi.c   | 149 ++-
 drivers/gpu/drm/radeon/radeon_asic.c |   2 +-
 drivers/gpu/drm/radeon/radeon_asic.h |   7 ++
 5 files changed, 241 insertions(+), 141 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/dce3_1_afmt.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 0943353..dbcbfe8 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
radeon_cs.o radeon_bios.o radeon_benchmark.o r100.o r300.o r420.o \
rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \
r200.o radeon_legacy_tv.o r600_cs.o r600_blit_shaders.o \
-   radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
+   radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o dce3_1_afmt.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c 
b/drivers/gpu/drm/radeon/dce3_1_afmt.c
new file mode 100644
index 000..39cb922
--- /dev/null
+++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
@@ -0,0 +1,222 @@
+#include 
+#include 
+#include "radeon.h"
+#include "radeon_asic.h"
+#include "r600d.h"
+
+static void dce3_2_afmt_write_speaker_allocation(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
+   u32 tmp;
+   u8 *sadb;
+   int sad_count;
+
+   list_for_each_entry(connector, 
&encoder->dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder) {
+   radeon_connector = to_radeon_connector(connector);
+   break;
+   }
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Couldn't find encoder's connector\n");
+   return;
+   }
+
+   sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
&sadb);
+   if (sad_count < 0) {
+   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sad_count);
+   return;
+   }
+
+   /* program the speaker allocation */
+   tmp = RREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER);
+   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
+   /* set HDMI mode */
+   tmp |= HDMI_CONNECTION;
+   if (sad_count)
+   tmp |= SPEAKER_ALLOCATION(sadb[0]);
+   else
+   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
+   WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp);
+
+   kfree(sadb);
+}
+
+static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
+   struct cea_sad *sads;
+   int i, sad_count;
+
+   static const u16 eld_reg_to_type[][2] = {
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR0, 
HDMI_AUDIO_CODING_TYPE_PCM },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR1, 
HDMI_AUDIO_CODING_TYPE_AC3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR2, 
HDMI_AUDIO_CODING_TYPE_MPEG1 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR3, 
HDMI_AUDIO_CODING_TYPE_MP3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR4, 
HDMI_AUDIO_CODING_TYPE_MPEG2 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR5, 
HDMI_AUDIO_CODING_TYPE_AAC_LC },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR6, 
HDMI_AUDIO_CODING_TYPE_DTS },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR7, 
HDMI_AUDIO_CODING_TYPE_ATRAC },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR9, 
HDMI_AUDIO_CODING_TYPE_EAC3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR10, 
HDMI_AUDIO_CODING_TYPE_DTS_HD },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR11, 
HDMI_AUDIO_CODING_TYPE_MLP },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR13, 
HDMI_AUDIO_CODING_TYPE_WMA_PRO },
+   };
+
+   list_for_each_entry(connector, 
&encoder->dev->mode_config.connector_list, head) {
+   

[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw

[Rafał Miłecki]

 On 12 May 2014 20:09, Alex Deucher  wrote:
> As far as I recall, 3.1 is
> pretty much the same as 3.0 from a programming perspective, but it's
> been a while since I looked at it in detail.

Please take a look at attached dce31.html file. It's a dump from fglrx
operations during HDMI mode setup.

You can see it's very similar for DCE 3.2 except for
AUDIO_PACKET_CONTROL and INFOFRAME_CONTROL0. But I think it's still
easier to add 2 or 3 /ifs/ in the code shared between DCE 3.1 and DCE
3.2

Apart from the above exceptions:

1) DCE3.1 uses AFMT_AUDIO_PACKET_CONTROL2 like DCE3.2
I don't think DCE2/3 had AUDIO_LAYOUT_OVRD or 60958_CS_SOURCE.

2) DCE3.1 controls ACR_AUTO_SEND with HDMI_ACR_PACKET_CONTROL like
DCE3.2. In DCE2/3 it was handled in HDMI0_ACR_PACKET_CONTROL register,
but wasn't touched by fglrx code.

3) DCE3.1 has this new AFMT_60958_2 register just like DCE3.2
It wasn't present in DCE2/3, see:
/* HDMI0_60958_2 is r7xx only */

4) DCE3.1 has AUDIO_DESCRIPTORs, like DCE3.2
I believe they were not present on DCE2/3

5) DCE3.1 enables audio engines just like DCE3.2 (using extra 0x7308
register during en/disable)

So I'm pretty sure we don't want to share code between DCE2/3.0 and DCE3.1.

The question is if we want separated code for DCE3.1 and DCE3.2. So
far it seems we can handle DCE3.1 and DCE3.2 with shared simply using
2 or 3 conditions.

-- 
Rafa?
-- next part --
An HTML attachment was scrubbed...
URL: 

[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw

[Rafał Miłecki]

On 12 May 2014 19:42, Rafa? Mi?ecki  wrote:
> On 12 May 2014 17:57, Alex Deucher  wrote:
>> On Mon, May 12, 2014 at 9:54 AM, Rafa? Mi?ecki  wrote:
>>> DCE 3.1 and 3.2 have different HDMI registers and should be programmed
>>> in a slightly different way. Moving support to separated file will
>>> allow use to use rv770d.h header in the future and adjust code as well.
>>
>> Any reason not to split it at DCE3.2 rather than 3.1?  It seems like
>> most (all?) of the changes are DCE3.2 specific rather than DCE3.1.
>> Otherwise, seems fine to me.
>
> I believe DCE 3.1 has HDMI much more like DCE 3.2 and it's programmed
> in a very similar way. Also it has 3.2 regs like DESCRIPTORs. The
> biggest difference is that DCE 3.1 doesn't seem to have
> AFMT_AUDIO_PACKET_CONTROL and AFMT_INFOFRAME_CONTROL0.

After looking closer... maybe I have to review it again. It seems
programming order of DCE 3.1 is much more like DCE 3.2, but registers
of DCE 3.1 are more like DCE 2.0/3.0. Maybe we'll need even one more
split.

I'll review it and come back.

[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw

[Rafał Miłecki]

On 12 May 2014 17:57, Alex Deucher  wrote:
> On Mon, May 12, 2014 at 9:54 AM, Rafa? Mi?ecki  wrote:
>> DCE 3.1 and 3.2 have different HDMI registers and should be programmed
>> in a slightly different way. Moving support to separated file will
>> allow use to use rv770d.h header in the future and adjust code as well.
>
> Any reason not to split it at DCE3.2 rather than 3.1?  It seems like
> most (all?) of the changes are DCE3.2 specific rather than DCE3.1.
> Otherwise, seems fine to me.

I believe DCE 3.1 has HDMI much more like DCE 3.2 and it's programmed
in a very similar way. Also it has 3.2 regs like DESCRIPTORs. The
biggest difference is that DCE 3.1 doesn't seem to have
AFMT_AUDIO_PACKET_CONTROL and AFMT_INFOFRAME_CONTROL0.

Take a look at defines for DCE 3.2. Even they are placed in rv770d.h,
which is the DCE 3.1 chipset.

[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw

[Rafał Miłecki]

On 12 May 2014 16:19, Christian K?nig  wrote:
> Am 12.05.2014 15:54, schrieb Rafa? Mi?ecki:
>
>> DCE 3.1 and 3.2 have different HDMI registers and should be programmed
>> in a slightly different way. Moving support to separated file will
>> allow use to use rv770d.h header in the future and adjust code as well.
>
> Looks like a valid cleanup to me. Should probably go into 3.16.

Thanks for review. Of course it's 3.16 material, no rush.

I'll re-send with Signed-off-by in a bigger patchset, after extra testing.

[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw

[Rafał Miłecki]

DCE 3.1 and 3.2 have different HDMI registers and should be programmed
in a slightly different way. Moving support to separated file will
allow use to use rv770d.h header in the future and adjust code as well.
---
 drivers/gpu/drm/radeon/Makefile  |   2 +-
 drivers/gpu/drm/radeon/dce3_1_afmt.c | 221 +++
 drivers/gpu/drm/radeon/r600_hdmi.c   | 130 +
 drivers/gpu/drm/radeon/radeon_asic.c |   2 +-
 drivers/gpu/drm/radeon/radeon_asic.h |   7 ++
 5 files changed, 235 insertions(+), 127 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/dce3_1_afmt.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 0943353..dbcbfe8 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
radeon_cs.o radeon_bios.o radeon_benchmark.o r100.o r300.o r420.o \
rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \
r200.o radeon_legacy_tv.o r600_cs.o r600_blit_shaders.o \
-   radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
+   radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o dce3_1_afmt.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c 
b/drivers/gpu/drm/radeon/dce3_1_afmt.c
new file mode 100644
index 000..4e3a8b7
--- /dev/null
+++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
@@ -0,0 +1,221 @@
+#include 
+#include "radeon.h"
+#include "radeon_asic.h"
+#include "r600d.h"
+
+static void dce3_2_afmt_write_speaker_allocation(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
+   u32 tmp;
+   u8 *sadb;
+   int sad_count;
+
+   list_for_each_entry(connector, 
&encoder->dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder) {
+   radeon_connector = to_radeon_connector(connector);
+   break;
+   }
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Couldn't find encoder's connector\n");
+   return;
+   }
+
+   sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
&sadb);
+   if (sad_count < 0) {
+   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sad_count);
+   return;
+   }
+
+   /* program the speaker allocation */
+   tmp = RREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER);
+   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
+   /* set HDMI mode */
+   tmp |= HDMI_CONNECTION;
+   if (sad_count)
+   tmp |= SPEAKER_ALLOCATION(sadb[0]);
+   else
+   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
+   WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp);
+
+   kfree(sadb);
+}
+
+static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
+   struct cea_sad *sads;
+   int i, sad_count;
+
+   static const u16 eld_reg_to_type[][2] = {
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR0, 
HDMI_AUDIO_CODING_TYPE_PCM },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR1, 
HDMI_AUDIO_CODING_TYPE_AC3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR2, 
HDMI_AUDIO_CODING_TYPE_MPEG1 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR3, 
HDMI_AUDIO_CODING_TYPE_MP3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR4, 
HDMI_AUDIO_CODING_TYPE_MPEG2 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR5, 
HDMI_AUDIO_CODING_TYPE_AAC_LC },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR6, 
HDMI_AUDIO_CODING_TYPE_DTS },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR7, 
HDMI_AUDIO_CODING_TYPE_ATRAC },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR9, 
HDMI_AUDIO_CODING_TYPE_EAC3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR10, 
HDMI_AUDIO_CODING_TYPE_DTS_HD },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR11, 
HDMI_AUDIO_CODING_TYPE_MLP },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR13, 
HDMI_AUDIO_CODING_TYPE_WMA_PRO },
+   };
+
+   list_for_each_entry(connector, 
&encoder->dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder) {
+   radeon_connector = to_radeon_connector(connector);
+   break;
+   }
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Cou

CIK hangs with kernel 3.15, bisected

[Rafał Miłecki]

On 9 May 2014 20:03, Marek Ol??k  wrote:
> This commit which first appeared in 3.15-rc1 causes hangs on Bonaire:
>
> commit 6d2f2944e95e504a7d33385eeeb9bb7fcca72592
> Author: Christian K?nig 
> Date:   Thu Feb 20 13:42:17 2014 +0100
>
> drm/radeon: use normal BOs for the page tables v4

Also reported in:
https://bugzilla.kernel.org/show_bug.cgi?id=75651

[PATCH] fix memory leak

[Rafał Miłecki]

Please re-send this patch with a correct commit message (subject). Add
at least "drm: " prefix to it.

2014-04-09 23:11 GMT+02:00 Micah Richert :
> Signed-off-by: Micah Richert 

You have some weird indent before "Signed-off-by".

3.14-rc1 ring/display regression in "low" power_profile (drm/radeon/pm: move pm handling into the asic specific code)

[Rafał Miłecki]

2014-02-25 18:04 GMT+01:00 Alex Deucher :
> Does the attached patch help?

It does, thanks!

-- 
Rafa?

3.14-rc1 ring/display regression in "low" power_profile (drm/radeon/pm: move pm handling into the asic specific code)

[Rafał Miłecki]

2014-02-06 8:28 GMT+01:00 Rafa? Mi?ecki :
> I can't successfully resume using "low" power_profile. My testing
> looks like this:
> boot
> s & r (result: GOOD)
> s & r (result: GOOD)
> s & r (result: GOOD)
> echo "low" > /sys/class/drm/card0/device/power_profile
> s & r (result: BAD)
>
> BAD means display corruption [0] and:
> [ 80.244475] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
> (scratch(0x8504)=0xCAFEDEAD)
> [ 80.244475] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume

Ping?

-- 
Rafa?

GeForce 6100 (NV4E) & nouveau regression in 3.12

[Rafał Miłecki]

2014-02-16 19:55 GMT+01:00 Ilia Mirkin :
> On Sun, Feb 16, 2014 at 10:17 AM, Rafa? Mi?ecki  wrote:
>> 2014-02-11 11:41 GMT+01:00 Ilia Mirkin :
>>> (b) bisect. you can (almost) definitely restrict the bisect to
>>> drivers/gpu/drm/nouveau. if you have additional computational power, i
>>> would recommend looking into distcc for speeding up the compiles. it
>>> may be interesting to also try 3.6.x since 3.7 received a pretty big
>>> rewrite. but a git bisect is a lot more direct in figuring these
>>> things out :)
>>>
>>> After I watched your video, it definitely brought back memories of
>>> another bug or perhaps email on this list a while back (definitely
>>> within the past year), but unfortunately I can't quite place it :(
>>
>> I've finally bisected between 3.10 and 3.11:
>>
>> 78ae0ad403daf11cf63da86923d2b5dbeda3af8f is the first bad commit
>> commit 78ae0ad403daf11cf63da86923d2b5dbeda3af8f
>> Author: Ben Skeggs 
>> Date: Wed Aug 21 11:30:36 2013 +1000
>>
>> drm/nv04/disp: fix framebuffer pin refcounting
>>
>> I've booted that commit and one commit older few times. Every time I
>> booted 78ae0ad I got corruption. Every time I booted 6ff8c76 (it's the
>> earlier commit), it was OK.
>
> But I bet if you restart X, you get a backtrace, right?

That's right.

78ae0ad:
Corruptions

6ff8c76:
WARNING: at drivers/gpu/drm/nouveau/nouveau_bo.c:151
nouveau_bo_del_ttm+0x80/0x90 [nouveau]()
(after quiting X by "init 3")

-- 
Rafa?

GeForce 6100 (NV4E) & nouveau regression in 3.12

[Rafał Miłecki]

2014-02-11 11:41 GMT+01:00 Ilia Mirkin :
> (b) bisect. you can (almost) definitely restrict the bisect to
> drivers/gpu/drm/nouveau. if you have additional computational power, i
> would recommend looking into distcc for speeding up the compiles. it
> may be interesting to also try 3.6.x since 3.7 received a pretty big
> rewrite. but a git bisect is a lot more direct in figuring these
> things out :)
>
> After I watched your video, it definitely brought back memories of
> another bug or perhaps email on this list a while back (definitely
> within the past year), but unfortunately I can't quite place it :(

I've finally bisected between 3.10 and 3.11:

78ae0ad403daf11cf63da86923d2b5dbeda3af8f is the first bad commit
commit 78ae0ad403daf11cf63da86923d2b5dbeda3af8f
Author: Ben Skeggs 
Date: Wed Aug 21 11:30:36 2013 +1000

drm/nv04/disp: fix framebuffer pin refcounting

I've booted that commit and one commit older few times. Every time I
booted 78ae0ad I got corruption. Every time I booted 6ff8c76 (it's the
earlier commit), it was OK.

Ben: any idea why this commit caused regression for my hardware? From
the commit message I assume it was supposed to affect some ancient
nv04 hardware only. Did it accidentally touch my nv4e path code maybe?

-- 
Rafa?

GeForce 6100 (NV4E) & nouveau regression in 3.12

[Rafał Miłecki]

2014-02-11 11:41 GMT+01:00 Ilia Mirkin :
> On Mon, Feb 10, 2014 at 3:05 PM, Rafa? Mi?ecki  wrote:
>> 2014-02-10 20:06 GMT+01:00 Ilia Mirkin :
>>> There was also an issue with libdrm_nouveau for pre-nv50 chips, when
>>> compiled with gcc-4.8 some time back... fixed in... 2.4.48 or so?
>>
>> I use openSUSE 12.2 (x86_64) which provides gcc 4.7.1 and
>> libdrm_nouveau1-2.4.33-2.3.2.x86_64. I assume libdrm_nouveau was
>> compiled using that 4.7.1.
>
> Hmmm... the nouveau drm rewrite went into 2.4.34... I guess you're
> using pretty old userspace in general, since everything depends on the
> post-rewrite libdrm_nouveau. Of course it definitely sounds like a
> kernel issue, but I can't help but wonder if this is a non-issue with
> later userspace.
>
> So there are basically 2 things left to do, in order of time-consuming-ness:
>
> (a) try a live{cd,usb} (e.g. arch, or something else that has recent
> software), and see if the issue is still present there.

I've tried Fedora 20 booted from USB. It suffers from the same issue.
It's based on kernel 3.11.10, but I'm sure it has more up to date
userspace.


> (b) bisect. you can (almost) definitely restrict the bisect to
> drivers/gpu/drm/nouveau. if you have additional computational power, i
> would recommend looking into distcc for speeding up the compiles. it
> may be interesting to also try 3.6.x since 3.7 received a pretty big
> rewrite. but a git bisect is a lot more direct in figuring these
> things out :)

Bisecting nouveau between 3.10 and 3.11 is a real pain.


Ben introduced booting regression with commit:
commit dceef5d87cc01358cc1434416f3272e2ddc3d97a
Author: Ben Skeggs 
Date: Mon Mar 4 13:01:21 2013 +1000

drm/nouveau/fb: initialise vram controller as pfb sub-object

I had to first bisect fix for that regression which appeared to be:
commit 6284bf41b97fb36ed96b664a3c23b6dc3661f5f9
Author: Ilia Mirkin 
Date: Fri Aug 9 17:25:54 2013 -0400

drm/nouveau/fb: fix null derefs in nv49 and nv4e init


Unfortunately meanwhile another init regression was introduced with:
commit 0108bc808107b97e101b15af9705729626be6447
Author: Maarten Lankhorst 
Date: Sun Jul 7 10:40:19 2013 +0200

drm/nouveau: do not allow negative sizes for now

And I had to find fix for that which was:
commit 35095f7529bb6abdfc956e7a41ca6957520b70a7
Author: Maarten Lankhorst 
Date: Sat Jul 27 10:17:12 2013 +0200

drm/nouveau: fix size check for cards without vm

Then I finally was able to test every commit between 3.10 and 3.11
without skipping 90% of them.

-- 
Rafa?

GeForce 6100 (NV4E) & nouveau regression in 3.12

[Rafał Miłecki]

2014-02-11 11:41 GMT+01:00 Ilia Mirkin :
> (b) bisect. you can (almost) definitely restrict the bisect to
> drivers/gpu/drm/nouveau. if you have additional computational power, i
> would recommend looking into distcc for speeding up the compiles. it
> may be interesting to also try 3.6.x since 3.7 received a pretty big
> rewrite. but a git bisect is a lot more direct in figuring these
> things out :)

I've already bisected commit that changed this pink line issue into a
general screen corruption. Just to remind it was:

commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
Author: Dave Airlie 
Date: Fri Sep 20 08:32:59 2013 +1000

Revert "drm: mark context support as a legacy subsystem"

Would you like me to bisect commit that introduced this pink line issue?

-- 
Rafa?

GeForce 6100 (NV4E) & nouveau regression in 3.12

[Rafał Miłecki]

2014-02-10 20:06 GMT+01:00 Ilia Mirkin :
> Lastly, it may be worth trying 3.11.x and 3.12.x to get a better
> handle on when problems happened. The commits you cite are in the
> middle of releases, and may have various badness associated with them
> (e.g. 3.12-rc had a later-disabled MSI implementation, back in 3.13...
> probably some other stuff).

I've tried Linux 3.11.0, 3.11.10 and 3.12.0. All of them suffer from
this corruption.

-- 
Rafa?

GeForce 6100 (NV4E) & nouveau regression in 3.12

[Rafał Miłecki]

2014-02-10 20:06 GMT+01:00 Ilia Mirkin :
> On Mon, Feb 10, 2014 at 10:12 AM, Rafa? Mi?ecki  wrote:
>> 2014-02-09 23:12 GMT+01:00 Ilia Mirkin :
>>> On Sun, Feb 9, 2014 at 5:08 PM, Rafa? Mi?ecki  wrote:
 Last week I've switched from my old & good 3.4.63 to 3.14-rc1 and
 noticed nasty display corruptions when using nouveau. It seems that
 changing parts of the screen are appearing for a fraction of second in
 random places. I've recorded this behavior:
 http://www.youtube.com/watch?v=IEq7JzGVzj0

 My hardware is some old motherboard with
 00:05.0 VGA compatible controller [0300]: NVIDIA Corporation C51G
 [GeForce 6100] [10de:0242] (rev a2)
 integrated. Since my CPU is ancient AMD Sempron(tm) Processor 2800+ it
 took me few days to track this issue.

 There goes some summary of various kernels:

 1) 3.4.63
 No display problems. Works great.

 2) commit 928c2f0c006bf7f381f58af2b2786d2a858ae311
 drm/fb-helper: don't sleep for screen unblank when an oops is in progress
 Scrollbars have a pink line. I didn't track which commit introduced
 this pink corruption. No other problems.

 3) commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
 Revert "drm: mark context support as a legacy subsystem"
 This fixes pink lines on scrollbars and introduces this nasty display
 corruption. It's one commit after previous one.
 It means it's the first bad commit for these nasty corruptions recoded
 and uploaded to YouTube.

 4) 3.14-rc1
 No changes since c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095. No pink
 lines, but display corruptions happening.
>>>
>>> Can you boot with nouveau.config=NvMSI=0 ? If that helps, there are
>>> some patches on the nouveau/dri-devel lists (search for "nv4c") that
>>> may help you.
>>
>> Unfortunately this config parameter doesn't help :(
>
> Too bad. It may still be worthwhile applying the patches and seeing
> what happens... it seems like some registers got switched around on
> the nv4x IGP's:
>
> http://lists.freedesktop.org/archives/nouveau/2014-February/016032.html
> http://lists.freedesktop.org/archives/nouveau/2014-February/016033.html
> http://lists.freedesktop.org/archives/nouveau/2014-February/016034.html

I've applied all 3 patches, compiled, tried... didn't help. I've also
tried nouveau.config=NvMSI=0 on top on your patches, didn't help.


> BTW, youtube says "this video is unavailable".

Ohh, Google/YouTube really doesn't like ppl removing G+ account...
http://files.zajec.net/20140208-nouveau.mp4


> Is there anything in dmesg when the display corruptions happen?

No.


> There was also an issue with libdrm_nouveau for pre-nv50 chips, when
> compiled with gcc-4.8 some time back... fixed in... 2.4.48 or so?

I use openSUSE 12.2 (x86_64) which provides gcc 4.7.1 and
libdrm_nouveau1-2.4.33-2.3.2.x86_64. I assume libdrm_nouveau was
compiled using that 4.7.1.


> Lastly, it may be worth trying 3.11.x and 3.12.x to get a better
> handle on when problems happened. The commits you cite are in the
> middle of releases, and may have various badness associated with them
> (e.g. 3.12-rc had a later-disabled MSI implementation, back in 3.13...
> probably some other stuff).

I'll provide results tomorrow.

-- 
Rafa?

GeForce 6100 (NV4E) & nouveau regression in 3.12

[Rafał Miłecki]

2014-02-09 23:12 GMT+01:00 Ilia Mirkin :
> On Sun, Feb 9, 2014 at 5:08 PM, Rafa? Mi?ecki  wrote:
>> Last week I've switched from my old & good 3.4.63 to 3.14-rc1 and
>> noticed nasty display corruptions when using nouveau. It seems that
>> changing parts of the screen are appearing for a fraction of second in
>> random places. I've recorded this behavior:
>> http://www.youtube.com/watch?v=IEq7JzGVzj0
>>
>> My hardware is some old motherboard with
>> 00:05.0 VGA compatible controller [0300]: NVIDIA Corporation C51G
>> [GeForce 6100] [10de:0242] (rev a2)
>> integrated. Since my CPU is ancient AMD Sempron(tm) Processor 2800+ it
>> took me few days to track this issue.
>>
>> There goes some summary of various kernels:
>>
>> 1) 3.4.63
>> No display problems. Works great.
>>
>> 2) commit 928c2f0c006bf7f381f58af2b2786d2a858ae311
>> drm/fb-helper: don't sleep for screen unblank when an oops is in progress
>> Scrollbars have a pink line. I didn't track which commit introduced
>> this pink corruption. No other problems.
>>
>> 3) commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
>> Revert "drm: mark context support as a legacy subsystem"
>> This fixes pink lines on scrollbars and introduces this nasty display
>> corruption. It's one commit after previous one.
>> It means it's the first bad commit for these nasty corruptions recoded
>> and uploaded to YouTube.
>>
>> 4) 3.14-rc1
>> No changes since c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095. No pink
>> lines, but display corruptions happening.
>
> Can you boot with nouveau.config=NvMSI=0 ? If that helps, there are
> some patches on the nouveau/dri-devel lists (search for "nv4c") that
> may help you.

Unfortunately this config parameter doesn't help :(

-- 
Rafa?

GeForce 6100 (NV4E) & nouveau regression in 3.12

[Rafał Miłecki]

Hi guys,

Last week I've switched from my old & good 3.4.63 to 3.14-rc1 and
noticed nasty display corruptions when using nouveau. It seems that
changing parts of the screen are appearing for a fraction of second in
random places. I've recorded this behavior:
http://www.youtube.com/watch?v=IEq7JzGVzj0

My hardware is some old motherboard with
00:05.0 VGA compatible controller [0300]: NVIDIA Corporation C51G
[GeForce 6100] [10de:0242] (rev a2)
integrated. Since my CPU is ancient AMD Sempron(tm) Processor 2800+ it
took me few days to track this issue.

There goes some summary of various kernels:

1) 3.4.63
No display problems. Works great.

2) commit 928c2f0c006bf7f381f58af2b2786d2a858ae311
drm/fb-helper: don't sleep for screen unblank when an oops is in progress
Scrollbars have a pink line. I didn't track which commit introduced
this pink corruption. No other problems.

3) commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
Revert "drm: mark context support as a legacy subsystem"
This fixes pink lines on scrollbars and introduces this nasty display
corruption. It's one commit after previous one.
It means it's the first bad commit for these nasty corruptions recoded
and uploaded to YouTube.

4) 3.14-rc1
No changes since c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095. No pink
lines, but display corruptions happening.

As you can see, this is a bit complex. Regression with pink lines on
scrollbars was introduced at some point, but it was fixed.
Unfortunately the same commit that fixed pink color also introduced
much more nasty corruption during screen refresh.

Is there any more info I can provide to help fixing this?

I'm a bit afraid the tracked commit
c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095 only exposed some hidden
issue. Could bisecting for a pink lines regression help?

-- 
Rafa?
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.14.0-rc1-torvalds+ (zayec at linux-n0m0) (gcc 
version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) ) #2 SMP 
PREEMPT Sun Feb 9 09:49:19 CET 2014
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.14.0-rc1-torvalds+ 
root=UUID=709eef04-7598-4719-b305-3d8db2635038 video=1280x1024 
resume=/dev/disk/by-id/ata-WDC_WD1600JS-55MHB1_WD-WCANM6560356-part1 
splash=silent quiet showopts
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e8000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1bfa] usable
[0.00] BIOS-e820: [mem 0x1bfb-0x1bfb] ACPI data
[0.00] BIOS-e820: [mem 0x1bfc-0x1bfe] ACPI NVS
[0.00] BIOS-e820: [mem 0x1bff-0x1bff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfeef] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.3 present.
[0.00] DMI:  K8NF4G-SATA2/K8NF4G-SATA2, BIOS P1.50 11/03/2005
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] No AGP bridge found
[0.00] e820: last_pfn = 0x1bfb0 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-E uncachable
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 00 mask FFE000 write-back
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at 
[880ff780]
[0.00] Scanning 1 areas for low memory corruption
[0.00] Base memory trampoline at [88099000] 99000 size 24576
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] BRK [0x01fa5000, 0x01fa5fff] PGTABLE
[0.00] BRK [0x01fa6000, 0x01fa6fff] PGTABLE
[0.00] BRK [0x01fa7000, 0x01fa7fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x1bc0-0x1bdf]
[0.00]  [mem 0x1bc0-0x1bdf] page 2M
[0.00] init_memory_mapping: [mem 0x1800-0x1bbf]
[0.00]  [mem 0x1800-0x1bbf] page 2M
[   

3.14-rc1 ring/display regression in "low" power_profile (drm/radeon/pm: move pm handling into the asic specific code)

[Rafał Miłecki]

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Blackcomb [Radeon HD 6970M/6990M] [1002:6720]

I don't use dpm, but a profile method. Right after booting (without
touching power_profile) I can suspend & resume as many times as I want
(tested with ~50 s&r routines).

Starting with:
commit 6c7bccea390853bdec5b76fe31fc50f3b36f75d5
Author: Alex Deucher 
Date: Wed Dec 18 14:07:14 2013 -0500

drm/radeon/pm: move pm handling into the asic specific code

We need more control over the ordering of dpm init with
respect to the rest of the asic. Specifically, the SMC
has to be initialized before the rlc and cg/pg. The pm
code currently initializes late in the driver, but we need
it to happen much earlier so move pm handling into the asic
specific callbacks.

This makes dpm more reliable and makes clockgating work
properly on CIK parts and should help on SI parts as well.

Signed-off-by: Alex Deucher 

I can't successfully resume using "low" power_profile. My testing
looks like this:
boot
s & r (result: GOOD)
s & r (result: GOOD)
s & r (result: GOOD)
echo "low" > /sys/class/drm/card0/device/power_profile
s & r (result: BAD)

BAD means display corruption [0] and:
[ 80.244475] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
(scratch(0x8504)=0xCAFEDEAD)
[ 80.244475] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume

[0] http://files.zajec.net/barts-low-resume-corruption.jpeg

-- 
Rafa?
-- next part --
A non-text attachment was scrubbed...
Name: dmesg.log
Type: application/octet-stream
Size: 173981 bytes
Desc: not available
URL: 

[PATCH] drm/radeon: warn users when hw_i2c is enabled

[Rafał Miłecki]

2014/1/7 Alex Deucher :
> +   if (radeon_hw_i2c == 1)
> +   DRM_INFO("hw_i2c forced on, you may experience display 
> detection problems!\n");

What about simple
if (radeon_hw_i2c)
? Values 2, 3, ... also enable i2c.

[PATCH] drm/radeon/dce6: set correct number of audio pins

[Rafał Miłecki]

2013/12/12 Deucher, Alexander :
>> -Original Message-
>> From: Rafa? Mi?ecki [mailto:zajec5 at gmail.com]
>> Sent: Thursday, December 12, 2013 1:10 PM
>> To: Alex Deucher
>> Cc: dri-devel; Deucher, Alexander
>> Subject: Re: [PATCH] drm/radeon/dce6: set correct number of audio pins
>>
>> 2013/12/12 Alex Deucher :
>> > DCE6.0, 8.x has 6
>> > DCE6.1 has 4
>> >
>> > Signed-off-by: Alex Deucher 
>> > ---
>> >  drivers/gpu/drm/radeon/dce6_afmt.c | 4 +++-
>> >  1 file changed, 3 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c
>> b/drivers/gpu/drm/radeon/dce6_afmt.c
>> > index de86493..ab59fd7 100644
>> > --- a/drivers/gpu/drm/radeon/dce6_afmt.c
>> > +++ b/drivers/gpu/drm/radeon/dce6_afmt.c
>> > @@ -308,7 +308,9 @@ int dce6_audio_init(struct radeon_device *rdev)
>> > rdev->audio.enabled = true;
>> >
>> > if (ASIC_IS_DCE8(rdev))
>> > -   rdev->audio.num_pins = 7;
>> > +   rdev->audio.num_pins = 6;
>> > +   else if (ASIC_IS_DCE61(rdev))
>> > +   rdev->audio.num_pins = 4;
>> > else
>> > rdev->audio.num_pins = 6;
>>
>> You don't check for DCE64, so OLAND will be treated as DCE6.0 (since
>> there isn't IGP Oland, so it won't be treated as 6.1).
>>
>> Does 6.4 also have 6 pins?
>
> Yes.  Oland has the same audio chip as the other SI parts.

Great. Thanks for the patch!

-- 
Rafa?

[PATCH] drm/radeon/dce6: set correct number of audio pins

[Rafał Miłecki]

2013/12/12 Alex Deucher :
> DCE6.0, 8.x has 6
> DCE6.1 has 4
>
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/radeon/dce6_afmt.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c 
> b/drivers/gpu/drm/radeon/dce6_afmt.c
> index de86493..ab59fd7 100644
> --- a/drivers/gpu/drm/radeon/dce6_afmt.c
> +++ b/drivers/gpu/drm/radeon/dce6_afmt.c
> @@ -308,7 +308,9 @@ int dce6_audio_init(struct radeon_device *rdev)
> rdev->audio.enabled = true;
>
> if (ASIC_IS_DCE8(rdev))
> -   rdev->audio.num_pins = 7;
> +   rdev->audio.num_pins = 6;
> +   else if (ASIC_IS_DCE61(rdev))
> +   rdev->audio.num_pins = 4;
> else
> rdev->audio.num_pins = 6;

You don't check for DCE64, so OLAND will be treated as DCE6.0 (since
there isn't IGP Oland, so it won't be treated as 6.1).

Does 6.4 also have 6 pins?

[PATCH] drm/edid: add quirk for BPC in Samsung NP700G7A-S01PL notebook

[Rafał Miłecki]

This bug in EDID was exposed by:

commit eccea7920cfb009c2fa40e9ecdce8c36f61cab66
Author: Alex Deucher 
Date:   Mon Mar 26 15:12:54 2012 -0400

drm/radeon/kms: improve bpc handling (v2)

Which resulted in kind of regression in 3.5. This fixes
https://bugs.freedesktop.org/show_bug.cgi?id=70934

Signed-off-by: Rafa? Mi?ecki 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/drm_edid.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f1764ec..a1b4f2b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -68,6 +68,8 @@
 #define EDID_QUIRK_DETAILED_SYNC_PP(1 << 6)
 /* Force reduced-blanking timings for detailed modes */
 #define EDID_QUIRK_FORCE_REDUCED_BLANKING  (1 << 7)
+/* Force 8bpc */
+#define EDID_QUIRK_FORCE_8BPC  (1 << 8)

 struct detailed_mode_closure {
struct drm_connector *connector;
@@ -128,6 +130,9 @@ static struct edid_quirk {

/* Medion MD 30217 PG */
{ "MED", 0x7b8, EDID_QUIRK_PREFER_LARGE_75 },
+
+   /* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */
+   { "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC },
 };

 /*
@@ -3421,6 +3426,9 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)

drm_add_display_info(edid, &connector->display_info);

+   if (quirks & EDID_QUIRK_FORCE_8BPC)
+   connector->display_info.bpc = 8;
+
return num_modes;
 }
 EXPORT_SYMBOL(drm_add_edid_modes);
-- 
1.7.10.4

[pull] radeon drm-next-3.13

[Rafał Miłecki]

2013/11/10 Alex Deucher :
> On Sat, Nov 9, 2013 at 3:20 AM, Rafa? Mi?ecki  wrote:
>> 2013/11/8 Alex Deucher :
>>>   Revert "drm/radeon/audio: don't set speaker allocation on DCE4+"
>>
>> What about that hangs people reported? Has anything changed meanwhile?
>> Did you fix them with some another commit?
>
> No one actually pointed to this commit as a problem, but it seemed
> like the safe thing to do for 3.12 considering the problems caused by
> the same functionality for DCE3.2 parts.  That said, a number of
> people have tested this patch successfully without problems, and it's
> necessary for the alsa driver to work correctly so I figured it was
> worth trying again for 3.13.

Nice to hear that. My short-hanging case appeared to be eDP related
(disabling eDP takes few seconds for some reason, will debug it some
day).

[pull] radeon drm-next-3.13

[Rafał Miłecki]

2013/11/8 Alex Deucher :
>   Revert "drm/radeon/audio: don't set speaker allocation on DCE4+"

What about that hangs people reported? Has anything changed meanwhile?
Did you fix them with some another commit?

2013/10/28 Deucher, Alexander :
>> Did you get any reports about that? Or is that based only on mine comment:
>
> Yes, I had some reports of hangs on newer chips for some people as well.  I'm 
> not sure if it was directly correlated, but seemed like the safe thing to at 
> this point in the kernel cycle.

[pull] radeon drm-next-3.13

[Rafał Miłecki]

2013/11/6 Dave Airlie :
> On Wed, Nov 6, 2013 at 9:08 PM, Rafa? Mi?ecki  wrote:
>> 2013/11/3 Rafa? Mi?ecki :
>>> 2013/11/1 Alex Deucher :

 Christian K?nig (7):
   drm/radeon: rework and fix reset detection v2
>>>
>>> Please note this pull request (above patch) break suspending on my:
>>> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
>>> nee ATI Blackcomb [Radeon HD 6900M series] [1002:6720]
>>
>> Alex: he have a fix for the above issue, could you add
>> [PATCH] drm/radeon: fix radeon_fence_wait_empty_locked
>> are re-send to Dave?
>>
>
> I already merged the fix into drm-next to avoid the regression there.

Oh, I missed that. Thanks!

-- 
Rafa?

[pull] radeon drm-next-3.13

[Rafał Miłecki]

2013/11/3 Rafa? Mi?ecki :
> 2013/11/1 Alex Deucher :
>>
>> Christian K?nig (7):
>>   drm/radeon: rework and fix reset detection v2
>
> Please note this pull request (above patch) break suspending on my:
> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
> nee ATI Blackcomb [Radeon HD 6900M series] [1002:6720]

Alex: he have a fix for the above issue, could you add
[PATCH] drm/radeon: fix radeon_fence_wait_empty_locked
are re-send to Dave?

-- 
Rafa?

[PATCH] avivotool: fix dumping HDMI blocks on DCE2, DCE3 and DCE3.2

[Rafał Miłecki]

Signed-off-by: Rafa? Mi?ecki 
---
 avivotool.c  |   30 --
 radeon_reg.h |8 +---
 2 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/avivotool.c b/avivotool.c
index 4c5c1ce..f5b3f72 100644
--- a/avivotool.c
+++ b/avivotool.c
@@ -1697,13 +1697,31 @@ void radeon_cmd_regs(const char *type)
SHOW_REG(R600_AUDIO_PIN_WIDGET_CNTL);
SHOW_REG(R600_AUDIO_STATUS_BITS);

-   printf("\nHDMI block at 0x%x:\n", R600_HDMI_BLOCK1);
-   for (i = R600_HDMI_BLOCK1; i < R600_HDMI_BLOCK1 + 0xf0; i += 4)
-   SHOW_UNKNOWN_REG(i);
+   if (IS_DISPLAY_DCE3(card_info)) {
+   printf("\nHDMI block at 0x%x:\n", DCE3_HDMI_BLOCK0);
+   for (i = DCE3_HDMI_BLOCK0; i <= DCE3_HDMI_BLOCK0 + 0xf0; i += 4)
+   SHOW_UNKNOWN_REG(i);
+   if (card_info && card_info->chip_family >= CHIP_FAMILY_RV730) {
+   for (i = DCE3_HDMI_BLOCK0 + 0x200; i <= DCE3_HDMI_BLOCK0 + 
0x210; i += 4)
+   SHOW_UNKNOWN_REG(i);
+   }

-   printf("\nHDMI block at 0x%x:\n", R600_HDMI_BLOCK3);
-   for (i = R600_HDMI_BLOCK3; i < R600_HDMI_BLOCK3 + 0xf0; i += 4)
-   SHOW_UNKNOWN_REG(i);
+   printf("\nHDMI block at 0x%x:\n", DCE3_HDMI_BLOCK1);
+   for (i = DCE3_HDMI_BLOCK1; i <= DCE3_HDMI_BLOCK1 + 0xf0; i += 4)
+   SHOW_UNKNOWN_REG(i);
+   if (card_info && card_info->chip_family >= CHIP_FAMILY_RV730) {
+   for (i = DCE3_HDMI_BLOCK1 + 0x200; i <= DCE3_HDMI_BLOCK1 + 
0x210; i += 4)
+   SHOW_UNKNOWN_REG(i);
+   }
+   } else {
+   printf("\nHDMI block at 0x%x:\n", DCE2_HDMI_BLOCK0);
+   for (i = DCE2_HDMI_BLOCK0; i <= DCE2_HDMI_BLOCK0 + 0xf0; i += 4)
+   SHOW_UNKNOWN_REG(i);
+
+   printf("\nHDMI block at 0x%x:\n", DCE2_HDMI_BLOCK1);
+   for (i = DCE2_HDMI_BLOCK1; i <= DCE2_HDMI_BLOCK1 + 0xf0; i += 4)
+   SHOW_UNKNOWN_REG(i);
+   }
 }
 }

diff --git a/radeon_reg.h b/radeon_reg.h
index ea5b6bc..06136e3 100644
--- a/radeon_reg.h
+++ b/radeon_reg.h
@@ -3063,9 +3063,11 @@
 #define R600_AUDIO_STATUS_BITS 0x73d8

 /* HDMI base register addresses */
-#define R600_HDMI_BLOCK1   0x7400
-#define R600_HDMI_BLOCK2   0x7700
-#define R600_HDMI_BLOCK3   0x7800
+#define DCE2_HDMI_BLOCK0   0x7400
+#define DCE2_HDMI_BLOCK1   0x7700
+/* DCE3 second instance starts at 0x7800 */
+#define DCE3_HDMI_BLOCK0   0x7400
+#define DCE3_HDMI_BLOCK1   0x7800

 #define RADEON_MC_ARB_CNTL 0x18c
 #define RADEON_PWRMAN_MISC 0x16
-- 
1.7.10.4

[PATCH] drm/radeon: fix radeon_fence_wait_empty_locked

[Rafał Miłecki]

2013/11/5 Christian K?nig :
> From: Christian K?nig 
>
> Don't block forever if there is nothing to wait for.
>
> Signed-off-by: Christian K?nig 

Tested-by: Rafa? Mi?ecki 

-- 
Rafa?

[PATCH 1/5] drm/radeon: rework and fix reset detection v2

[Rafał Miłecki]

2013/11/5 Christian K?nig :
> Am 03.11.2013 13:15, schrieb Rafa? Mi?ecki:
>
>> 2013/10/29 Christian K?nig :
>>>
>>> From: Christian K?nig 
>>>
>>> Stop fiddling with jiffies, always wait for RADEON_FENCE_JIFFIES_TIMEOUT.
>>> Consolidate the two wait sequence implementations into just one function.
>>> Activate all waiters and remember if the reset was already done instead
>>> of
>>> trying to reset from only one thread.
>>
>> With this patch I can't suspend my Samsung with:
>> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
>> nee ATI Blackcomb [Radeon HD 6900M series] [1002:6720]
>> anymore.
>>
>> The backlight goes off, activity LED goes off and then nothing.
>> Machine is still running and other lights (power, wifi, keyboard,
>> touchpad) are still working. Seems like a lockup to me.
>
>
> Does the attached patch help?

It does, thanks!

-- 
Rafa?

[PATCH 1/5] drm/radeon: rework and fix reset detection v2

[Rafał Miłecki]

2013/10/29 Christian K?nig :
> From: Christian K?nig 
>
> Stop fiddling with jiffies, always wait for RADEON_FENCE_JIFFIES_TIMEOUT.
> Consolidate the two wait sequence implementations into just one function.
> Activate all waiters and remember if the reset was already done instead of
> trying to reset from only one thread.

With this patch I can't suspend my Samsung with:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
nee ATI Blackcomb [Radeon HD 6900M series] [1002:6720]
anymore.

The backlight goes off, activity LED goes off and then nothing.
Machine is still running and other lights (power, wifi, keyboard,
touchpad) are still working. Seems like a lockup to me.

[pull] radeon drm-next-3.13

[Rafał Miłecki]

2013/11/1 Alex Deucher :
>
> Christian K?nig (7):
>   drm/radeon: rework and fix reset detection v2

Please note this pull request (above patch) break suspending on my:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
nee ATI Blackcomb [Radeon HD 6900M series] [1002:6720]

[PATCH] drm/radeon/audio: fix missing multichannel PCM SAD in some cases

[Rafał Miłecki]

2013/11/2 Anssi Hannula :
> SAD with channels=6,freqs=32..96kHz,bits=16..24 implies that those freqs
> and bps are supported for all channel counts up to 6 (since it is "Max
> Number of channels"). Therefore the specified rates are supported in
> stereo mode as well and I believe should be included in the stereo bitmask.
>
> As per AMD HDA Verbs documentation the 4th byte is "Rates supported for
> stereo". And since those rates _are_ supported by stereo, IMO they
> should be there.

OK, that sounds sane. Thanks for explaining.

Acked-by: Rafa? Mi?ecki 

-- 
Rafa?

[PATCH] drm/radeon/audio: fix missing multichannel PCM SAD in some cases

[Rafał Miłecki]

2013/10/29 Anssi Hannula :
> +   if (sad->channels > max_channels) {
> +   value = MAX_CHANNELS(sad->channels) |
> +   DESCRIPTOR_BYTE_2(sad->byte2) 
> |
> +   
> SUPPORTED_FREQUENCIES(sad->freq);
> +   max_channels = sad->channels;
> +   }

Just for a record. I was wondering if fglrx sets both:
SUPPORTED_FREQUENCIES and SUPPORTED_FREQUENCIES_STEREO for receiver
with LPCM stereo only. It does:
5f84 07070701 (117901057)
5f88  (0)
5f8c  (0)
5f90  (0)
5f94  (0)
5f98  (0)
5f9c  (0)
5fa0  (0)
5fa4  (0)
5fa8  (0)
5fac  (0)
5fb0  (0)
5fb4  (0)
5fb8  (0)

So with the above code we'll be compatible with fglrx about that.
Nice. Just wanted to note that :)

[PATCH] drm/radeon/audio: fix missing multichannel PCM SAD in some cases

[Rafał Miłecki]

2013/10/29 Anssi Hannula :
> Fix the code to pick the PCM SAD with the highest number of channels,
> while merging the rate masks of PCM SADs with lower amount of channels
> into the additional stereo rate mask byte.

Don't you think that we should use SUPPORTED_FREQUENCIES_STEREO for
stereo frequencies only?


> if (sad->format == HDMI_AUDIO_CODING_TYPE_PCM)
> +   stereo_freqs |= sad->freq;

I mean making that (... && sad->channels == 1)

[pull] radeon drm-next-3.13

[Rafał Miłecki]

HDMI/audio part looks fine, thanks!

[PATCH] drm/radeon/audio: fix missing multichannel PCM SAD in some cases

[Rafał Miłecki]

2013/11/1 Rafa? Mi?ecki :
> 2013/10/29 Anssi Hannula :
>> Fix the code to pick the PCM SAD with the highest number of channels,
>> while merging the rate masks of PCM SADs with lower amount of channels
>> into the additional stereo rate mask byte.
>
> Does it mean that now instead of 2 real SADs:
> 1) 192kHz support for 2 channels
> 2) 96kHz support for 8 channels
> you will only get:
> 1) 192kHz support for 8 channels
> ?
> Does it mean alsa may try to play 8channels audio at 192kHz and fail at this?
> That doesn't sound good, but on the other hand I can't propose
> anything better :|

Ahh, wait. I just noticed you're using SUPPORTED_FREQUENCIES and
(different one) SUPPORTED_FREQUENCIES_STEREO there. Sorry I missed
that earlier.

Yeah, just code makes much more sense, I just think the logic in
setting that frequency may be a bit bad... Let me think about this
clearly tomorrow and I'll let you know :)

-- 
Rafa?

[PATCH] drm/radeon/audio: fix missing multichannel PCM SAD in some cases

[Rafał Miłecki]

2013/10/29 Anssi Hannula :
> Because of this, only the 2-channel SAD may be used if it appears before
> the 8-channel SAD. Unless other SADs require otherwise, this may cause
> the ALSA HDA driver to allow stereo playback only.

I can confirm that the problem exists. My SADs (Onkyo TX-SR605):
Format: 1 (PCM)Channels:1Freq:0x7F (32-192)B2:0x07 (16-24b)
Format: 1 (PCM)Channels:7Freq:0x7F (32-192)B2:0x07 (16-24b)
Format: 2 (AC3)Channels:7Freq:0x07 (32-48)B2:0x50 (640?)
Format: 7 (DTS)Channels:7Freq:0x06 (44-48)B2:0xC0 (1536?)
Format: 10 (EAC3)Channels:7Freq:0x06 (44-48)B2:0x00
Format: 11 (DTS_HD)Channels:7Freq:0x7E (44-192)B2:0x01
Format: 12 (MLP)Channels:7Freq:0x1E (44-96)B2:0x00

Unfortunately I get only 1 emulated SAD entry for PCM
(/proc/asound/card1/eld#0.0):
sad0_coding_type[0x1] LPCM
sad0_channels   2
sad0_rates  [0x1ee0] 32000 44100 48000 88200 96000 176400 192000
sad0_bits   [0xe] 16 20 24

So I can not play 8 channel LPCM "legally" (without forcing player to do so).


> Fix the code to pick the PCM SAD with the highest number of channels,
> while merging the rate masks of PCM SADs with lower amount of channels
> into the additional stereo rate mask byte.

Does it mean that now instead of 2 real SADs:
1) 192kHz support for 2 channels
2) 96kHz support for 8 channels
you will only get:
1) 192kHz support for 8 channels
?
Does it mean alsa may try to play 8channels audio at 192kHz and fail at this?
That doesn't sound good, but on the other hand I can't propose
anything better :|
Out of curiosity, what does fglrx set in the verbs?


> Technically there are even more cases to handle (multiple non-PCM SADs
> of the same type, more than two PCM SADs with varying channel counts,
> etc), but those have not actually been encountered in the field and
> handling them would be non-trivial.
>
> Example affected EDID from Onkyo TX-SR674 specifying 192kHz stereo
> support and 96kHz 8-channel support (and other 8-channel compressed
> formats):

-- 
Rafa?

[PATCH] drm/radeon/audio: don't set speaker allocation on DCE4+

[Rafał Miłecki]

2013/10/28 Deucher, Alexander :
>> -Original Message-
>> From: Rafa? Mi?ecki [mailto:zajec5 at gmail.com]
>> Sent: Monday, October 28, 2013 5:24 AM
>> To: Alex Deucher
>> Cc: dri-devel; Deucher, Alexander
>> Subject: Re: [PATCH] drm/radeon/audio: don't set speaker allocation on
>> DCE4+
>>
>> 2013/10/19 Alex Deucher :
>> > It causes hangs on some asics.  Disable on DCE6+ as well
>> > just to be on the safe side.
>>
>> Did you get any reports about that? Or is that based only on mine comment:
>
> Yes, I had some reports of hangs on newer chips for some people as well.  I'm 
> not sure if it was directly correlated, but seemed like the safe thing to at 
> this point in the kernel cycle.

Too bad :( I'll see what I can reproduce with my cards.

-- 
Rafa?

[PATCH] drm/radeon/audio: don't set speaker allocation on DCE4+

[Rafał Miłecki]

2013/10/19 Alex Deucher :
> It causes hangs on some asics.  Disable on DCE6+ as well
> just to be on the safe side.

Did you get any reports about that? Or is that based only on mine comment:

> I noticed some hangs on BARTS too, let me test this solution on DCE5.
> Maybe it's not just DCE3.2.

(After some testing that hangs were not likely related to the HDMI/audio stuff).

[PATCH 1/2] drm/radeon/audio: don't set speaker allocation on DCE3.2

[Rafał Miłecki]

2013/10/17 Alex Deucher :
> It causes hangs on some asics.
>
> Bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=70439

I noticed some hangs on BARTS too, let me test this solution on DCE5.
Maybe it's not just DCE3.2.

[PATCH 2/2] drm/radeon: rework audio option

[Rafał Miłecki]

2013/10/17 Alex Deucher :
> In 3.12 I changed audio to be enabled by default,
> but you still had to turn it on via xrandr.  This
> was confusing to users so change it to minic the
> previous behavior:
>
> - audio option is set to -1 (auto) by default which is
>   the current 3.12 behavior (audio is enabled but requires
>   xrandr to turn it on.
> - if audio = 1, the audio is enabled without needing
>   to mess with xrandr (previous behavior)
> - audio = 0 disables audio

I like this!

Re: [RFC][PATCH] drm/radeon: put DCE4 audio init/fini in evergreen_hdmi.c

[Rafał Miłecki]

2013/10/13 Alex Deucher :
> On Sun, Oct 13, 2013 at 12:26 PM, Rafał Miłecki  wrote:
>> That allow us to use registers defined in evergreend.h.
>> ---
>> This is another proposal for HDMI code improvment. I'll start testing
>> my patches soon, so I hope to re-send all of them in the following days.
>
> Might be worth adding audio_init/fini callbacks the radeon_asic struct
> like we dis for hdmi_enable and hdmi_setmode.

Good idea, thanks.

> Might also be worth
> changing the hdmi_enable and hdmi_setmode callbacks to afmt_enable and
> afmt_setmode in preparation DP audio support.  Either way, patch looks
> good to me.

It's a bit too early for me, I'm not sure what part of code can be
shared between HDMI and DP. On the other hand, I want to clean
DCE2/3.0/3.2 code too, I'm in progress to collecting the hardware.

Too bad DP monitors/TVs are still so uncommon. Maybe I'll just buy an
active DP to HDMI adapter, I think it should make the trick.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC][PATCH] drm/radeon: put DCE4 audio init/fini in evergreen_hdmi.c

[Rafał Miłecki]

That allow us to use registers defined in evergreend.h.
---
This is another proposal for HDMI code improvment. I'll start testing
my patches soon, so I hope to re-send all of them in the following days.
---
 drivers/gpu/drm/radeon/evergreen.c  |4 +--
 drivers/gpu/drm/radeon/evergreen_hdmi.c |   56 +++
 drivers/gpu/drm/radeon/r600_audio.c |   15 ++---
 drivers/gpu/drm/radeon/radeon_asic.h|4 +++
 4 files changed, 65 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 52fa3be..68a5200 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -5246,7 +5246,7 @@ static int evergreen_startup(struct radeon_device *rdev)
return r;
}
 
-   r = r600_audio_init(rdev);
+   r = dce4_audio_init(rdev);
if (r) {
DRM_ERROR("radeon: audio init failed\n");
return r;
@@ -5288,7 +5288,7 @@ int evergreen_resume(struct radeon_device *rdev)
 
 int evergreen_suspend(struct radeon_device *rdev)
 {
-   r600_audio_fini(rdev);
+   dce4_audio_fini(rdev);
uvd_v1_0_fini(rdev);
radeon_uvd_suspend(rdev);
r700_cp_stop(rdev);
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 9153b24..98b420e 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -403,3 +403,59 @@ void evergreen_hdmi_enable(struct drm_encoder *encoder, 
bool enable)
DRM_DEBUG("%sabling HDMI interface @ 0x%04X for encoder 0x%x\n",
  enable ? "En" : "Dis", dig->afmt->offset, 
radeon_encoder->encoder_id);
 }
+
+static void dce4_audio_enable(struct radeon_device *rdev,
+ struct r600_audio_pin *pin,
+ bool enable)
+{
+   static u32 ctl_bits = PIN0_AUDIO_ENABLED |
+ PIN1_AUDIO_ENABLED |
+ PIN2_AUDIO_ENABLED |
+ PIN3_AUDIO_ENABLED |
+ AUDIO_ENABLED;
+   u32 tmp;
+
+   tmp = RREG32(AZ_HOT_PLUG_CONTROL);
+   if (enable) {
+   tmp |= ctl_bits;
+   WREG32_P(0x5e80, 0x1, ~0x03ff);
+   } else {
+   tmp &= ~ctl_bits;
+   }
+   WREG32(AZ_HOT_PLUG_CONTROL, tmp);
+
+   DRM_INFO("%s audio %d support\n", enable ? "Enabling" : "Disabling", 
pin->id);
+}
+
+int dce4_audio_init(struct radeon_device *rdev)
+{
+   if (!radeon_audio || ASIC_IS_NODCE(rdev))
+   return 0;
+
+   rdev->audio.enabled = true;
+
+   rdev->audio.num_pins = 1;
+   rdev->audio.pin[0].channels = -1;
+   rdev->audio.pin[0].rate = -1;
+   rdev->audio.pin[0].bits_per_sample = -1;
+   rdev->audio.pin[0].status_bits = 0;
+   rdev->audio.pin[0].category_code = 0;
+   rdev->audio.pin[0].id = 0;
+
+   dce4_audio_enable(rdev, &rdev->audio.pin[0], true);
+
+   return 0;
+}
+
+void dce4_audio_fini(struct radeon_device *rdev)
+{
+   int i;
+
+   if (!rdev->audio.enabled)
+   return;
+
+   for (i = 0; i < rdev->audio.num_pins; i++)
+   dce4_audio_enable(rdev, &rdev->audio.pin[i], false);
+
+   rdev->audio.enabled = false;
+}
diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
b/drivers/gpu/drm/radeon/r600_audio.c
index 47fc2b8..1511cc5 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -146,18 +146,9 @@ static void r600_audio_enable(struct radeon_device *rdev,
  struct r600_audio_pin *pin,
  bool enable)
 {
-   u32 value = 0;
-
-   if (ASIC_IS_DCE4(rdev)) {
-   if (enable) {
-   value |= 0x8100; /* Required to enable audio */
-   value |= 0x0e1000f0; /* fglrx sets that too */
-   }
-   WREG32(EVERGREEN_AUDIO_ENABLE, value);
-   } else {
-   WREG32_P(R600_AUDIO_ENABLE,
-enable ? 0x8100 : 0x0, ~0x8100);
-   }
+   WREG32_P(R600_AUDIO_ENABLE,
+enable ? 0x8100 : 0x0, ~0x8100);
+
DRM_INFO("%s audio %d support\n", enable ? "Enabling" : "Disabling", 
pin->id);
 }
 
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 86d871b..5cf52c0 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -469,6 +469,10 @@ int rv770_dpm_force_performance_level(struct radeon_device 
*rdev,
  enum radeon_dpm_forced_level level);
 bool rv770_dpm_vblank_too_short(struct radeon_device *rdev);
 
+/* DCE4 */
+int dce4_audio_init(struct radeon_device *rdev);
+void dce4_audio_fini(struct radeon_device *rdev);
+
 /*
  * evergreen
  */
-- 
1.7.10.4

___

Re: [pull] radeon drm-fixes-3.12

[Rafał Miłecki]

2013/10/10 Alex Deucher :
> Attached.  I'll send an updated pull request with the patch added.

Thanks! I promise to work on that, it just takes time to gather so old
hardware and run it (especially fglrx).

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] radeon drm-fixes-3.12

[Rafał Miłecki]

2013/10/10 Alex Deucher :
> On Thu, Oct 10, 2013 at 1:39 AM, Rafał Miłecki  wrote:
>> 2013/10/10 Alex Deucher :
>>>   drm/radeon: use hw generated CTS/N values for audio
>>
>> I'd like to see such patches earlier :| I'm OK with the change for
>> DCE4+ (Evergreen) (I even suggested that change myself recently), but
>> I didn't have time to check how this should be programmed on
>> DCE2/3/4...
>>
>> In your patch 0001-WIP-port-of-hdmi-dp-audio-code-to-newer-kernel.patch
>> based on (AFAIU) internal specs you were setting HDMI_ACR_SOURCE.
>>
>> According to the Christian R6xx may really have some bug for
>> generating values by the hw, see:
>> https://bugs.freedesktop.org/show_bug.cgi?id=69675#c12
>>
>> So it doesn't look like a good patch for -fixes, especially without
>> testing it on some hardware.
>
> Yeah, I thought about that, but on the other hand, there is already a
> regression caused by the 1001 modes patches that this series fixes.  I
> can add a patch to disable the hw generated values on older families
> for now if you'd prefer.

It would be nice. I'm working on getting some old GPUs, tracing fglrx
and testing. So I hope to get HDMI support on DCE2/3 cleaned soon.

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] radeon drm-fixes-3.12

[Rafał Miłecki]

2013/10/10 Alex Deucher :
>   drm/radeon: use hw generated CTS/N values for audio

I'd like to see such patches earlier :| I'm OK with the change for
DCE4+ (Evergreen) (I even suggested that change myself recently), but
I didn't have time to check how this should be programmed on
DCE2/3/4...

In your patch 0001-WIP-port-of-hdmi-dp-audio-code-to-newer-kernel.patch
based on (AFAIU) internal specs you were setting HDMI_ACR_SOURCE.

According to the Christian R6xx may really have some bug for
generating values by the hw, see:
https://bugs.freedesktop.org/show_bug.cgi?id=69675#c12

So it doesn't look like a good patch for -fixes, especially without
testing it on some hardware.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH 1/2] drm/radeon: remove unneeded HDMI r/w ops on DCE4+

[Rafał Miłecki]

2013/10/7 Alex Deucher :
> On Sun, Oct 6, 2013 at 4:46 PM, Rafał Miłecki  wrote:
>> Write to HDMI_VBI_PACKET_CONTROL was duplicated.
>> Writes to AFMT_AUDIO_CRC_CONTROL and AFMT_RAMP_CONTROL[0-3] came from
>> DCE2/3 code (copy & paste) and were never needed on DCE4+.
>>
>> See https://bugzilla.kernel.org/show_bug.cgi?id=62591 for details.
>
> I think in general it would be better to do a read/modify/write
> sequences for all hdmi register updates rather than just writing.
> That's generally what the hw team recommends and what the catalyst
> driver does.

See my patch 3/2 for that :) I agree with you.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [TIP] Catalyst / fglrx and DVI to HDMI adapters (audio)

[Rafał Miłecki]

2013/10/7 Christian König :
> Why didn't you just asked me?

I was told on #radeon you're on holidays ;) I was trying to catch you.

> I've figured this out over five years ago by applying brute force to one of
> the "magic" DVI->HDMI adapters that came with my original RV635. And it
> indeed contains an extra EEPROM on the I2C bus ;)

Did you find any way to workaround this? So I can use my generic
adapter with fglrx for audio?

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[TIP] Catalyst / fglrx and DVI to HDMI adapters (audio)

[Rafał Miłecki]

For the last few days it was I was testing fglrx on various cards to
trace HDMI setup. One thing that was killing me was no HDMI audio when
using some generic/cheap DVI to HDMI adapter with my HD 4850.

I started digging and it has appeared to be common problem when using
Catalyst / fglrx. Windows users were also experiencing this problem,
without any known workaround.

I've found one explanation by droidhacker:
http://phoronix.com/forums/showthread.php?23451-HDMI-Audio-with-fglrx&p=124891#post124891
> If that is the case, you need to be aware that AMD sells a couple of 
> PROPRIETARY adapter plugs, which fglrx can DETECT in order to decide whether 
> or not to enable HDMI audio.

That sounded weird, I didn't believe that. There wasn't any
explanation how it's handled, I couldn't imagine how fglrx can "talk"
to the simple adapter. Overall it should just map the PINs, not
include any logic!

But today I've found another discussion:
http://www.avsforum.com/t/1080627/atis-magic-dvi-to-hdmi-dongle

That finally explains what is happening. So it appears that ATI's
proprietary adapter include some tiny I2C protocol that allows
identifying them! It seems that Catalyst / fglrx uses some simple I2C
talk to check if the adapter is made by ATI and allows or refuses to
use HDMI mode.
That also explains why radeon driver never had any problems with audio
over DVI, no matter what adapter was used.

Another ATI/fgllx mystery explained ;)

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC][PATCH 3/2] drm/radeon: use masks when doing DCE4+ HDMI R/W ops

[Rafał Miłecki]

Recent RE with faking reading values allowed us to figure out correct
masks for all R/W ops. Use them following fglrx logic.

See https://bugzilla.kernel.org/show_bug.cgi?id=62591 for details.
---
That patches weren't tested with the HW, please don't apply them yet.
---
 drivers/gpu/drm/radeon/evergreen_hdmi.c |   78 +++
 drivers/gpu/drm/radeon/evergreend.h |   12 +
 2 files changed, 59 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 51b643d..1f6e332 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -48,14 +48,20 @@ static void evergreen_hdmi_update_ACR(struct drm_encoder 
*encoder, uint32_t cloc
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t offset = dig->afmt->offset;
 
-   WREG32(HDMI_ACR_32_0 + offset, HDMI_ACR_CTS_32(acr.cts_32khz));
-   WREG32(HDMI_ACR_32_1 + offset, acr.n_32khz);
-
-   WREG32(HDMI_ACR_44_0 + offset, HDMI_ACR_CTS_44(acr.cts_44_1khz));
-   WREG32(HDMI_ACR_44_1 + offset, acr.n_44_1khz);
-
-   WREG32(HDMI_ACR_48_0 + offset, HDMI_ACR_CTS_48(acr.cts_48khz));
-   WREG32(HDMI_ACR_48_1 + offset, acr.n_48khz);
+   WREG32_P(HDMI_ACR_32_0 + offset, HDMI_ACR_CTS_32(acr.cts_32khz),
+~HDMI_ACR_CTS_32_MASK);
+   WREG32_P(HDMI_ACR_32_1 + offset, HDMI_ACR_N_32(acr.n_32khz),
+~HDMI_ACR_N_32_MASK);
+
+   WREG32_P(HDMI_ACR_44_0 + offset, HDMI_ACR_CTS_44(acr.cts_44_1khz),
+~HDMI_ACR_CTS_44_MASK);
+   WREG32_P(HDMI_ACR_44_1 + offset, HDMI_ACR_N_44(acr.n_44_1khz),
+~HDMI_ACR_N_44_MASK);
+
+   WREG32_P(HDMI_ACR_48_0 + offset, HDMI_ACR_CTS_48(acr.cts_48khz),
+~HDMI_ACR_CTS_48_MASK);
+   WREG32_P(HDMI_ACR_48_1 + offset, HDMI_ACR_N_48(acr.n_48khz),
+~HDMI_ACR_N_48_MASK);
 }
 
 static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
@@ -258,10 +264,11 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
 
evergreen_audio_set_dto(encoder, mode->clock);
 
-   WREG32(HDMI_VBI_PACKET_CONTROL + offset,
-  HDMI_NULL_SEND | /* send null packets when required */
-  HDMI_GC_SEND | /* send general control packets */
-  HDMI_GC_CONT); /* send general control packets every frame */
+   WREG32_P(HDMI_VBI_PACKET_CONTROL + offset,
+HDMI_NULL_SEND | /* send null packets when required */
+HDMI_GC_SEND | /* send general control packets */
+HDMI_GC_CONT, /* send general control packets every frame */
+~(HDMI_NULL_SEND | HDMI_GC_SEND | HDMI_GC_CONT | BIT(12)));
 
WREG32(HDMI_INFOFRAME_CONTROL0 + offset,
   HDMI_AUDIO_INFO_SEND | /* enable audio info frames (frames won't 
be set until audio is enabled) */
@@ -270,14 +277,17 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
WREG32(AFMT_INFOFRAME_CONTROL0 + offset,
   AFMT_AUDIO_INFO_UPDATE); /* required for audio info values to be 
updated */
 
-   WREG32(HDMI_INFOFRAME_CONTROL1 + offset,
-  HDMI_AUDIO_INFO_LINE(2)); /* anything other than 0 */
+   WREG32_P(HDMI_INFOFRAME_CONTROL1 + offset,
+HDMI_AUDIO_INFO_LINE(2), /* anything other than 0 */
+~HDMI_AUDIO_INFO_LINE_MASK);
 
-   WREG32(HDMI_GC + offset, 0); /* unset HDMI_GC_AVMUTE */
+   WREG32_AND(HDMI_GC + offset, ~HDMI_GC_AVMUTE); /* unset HDMI_GC_AVMUTE 
*/
 
-   WREG32(HDMI_AUDIO_PACKET_CONTROL + offset,
-  HDMI_AUDIO_DELAY_EN(1) | /* set the default audio delay */
-  HDMI_AUDIO_PACKETS_PER_LINE(3)); /* should be suffient for all 
audio modes and small enough for all hblanks */
+   WREG32_P(HDMI_AUDIO_PACKET_CONTROL + offset,
+HDMI_AUDIO_DELAY_EN(1) | /* set the default audio delay */
+HDMI_AUDIO_PACKETS_PER_LINE(3), /* should be suffient for all 
audio modes and small enough for all hblanks */
+~(HDMI_AUDIO_DELAY_EN_MASK |
+  HDMI_AUDIO_PACKETS_PER_LINE_MASK));
 
WREG32(AFMT_AUDIO_PACKET_CONTROL + offset,
   AFMT_60958_CS_UPDATE); /* allow 60958 channel status fields to 
be updated */
@@ -285,25 +295,31 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
WREG32_AND(AFMT_AUDIO_PACKET_CONTROL2,
   ~(AFMT_AUDIO_LAYOUT_OVRD | AFMT_60958_CS_SOURCE));
 
+   /* TODO: do we need HDMI_ACR_SOURCE? */
WREG32(HDMI_ACR_PACKET_CONTROL + offset,
   HDMI_ACR_AUTO_SEND | /* allow hw to sent ACR packets when 
required */
   HDMI_ACR_SOURCE); /* select SW CTS value */
 
evergreen_hdmi_update_ACR(encoder, mode->clock);
 
-   WREG32(AFMT_60958_0 + offset,
-  AFMT_60958

[RFC][PATCH 2/2] drm/radeon: add missing writes for DCE4+ HDMI mode

[Rafał Miłecki]

They were verified to be used by fglrx on PALM, BARTS, CAICOS and VERDE.
VERDE which is DCE6 seems to need also clearing 0x7138 register.

See https://bugzilla.kernel.org/show_bug.cgi?id=62591 for details.
---
That patches weren't tested with the HW, please don't apply them yet.
---
 drivers/gpu/drm/radeon/dce6_afmt.c  |   10 ++
 drivers/gpu/drm/radeon/evergreen_hdmi.c |   20 +++-
 drivers/gpu/drm/radeon/evergreend.h |3 +++
 3 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c 
b/drivers/gpu/drm/radeon/dce6_afmt.c
index 85a69d2..cb4eb3a 100644
--- a/drivers/gpu/drm/radeon/dce6_afmt.c
+++ b/drivers/gpu/drm/radeon/dce6_afmt.c
@@ -56,6 +56,14 @@ static void dce6_endpoint_wreg(struct radeon_device *rdev,
 
 #define RREG32_ENDPOINT(block, reg) dce6_endpoint_rreg(rdev, (block), (reg))
 #define WREG32_ENDPOINT(block, reg, v) dce6_endpoint_wreg(rdev, (block), 
(reg), (v))
+#define WREG32_ENDPOINT_P(block, reg, val, mask)   \
+   do {\
+   uint32_t tmp_ = RREG32_ENDPOINT(block, reg);\
+   tmp_ &= (mask); \
+   tmp_ |= ((val) & ~(mask));  \
+   WREG32_ENDPOINT(block, reg, tmp_);  \
+   } while (0)
+#define WREG32_ENDPOINT_OR(block, reg, or) WREG32_ENDPOINT_P(block, reg, or, 
~(or))
 
 
 static void dce6_afmt_get_connected_pins(struct radeon_device *rdev)
@@ -196,6 +204,8 @@ void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
}
BUG_ON(!sads);
 
+   WREG32_ENDPOINT_OR(offset, 0x25, 0x40);
+
for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
u32 value = 0;
int j;
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 50f6299..2935161 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -137,6 +137,8 @@ static void evergreen_hdmi_write_sad_regs(struct 
drm_encoder *encoder)
}
BUG_ON(!sads);
 
+   WREG32_OR(0x5f80, 0x40);
+
for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
u32 value = 0;
int j;
@@ -280,7 +282,8 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
WREG32(AFMT_AUDIO_PACKET_CONTROL + offset,
   AFMT_60958_CS_UPDATE); /* allow 60958 channel status fields to 
be updated */
 
-   /* fglrx clears sth in AFMT_AUDIO_PACKET_CONTROL2 here */
+   WREG32_AND(AFMT_AUDIO_PACKET_CONTROL2,
+  ~(AFMT_AUDIO_LAYOUT_OVRD | AFMT_60958_CS_SOURCE));
 
WREG32(HDMI_ACR_PACKET_CONTROL + offset,
   HDMI_ACR_AUTO_SEND | /* allow hw to sent ACR packets when 
required */
@@ -302,16 +305,18 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
   AFMT_60958_CS_CHANNEL_NUMBER_6(7) |
   AFMT_60958_CS_CHANNEL_NUMBER_7(8));
 
+   if (ASIC_IS_DCE6(rdev))
+   WREG32(0x7138 + offset, 0);
+
if (ASIC_IS_DCE6(rdev)) {
dce6_afmt_write_speaker_allocation(encoder);
} else {
dce4_afmt_write_speaker_allocation(encoder);
}
 
-   WREG32(AFMT_AUDIO_PACKET_CONTROL2 + offset,
-  AFMT_AUDIO_CHANNEL_ENABLE(0xff));
-
-   /* fglrx sets 0x40 in 0x5f80 here */
+   WREG32_P(AFMT_AUDIO_PACKET_CONTROL2 + offset,
+AFMT_AUDIO_CHANNEL_ENABLE(0xff),
+~AFMT_AUDIO_CHANNEL_MASK);
 
if (ASIC_IS_DCE6(rdev)) {
dce6_afmt_select_pin(encoder);
@@ -342,6 +347,11 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
 HDMI_AVI_INFO_LINE(2), /* anything other than 0 */
 ~HDMI_AVI_INFO_LINE_MASK);
 
+   WREG32_AND(HDMI_GENERIC_PACKET_CONTROL + offset,
+  ~(HDMI_GENERIC0_SEND | HDMI_GENERIC0_CONT | 
HDMI_GENERIC0_MASK));
+   WREG32_AND(HDMI_GENERIC_PACKET_CONTROL + offset,
+  ~(HDMI_GENERIC1_SEND | HDMI_GENERIC1_CONT | 
HDMI_GENERIC1_MASK));
+
WREG32_OR(AFMT_AUDIO_PACKET_CONTROL + offset,
  AFMT_AUDIO_SAMPLE_SEND); /* send audio packets */
 }
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index 8768fd6..5724ae5 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -561,7 +561,9 @@
 #   define HDMI_GENERIC1_SEND(1 << 4)
 #   define HDMI_GENERIC1_CONT(1 << 5)
 #   define HDMI_GENERIC0_LINE(x) (((x) & 0x3f) << 16)
+#   define HDMI_GENERIC0_MASK(0x3f << 16)
 #   define HDMI_GENERIC1_LINE(x) (((x) & 0x3f) << 24)
+#   define HDMI_GENERIC1_MASK(0x3f << 24)
 #define HDMI_GC  0x7058
 # 

[RFC][PATCH 1/2] drm/radeon: remove unneeded HDMI r/w ops on DCE4+

[Rafał Miłecki]

Write to HDMI_VBI_PACKET_CONTROL was duplicated.
Writes to AFMT_AUDIO_CRC_CONTROL and AFMT_RAMP_CONTROL[0-3] came from
DCE2/3 code (copy & paste) and were never needed on DCE4+.

See https://bugzilla.kernel.org/show_bug.cgi?id=62591 for details.
---
That patches weren't tested with the HW, please don't apply them yet.
---
 drivers/gpu/drm/radeon/evergreen_hdmi.c |   11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index f71ce39..50f6299 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -257,11 +257,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
evergreen_audio_set_dto(encoder, mode->clock);
 
WREG32(HDMI_VBI_PACKET_CONTROL + offset,
-  HDMI_NULL_SEND); /* send null packets when required */
-
-   WREG32(AFMT_AUDIO_CRC_CONTROL + offset, 0x1000);
-
-   WREG32(HDMI_VBI_PACKET_CONTROL + offset,
   HDMI_NULL_SEND | /* send null packets when required */
   HDMI_GC_SEND | /* send general control packets */
   HDMI_GC_CONT); /* send general control packets every frame */
@@ -349,12 +344,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
 
WREG32_OR(AFMT_AUDIO_PACKET_CONTROL + offset,
  AFMT_AUDIO_SAMPLE_SEND); /* send audio packets */
-
-   /* it's unknown what these bits do excatly, but it's indeed quite 
useful for debugging */
-   WREG32(AFMT_RAMP_CONTROL0 + offset, 0x00FF);
-   WREG32(AFMT_RAMP_CONTROL1 + offset, 0x007F);
-   WREG32(AFMT_RAMP_CONTROL2 + offset, 0x0001);
-   WREG32(AFMT_RAMP_CONTROL3 + offset, 0x0001);
 }
 
 void evergreen_hdmi_enable(struct drm_encoder *encoder, bool enable)
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Looking for a RV710 / RV730 / RV740 user with HDMI TV

[Rafał Miłecki]

Hi guys,

I wanted to verify/improve HDMI (audio) implementation in radeon for
so-called DCE3.2 cards. To achieve that I need a log from fglrx.

Is there anyone around using RV710 / RV730 / RV740 who can install
fglrx for one day and do few simple tests for me?

In case you don't know chipsets:
RV710: HD4350, HD4550, HD4570
RV730: HD4650, HD4670
RV740: HD4750, HD4770, Mobility HD4830, Mobility HD4870

Please note that above cards are supported by fglrx legacy only, which
means you have to use Xorg server 1.12 or older (1.13 is not supported
by fglrx legacy).

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/51] DMA mask changes

[Rafał Miłecki]

2013/9/19 Russell King - ARM Linux :
> This email is only being sent to the mailing lists in question, not to
> anyone personally.  The list of individuals is far to great to do that.
> I'm hoping no mailing lists reject the patches based on the number of
> recipients.

Huh, I think it was enough to send only 3 patches to the b43-dev@. Like:
[PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
[PATCH 14/51] DMA-API: net: b43: (...)
[PATCH 15/51] DMA-API: net: b43legacy: (...)
;)

I believe Joe has some nice script for doing it that way. When fixing
some coding style / formatting, he sends only related patches to the
given ML.

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

no hdmi sound on hd5450

[Rafał Miłecki]

2013/8/18 StompDagger1 at yahoo.com :
> 2013/8/18 StompDagger1 at yahoo.com :
>>> does the following patch: "[FIX][PATCH] drm/radeon: fix WREG32_OR macro
>>> setting bits in a register" which you've commited fixes my issue?
>
>>Yes, I believe so! Sorry, I forgot to ping you about that.
>
> thats ok, I've applied the patch it doesn't seems to work, I'll verify later
> today when I'll get home.
>
> also, does screen flickering is part of this bug?

Please create a bug report, and stop using HTML in your e-mail all the time.

Provide output of "avivotool regs hdmi" in your bug report.

-- 
Rafa?

no hdmi sound on hd5450

[Rafał Miłecki]

2013/8/18 StompDagger1 at yahoo.com :
> does the following patch: "[FIX][PATCH] drm/radeon: fix WREG32_OR macro
> setting bits in a register" which you've commited fixes my issue?

Yes, I believe so! Sorry, I forgot to ping you about that.

-- 
Rafa?

Re: no hdmi sound on hd5450

[Rafał Miłecki]

2013/8/18 stompdagg...@yahoo.com :
> 2013/8/18 stompdagg...@yahoo.com :
>>> does the following patch: "[FIX][PATCH] drm/radeon: fix WREG32_OR macro
>>> setting bits in a register" which you've commited fixes my issue?
>
>>Yes, I believe so! Sorry, I forgot to ping you about that.
>
> thats ok, I've applied the patch it doesn't seems to work, I'll verify later
> today when I'll get home.
>
> also, does screen flickering is part of this bug?

Please create a bug report, and stop using HTML in your e-mail all the time.

Provide output of "avivotool regs hdmi" in your bug report.

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: no hdmi sound on hd5450

[Rafał Miłecki]

2013/8/18 stompdagg...@yahoo.com :
> does the following patch: "[FIX][PATCH] drm/radeon: fix WREG32_OR macro
> setting bits in a register" which you've commited fixes my issue?

Yes, I believe so! Sorry, I forgot to ping you about that.

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[FIX][PATCH] drm/radeon: fix WREG32_OR macro setting bits in a register

[Rafał Miłecki]

This bug (introduced in 3.10) in WREG32_OR made
commit d3418eacad403033e95e49dc14afa37c2112c134
"drm/radeon/evergreen: setup HDMI before enabling it"
cause a regression. Sometimes audio over HDMI wasn't working, sometimes
display was corrupted.

This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60687
https://bugzilla.kernel.org/show_bug.cgi?id=60709
https://bugs.freedesktop.org/show_bug.cgi?id=67767

Signed-off-by: Rafa? Mi?ecki 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9fc9e71..289047e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2259,7 +2259,7 @@ void cik_mm_wdoorbell(struct radeon_device *rdev, u32 
offset, u32 v);
WREG32(reg, tmp_);  \
} while (0)
 #define WREG32_AND(reg, and) WREG32_P(reg, 0, and)
-#define WREG32_OR(reg, or) WREG32_P(reg, or, ~or)
+#define WREG32_OR(reg, or) WREG32_P(reg, or, ~(or))
 #define WREG32_PLL_P(reg, val, mask)   \
do {\
uint32_t tmp_ = RREG32_PLL(reg);\
-- 
1.7.10.4

[PATCH 5/5] drm/radeon: set speaker allocation for DCE4/5

[Rafał Miłecki]

2013/8/15 Rafa? Mi?ecki :
> 2013/8/15 Alex Deucher :
>> +static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
>> +{
>> +   struct radeon_device *rdev = encoder->dev->dev_private;
>> +   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
>> +   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>> +   struct drm_connector *connector;
>> +   struct radeon_connector *radeon_connector = NULL;
>> +   u32 offset, tmp;
>> +   u8 *sadb;
>> +   int sad_count;
>> +
>> +   if (!dig->afmt->pin)
>> +   return;
>> +
>> +   offset = dig->afmt->pin->offset;
>
> You don't want that (offset) :)

After that trivial fix
Acked-by: Rafa? Mi?ecki 

-- 
Rafa?

[PATCH 1/5] drm/edid: add a helper function to extract the speaker allocation data block (v3)

[Rafał Miłecki]

2013/8/15 Alex Deucher :
> This adds a helper function to extract the speaker allocation
> data block from the EDID.  This data block describes what speakers
> are present on the display device.
>
> v2: update per Ville Syrj?l?'s comments
> v3: fix copy/paste typo in memory allocation
>
> Signed-off-by: Alex Deucher 
> Reviewed-by: Ville Syrj?l? 

Tested-by: Rafa? Mi?ecki 

[PATCH 3/5] drm/radeon: add audio support for DCE6/8 GPUs (v11)

[Rafał Miłecki]

> @@ -169,13 +169,17 @@ int r600_audio_init(struct radeon_device *rdev)
> if (!radeon_audio || !r600_audio_chipset_supported(rdev))
> return 0;
>
> -   r600_audio_engine_enable(rdev, true);
> +   rdev->audio.enabled = true;
> +
> +   rdev->audio.num_pins = 1;
> +   rdev->audio.pin[0].channels = -1;
> +   rdev->audio.pin[0].rate = -1;
> +   rdev->audio.pin[0].bits_per_sample = -1;
> +   rdev->audio.pin[0].status_bits = 0;
> +   rdev->audio.pin[0].category_code = 0;
> +   rdev->audio.pin[0].id = 0;
>
> -   rdev->audio_status.channels = -1;
> -   rdev->audio_status.rate = -1;
> -   rdev->audio_status.bits_per_sample = -1;
> -   rdev->audio_status.status_bits = 0;
> -   rdev->audio_status.category_code = 0;
> +   r600_audio_enable(rdev, &rdev->audio.pin[0], false);

I was really wondering why my audio was *DISABLED* during init :P Fix
this regression please ;)

[PATCH 5/5] drm/radeon: set speaker allocation for DCE4/5

[Rafał Miłecki]

2013/8/15 Alex Deucher :
> +static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
> +{
> +   struct radeon_device *rdev = encoder->dev->dev_private;
> +   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> +   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
> +   struct drm_connector *connector;
> +   struct radeon_connector *radeon_connector = NULL;
> +   u32 offset, tmp;
> +   u8 *sadb;
> +   int sad_count;
> +
> +   if (!dig->afmt->pin)
> +   return;
> +
> +   offset = dig->afmt->pin->offset;

You don't want that (offset) :)

[PATCH] drm/radeon: set speakers allocation earlier

[Rafał Miłecki]

Do it before enabling audio channels (in AFMT_AUDIO_PACKET_CONTROL2
register).

Signed-off-by: Rafa? Mi?ecki 
---
 drivers/gpu/drm/radeon/dce6_afmt.c  |   69 +--
 drivers/gpu/drm/radeon/evergreen_hdmi.c |7 +++-
 2 files changed, 54 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c 
b/drivers/gpu/drm/radeon/dce6_afmt.c
index 630df96..34392ec 100644
--- a/drivers/gpu/drm/radeon/dce6_afmt.c
+++ b/drivers/gpu/drm/radeon/dce6_afmt.c
@@ -94,17 +94,62 @@ void dce6_afmt_select_pin(struct drm_encoder *encoder)
WREG32(AFMT_AUDIO_SRC_CONTROL + offset, AFMT_AUDIO_SRC_SELECT(id));
 }

-void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
+void dce6_afmt_write_speaker_allocation(struct drm_encoder *encoder)
 {
struct radeon_device *rdev = encoder->dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
u32 offset, tmp;
+   u8 *sadb;
+   int sad_count;
+
+   if (!dig->afmt->pin)
+   return;
+
+   offset = dig->afmt->pin->offset;
+
+   list_for_each_entry(connector, 
&encoder->dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder)
+   radeon_connector = to_radeon_connector(connector);
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Couldn't find encoder's connector\n");
+   return;
+   }
+
+   sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
&sadb);
+   if (sad_count < 0) {
+   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sad_count);
+   return;
+   }
+
+   /* program the speaker allocation */
+   tmp = RREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER);
+   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
+   /* set HDMI mode */
+   tmp |= HDMI_CONNECTION;
+   if (sad_count)
+   tmp |= SPEAKER_ALLOCATION(sadb[0]);
+   else
+   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
+   WREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER, tmp);
+
+   kfree(sadb);
+}
+
+void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+   u32 offset;
struct drm_connector *connector;
struct radeon_connector *radeon_connector = NULL;
struct cea_sad *sads;
-   int i, sad_count, sadb_count;
-   u8 *sadb;
+   int i, sad_count;

static const u16 eld_reg_to_type[][2] = {
{ AZ_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0, 
HDMI_AUDIO_CODING_TYPE_PCM },
@@ -143,23 +188,6 @@ void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
}
BUG_ON(!sads);

-   sadb_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
&sadb);
-   if (sadb_count < 0) {
-   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sadb_count);
-   return;
-   }
-
-   /* program the speaker allocation */
-   tmp = RREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER);
-   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
-   /* set HDMI mode */
-   tmp |= HDMI_CONNECTION;
-   if (sadb_count)
-   tmp |= SPEAKER_ALLOCATION(sadb[0]);
-   else
-   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
-   WREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER, tmp);
-
for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
u32 value = 0;
int j;
@@ -180,7 +208,6 @@ void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
}

kfree(sads);
-   kfree(sadb);
 }

 static int dce6_audio_chipset_supported(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index c5acdf0..2cb0f90 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -32,6 +32,7 @@
 #include "evergreend.h"
 #include "atom.h"

+extern void dce6_afmt_write_speaker_allocation(struct drm_encoder *encoder);
 extern void dce6_afmt_write_sad_regs(struct drm_encoder *encoder);
 extern void dce6_afmt_select_pin(struct drm_encoder *encoder);

@@ -267,7 +268,11 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
   AFMT_60958_CS_CHANNEL_NUMBER_6(7) |
   AFMT_60958_CS_CHANNEL_NUMBER_7(8));

-   /* fglrx sets 0x0001005f | (x & 0x00fc) in 0x5f78 here */
+   if (ASIC_IS_DCE6(rdev)) {
+   dce6_afmt_write_

[PATCH 3/3] drm/radeon: add audio support for DCE6/8 GPUs (v10)

[Rafał Miłecki]

2013/8/14 Alex Deucher :
> +   /* program the speaker allocation */
> +   tmp = RREG32_ENDPOINT(offset, 
> AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER);
> +   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
> +   /* set HDMI mode */
> +   tmp |= HDMI_CONNECTION;
> +   if (sadb_count)
> +   tmp |= SPEAKER_ALLOCATION(sadb[0]);
> +   else
> +   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
> +   WREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER, tmp);
> +
> +   for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> +   u32 value = 0;
> +   int j;
> +
> +   for (j = 0; j < sad_count; j++) {
> +   struct cea_sad *sad = &sads[j];
> +
> +   if (sad->format == eld_reg_to_type[i][1]) {
> +   value = MAX_CHANNELS(sad->channels) |
> +   DESCRIPTOR_BYTE_2(sad->byte2) |
> +   SUPPORTED_FREQUENCIES(sad->freq);
> +   if (sad->format == HDMI_AUDIO_CODING_TYPE_PCM)
> +   value |= 
> SUPPORTED_FREQUENCIES_STEREO(sad->freq);
> +   break;
> +   }
> +   }
> +   WREG32_ENDPOINT(offset, eld_reg_to_type[i][0], value);
> +   }

I hope this is my last questions I'm bothering you with... This is how
fglrx does that part:

WREG32(0x5e00, 0x0125);PIN_CONTROL_CHANNEL_SPEAKER
WREG32(0x5e04, 0x00c1005f);PIN_CONTROL_CHANNEL_SPEAKER

RREG32(0x000..05c); -> 0xAFMT_AUDIO_PACKET_CONTROL2
WREG32(0x000..05c, 0xff00);AFMT_AUDIO_PACKET_CONTROL2

WREG32(0x5e00, 0x0027);0x27 was 0x5f80 on Evergreen
RREG32(0x5e04); -> 0x0x27 was 0x5f80 on Evergreen

WREG32(0x5e00, 0x0127);0x27 was 0x5f80
WREG32(0x5e04, 0x0040);0x27 was 0x5f80

WREG32(0x5e00, 0x000c3128);DESCRIPTOR0
WREG32(0x5e04, 0x7f077f07);DESCRIPTOR0

The difference is that between setting PIN_CONTROL_CHANNEL_SPEAKER and
DESCRIPTOR0 fglrx enables audio channels (see
AFMT_AUDIO_PACKET_CONTROL2 and 0xff00).

Do you think it does matter? Or can we ignore the order and do it your way?

[PATCH 3/3] drm/radeon: add audio support for DCE6/8 GPUs (v10)

[Rafał Miłecki]

2013/8/14 Alex Deucher :
> Similar to DCE4/5, but supports multiple audio pins
> which can be assigned per afmt block.

Acked-by: Rafa? Mi?ecki 

Tested successfully on my HD7750.


> +static void r600_audio_enable(struct radeon_device *rdev,
> + struct r600_audio_pin *pin,
> + bool enable)
>  {
> u32 value = 0;
> -   DRM_INFO("%s audio support\n", enable ? "Enabling" : "Disabling");

Whoops, that confused me at the beginning. Don't you think it's nice
to know from somebody's dmesg if he uses radeon.audio or now? For
debugging purposes.


> +#define AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER  0x25
> +#defineSPEAKER_ALLOCATION(x)   (((x) & 0x7f) 
> << 0)
> +#defineSPEAKER_ALLOCATION_MASK (0x7f << 0)
> +#defineSPEAKER_ALLOCATION_SHIFT0
> +#defineHDMI_CONNECTION (1 << 16)
> +#defineDP_CONNECTION   (1 << 17)

Could you share a meaning of 0x00c0 bit? I noticed it's set when
fglrx reads this register:
WREG32(0x5e00, 0x0025);
RREG32(0x5e04); -> 0x00c0

WREG32(0x5e00, 0x0125);
WREG32(0x5e04, 0x00c1005f);

but it's not set with radeon reads it for the first time. Maybe fglrx
sets that at some other stage (earlier)?

-- 
Rafa?

[FIX][PATCH] drm/radeon: fix WREG32_OR macro setting bits in a register

[Rafał Miłecki]

This bug (introduced in 3.10) in WREG32_OR made
commit d3418eacad403033e95e49dc14afa37c2112c134
"drm/radeon/evergreen: setup HDMI before enabling it"
cause a regression. Sometimes audio over HDMI wasn't working, sometimes
display was corrupted.

This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60687
https://bugzilla.kernel.org/show_bug.cgi?id=60709
https://bugs.freedesktop.org/show_bug.cgi?id=67767

Signed-off-by: Rafał Miłecki 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9fc9e71..289047e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2259,7 +2259,7 @@ void cik_mm_wdoorbell(struct radeon_device *rdev, u32 
offset, u32 v);
WREG32(reg, tmp_);  \
} while (0)
 #define WREG32_AND(reg, and) WREG32_P(reg, 0, and)
-#define WREG32_OR(reg, or) WREG32_P(reg, or, ~or)
+#define WREG32_OR(reg, or) WREG32_P(reg, or, ~(or))
 #define WREG32_PLL_P(reg, val, mask)   \
do {\
uint32_t tmp_ = RREG32_PLL(reg);\
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/radeon: set speaker allocation for DCE4/5

[Rafał Miłecki]

2013/8/15 Rafał Miłecki :
> 2013/8/15 Alex Deucher :
>> +static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
>> +{
>> +   struct radeon_device *rdev = encoder->dev->dev_private;
>> +   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
>> +   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>> +   struct drm_connector *connector;
>> +   struct radeon_connector *radeon_connector = NULL;
>> +   u32 offset, tmp;
>> +   u8 *sadb;
>> +   int sad_count;
>> +
>> +   if (!dig->afmt->pin)
>> +   return;
>> +
>> +   offset = dig->afmt->pin->offset;
>
> You don't want that (offset) :)

After that trivial fix
Acked-by: Rafał Miłecki 

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/edid: add a helper function to extract the speaker allocation data block (v3)

[Rafał Miłecki]

2013/8/15 Alex Deucher :
> This adds a helper function to extract the speaker allocation
> data block from the EDID.  This data block describes what speakers
> are present on the display device.
>
> v2: update per Ville Syrjälä's comments
> v3: fix copy/paste typo in memory allocation
>
> Signed-off-by: Alex Deucher 
> Reviewed-by: Ville Syrjälä 

Tested-by: Rafał Miłecki 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] drm/radeon: add audio support for DCE6/8 GPUs (v11)

[Rafał Miłecki]

> @@ -169,13 +169,17 @@ int r600_audio_init(struct radeon_device *rdev)
> if (!radeon_audio || !r600_audio_chipset_supported(rdev))
> return 0;
>
> -   r600_audio_engine_enable(rdev, true);
> +   rdev->audio.enabled = true;
> +
> +   rdev->audio.num_pins = 1;
> +   rdev->audio.pin[0].channels = -1;
> +   rdev->audio.pin[0].rate = -1;
> +   rdev->audio.pin[0].bits_per_sample = -1;
> +   rdev->audio.pin[0].status_bits = 0;
> +   rdev->audio.pin[0].category_code = 0;
> +   rdev->audio.pin[0].id = 0;
>
> -   rdev->audio_status.channels = -1;
> -   rdev->audio_status.rate = -1;
> -   rdev->audio_status.bits_per_sample = -1;
> -   rdev->audio_status.status_bits = 0;
> -   rdev->audio_status.category_code = 0;
> +   r600_audio_enable(rdev, &rdev->audio.pin[0], false);

I was really wondering why my audio was *DISABLED* during init :P Fix
this regression please ;)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/radeon: set speaker allocation for DCE4/5

[Rafał Miłecki]

2013/8/15 Alex Deucher :
> +static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
> +{
> +   struct radeon_device *rdev = encoder->dev->dev_private;
> +   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> +   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
> +   struct drm_connector *connector;
> +   struct radeon_connector *radeon_connector = NULL;
> +   u32 offset, tmp;
> +   u8 *sadb;
> +   int sad_count;
> +
> +   if (!dig->afmt->pin)
> +   return;
> +
> +   offset = dig->afmt->pin->offset;

You don't want that (offset) :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: set speakers allocation earlier

[Rafał Miłecki]

Do it before enabling audio channels (in AFMT_AUDIO_PACKET_CONTROL2
register).

Signed-off-by: Rafał Miłecki 
---
 drivers/gpu/drm/radeon/dce6_afmt.c  |   69 +--
 drivers/gpu/drm/radeon/evergreen_hdmi.c |7 +++-
 2 files changed, 54 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c 
b/drivers/gpu/drm/radeon/dce6_afmt.c
index 630df96..34392ec 100644
--- a/drivers/gpu/drm/radeon/dce6_afmt.c
+++ b/drivers/gpu/drm/radeon/dce6_afmt.c
@@ -94,17 +94,62 @@ void dce6_afmt_select_pin(struct drm_encoder *encoder)
WREG32(AFMT_AUDIO_SRC_CONTROL + offset, AFMT_AUDIO_SRC_SELECT(id));
 }
 
-void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
+void dce6_afmt_write_speaker_allocation(struct drm_encoder *encoder)
 {
struct radeon_device *rdev = encoder->dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
u32 offset, tmp;
+   u8 *sadb;
+   int sad_count;
+
+   if (!dig->afmt->pin)
+   return;
+
+   offset = dig->afmt->pin->offset;
+
+   list_for_each_entry(connector, 
&encoder->dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder)
+   radeon_connector = to_radeon_connector(connector);
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Couldn't find encoder's connector\n");
+   return;
+   }
+
+   sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
&sadb);
+   if (sad_count < 0) {
+   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sad_count);
+   return;
+   }
+
+   /* program the speaker allocation */
+   tmp = RREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER);
+   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
+   /* set HDMI mode */
+   tmp |= HDMI_CONNECTION;
+   if (sad_count)
+   tmp |= SPEAKER_ALLOCATION(sadb[0]);
+   else
+   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
+   WREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER, tmp);
+
+   kfree(sadb);
+}
+
+void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+   u32 offset;
struct drm_connector *connector;
struct radeon_connector *radeon_connector = NULL;
struct cea_sad *sads;
-   int i, sad_count, sadb_count;
-   u8 *sadb;
+   int i, sad_count;
 
static const u16 eld_reg_to_type[][2] = {
{ AZ_F0_CODEC_PIN_CONTROL_AUDIO_DESCRIPTOR0, 
HDMI_AUDIO_CODING_TYPE_PCM },
@@ -143,23 +188,6 @@ void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
}
BUG_ON(!sads);
 
-   sadb_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
&sadb);
-   if (sadb_count < 0) {
-   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sadb_count);
-   return;
-   }
-
-   /* program the speaker allocation */
-   tmp = RREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER);
-   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
-   /* set HDMI mode */
-   tmp |= HDMI_CONNECTION;
-   if (sadb_count)
-   tmp |= SPEAKER_ALLOCATION(sadb[0]);
-   else
-   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
-   WREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER, tmp);
-
for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
u32 value = 0;
int j;
@@ -180,7 +208,6 @@ void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
}
 
kfree(sads);
-   kfree(sadb);
 }
 
 static int dce6_audio_chipset_supported(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index c5acdf0..2cb0f90 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -32,6 +32,7 @@
 #include "evergreend.h"
 #include "atom.h"
 
+extern void dce6_afmt_write_speaker_allocation(struct drm_encoder *encoder);
 extern void dce6_afmt_write_sad_regs(struct drm_encoder *encoder);
 extern void dce6_afmt_select_pin(struct drm_encoder *encoder);
 
@@ -267,7 +268,11 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
   AFMT_60958_CS_CHANNEL_NUMBER_6(7) |
 

Re: [PATCH 3/3] drm/radeon: add audio support for DCE6/8 GPUs (v10)

[Rafał Miłecki]

2013/8/14 Alex Deucher :
> +   /* program the speaker allocation */
> +   tmp = RREG32_ENDPOINT(offset, 
> AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER);
> +   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
> +   /* set HDMI mode */
> +   tmp |= HDMI_CONNECTION;
> +   if (sadb_count)
> +   tmp |= SPEAKER_ALLOCATION(sadb[0]);
> +   else
> +   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
> +   WREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER, tmp);
> +
> +   for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> +   u32 value = 0;
> +   int j;
> +
> +   for (j = 0; j < sad_count; j++) {
> +   struct cea_sad *sad = &sads[j];
> +
> +   if (sad->format == eld_reg_to_type[i][1]) {
> +   value = MAX_CHANNELS(sad->channels) |
> +   DESCRIPTOR_BYTE_2(sad->byte2) |
> +   SUPPORTED_FREQUENCIES(sad->freq);
> +   if (sad->format == HDMI_AUDIO_CODING_TYPE_PCM)
> +   value |= 
> SUPPORTED_FREQUENCIES_STEREO(sad->freq);
> +   break;
> +   }
> +   }
> +   WREG32_ENDPOINT(offset, eld_reg_to_type[i][0], value);
> +   }

I hope this is my last questions I'm bothering you with... This is how
fglrx does that part:

WREG32(0x5e00, 0x0125);PIN_CONTROL_CHANNEL_SPEAKER
WREG32(0x5e04, 0x00c1005f);PIN_CONTROL_CHANNEL_SPEAKER

RREG32(0x000..05c); -> 0xAFMT_AUDIO_PACKET_CONTROL2
WREG32(0x000..05c, 0xff00);AFMT_AUDIO_PACKET_CONTROL2

WREG32(0x5e00, 0x0027);0x27 was 0x5f80 on Evergreen
RREG32(0x5e04); -> 0x0x27 was 0x5f80 on Evergreen

WREG32(0x5e00, 0x0127);0x27 was 0x5f80
WREG32(0x5e04, 0x0040);0x27 was 0x5f80

WREG32(0x5e00, 0x000c3128);DESCRIPTOR0
WREG32(0x5e04, 0x7f077f07);DESCRIPTOR0

The difference is that between setting PIN_CONTROL_CHANNEL_SPEAKER and
DESCRIPTOR0 fglrx enables audio channels (see
AFMT_AUDIO_PACKET_CONTROL2 and 0xff00).

Do you think it does matter? Or can we ignore the order and do it your way?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/radeon: add audio support for DCE6/8 GPUs (v10)

[Rafał Miłecki]

2013/8/14 Alex Deucher :
> Similar to DCE4/5, but supports multiple audio pins
> which can be assigned per afmt block.

Acked-by: Rafał Miłecki 

Tested successfully on my HD7750.


> +static void r600_audio_enable(struct radeon_device *rdev,
> + struct r600_audio_pin *pin,
> + bool enable)
>  {
> u32 value = 0;
> -   DRM_INFO("%s audio support\n", enable ? "Enabling" : "Disabling");

Whoops, that confused me at the beginning. Don't you think it's nice
to know from somebody's dmesg if he uses radeon.audio or now? For
debugging purposes.


> +#define AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER  0x25
> +#defineSPEAKER_ALLOCATION(x)   (((x) & 0x7f) 
> << 0)
> +#defineSPEAKER_ALLOCATION_MASK (0x7f << 0)
> +#defineSPEAKER_ALLOCATION_SHIFT0
> +#defineHDMI_CONNECTION (1 << 16)
> +#defineDP_CONNECTION   (1 << 17)

Could you share a meaning of 0x00c0 bit? I noticed it's set when
fglrx reads this register:
WREG32(0x5e00, 0x0025);
RREG32(0x5e04); -> 0x00c0

WREG32(0x5e00, 0x0125);
WREG32(0x5e04, 0x00c1005f);

but it's not set with radeon reads it for the first time. Maybe fglrx
sets that at some other stage (earlier)?

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/radeon: add audio support for DCE6/8 GPUs (v9)

[Rafał Miłecki]

2013/8/14 Alex Deucher :
> +static u32 dce6_endpoint_rreg(struct radeon_device *rdev,
> + u32 block_offset, u32 reg)
> +{
> +   u32 r;
> +
> +   WREG32(AZ_F0_CODEC_ENDPOINT_INDEX + block_offset, reg);
> +   r = RREG32(AZ_F0_CODEC_ENDPOINT_DATA + block_offset);
> +   return r;
> +}
> +
> +static void dce6_endpoint_wreg(struct radeon_device *rdev,
> +  u32 block_offset, u32 reg, u32 v)
> +{
> +   if (ASIC_IS_DCE8(rdev))
> +   WREG32(AZ_F0_CODEC_ENDPOINT_INDEX + block_offset, reg);
> +   else
> +   WREG32(AZ_F0_CODEC_ENDPOINT_INDEX + block_offset,
> +  AZ_ENDPOINT_REG_WRITE_EN | AZ_ENDPOINT_REG_INDEX(reg));
> +   WREG32(AZ_F0_CODEC_ENDPOINT_DATA + block_offset, v);
> +}

Thanks!


> +struct r600_audio_pin *dce6_audio_get_pin(struct radeon_device *rdev)
> +{
> +   int i;
> +
> +   dce6_afmt_get_connected_pins(rdev);
> +
> +   for (i = 0; i < rdev->audio.num_pins; i++) {
> +   if (rdev->audio.pin[i].connected)
> +   return &rdev->audio.pin[i];
> +   }
> +   DRM_ERROR("No connected audio pins found!");
> +   return NULL;
> +}

You missed the line break. Sorry I didn't spot it earlier :/

Re: [PATCH 3/3] drm/radeon: add audio support for DCE6/8 GPUs (v9)

[Rafał Miłecki]

2013/8/14 Alex Deucher :
> +static u32 dce6_endpoint_rreg(struct radeon_device *rdev,
> + u32 block_offset, u32 reg)
> +{
> +   u32 r;
> +
> +   WREG32(AZ_F0_CODEC_ENDPOINT_INDEX + block_offset, reg);
> +   r = RREG32(AZ_F0_CODEC_ENDPOINT_DATA + block_offset);
> +   return r;
> +}
> +
> +static void dce6_endpoint_wreg(struct radeon_device *rdev,
> +  u32 block_offset, u32 reg, u32 v)
> +{
> +   if (ASIC_IS_DCE8(rdev))
> +   WREG32(AZ_F0_CODEC_ENDPOINT_INDEX + block_offset, reg);
> +   else
> +   WREG32(AZ_F0_CODEC_ENDPOINT_INDEX + block_offset,
> +  AZ_ENDPOINT_REG_WRITE_EN | AZ_ENDPOINT_REG_INDEX(reg));
> +   WREG32(AZ_F0_CODEC_ENDPOINT_DATA + block_offset, v);
> +}

Thanks!


> +struct r600_audio_pin *dce6_audio_get_pin(struct radeon_device *rdev)
> +{
> +   int i;
> +
> +   dce6_afmt_get_connected_pins(rdev);
> +
> +   for (i = 0; i < rdev->audio.num_pins; i++) {
> +   if (rdev->audio.pin[i].connected)
> +   return &rdev->audio.pin[i];
> +   }
> +   DRM_ERROR("No connected audio pins found!");
> +   return NULL;
> +}

You missed the line break. Sorry I didn't spot it earlier :/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

no hdmi sound on hd5450

[Rafał Miłecki]

2013/8/13 StompDagger1 at yahoo.com :
> following the inclusion of UVD support for and a post I've seen written by
> on of the devs mentioning that the hdmi sound will likely to be activated by
> default in 3.12, I've decided to switch my cards and use the hd5450 as the
> media center card and connect it to my hdtv.
>
> I've enabled the sound via the relevant kernel param, I see in dmesg that it
> is enabled and when I try to play directly to the hdmi, I see that mplayer
> is playing but there is no sound coming out.
>
> what can be the issue?

We've a regression in radeon (in audio support), I'll try to fix it
tomorrow or the day after. That's the first thing to try.

-- 
Rafa?

Re: no hdmi sound on hd5450

[Rafał Miłecki]

2013/8/13 stompdagg...@yahoo.com :
> following the inclusion of UVD support for and a post I've seen written by
> on of the devs mentioning that the hdmi sound will likely to be activated by
> default in 3.12, I've decided to switch my cards and use the hd5450 as the
> media center card and connect it to my hdtv.
>
> I've enabled the sound via the relevant kernel param, I see in dmesg that it
> is enabled and when I try to play directly to the hdmi, I see that mplayer
> is playing but there is no sound coming out.
>
> what can be the issue?

We've a regression in radeon (in audio support), I'll try to fix it
tomorrow or the day after. That's the first thing to try.

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel