[PATCH] drm/radeon/audio: use actual pll clock for setting up dto
19.10.2013 02:30, Alex Deucher kirjoitti:
> Use the actual pll clock (rather than the mode clock) to set
> up the audio dto. This fixes audio playback speed issues
> when the pll clock does not exactly match the mode clock.
AFAICS we should use this for ACR CTS calculation as well, where/if the
SW values are still used.
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/atombios_crtc.c | 2 ++
> drivers/gpu/drm/radeon/evergreen_hdmi.c | 9 +
> drivers/gpu/drm/radeon/r600_hdmi.c | 16 +---
> drivers/gpu/drm/radeon/radeon_mode.h| 1 +
> 4 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index bf87f6d..3a6059f 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -1027,6 +1027,8 @@ static void atombios_crtc_set_pll(struct drm_crtc
> *crtc, struct drm_display_mode
> radeon_compute_pll_legacy(pll, radeon_crtc->adjusted_clock,
> _clock,
> _div, _fb_div, _div,
> _div);
>
> + radeon_crtc->pll_clock = pll_clock * 10; /* convert to khz units */
> +
> atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id,
>radeon_crtc->crtc_id, _crtc->ss);
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> index 6787365..0d55870 100644
> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> @@ -225,7 +225,7 @@ static void evergreen_hdmi_update_avi_infoframe(struct
> drm_encoder *encoder,
> frame[0xC] | (frame[0xD] << 8) | (header[1] << 24));
> }
>
> -static void evergreen_audio_set_dto(struct drm_encoder *encoder, u32 clock)
> +static void evergreen_audio_set_dto(struct drm_encoder *encoder)
> {
> struct drm_device *dev = encoder->dev;
> struct radeon_device *rdev = dev->dev_private;
> @@ -233,9 +233,10 @@ static void evergreen_audio_set_dto(struct drm_encoder
> *encoder, u32 clock)
> struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
> struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
> u32 base_rate = 24000;
> - u32 max_ratio = clock / base_rate;
> + u32 max_ratio = radeon_crtc->pll_clock / base_rate;
> u32 dto_phase;
> - u32 dto_modulo = clock;
> + /* need to use the exact pll clock here to keep audio rate correct */
> + u32 dto_modulo = radeon_crtc->pll_clock;
> u32 wallclock_ratio;
> u32 dto_cntl;
>
> @@ -296,7 +297,7 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder,
> struct drm_display_mode
> return;
> offset = dig->afmt->offset;
>
> - evergreen_audio_set_dto(encoder, mode->clock);
> + evergreen_audio_set_dto(encoder);
>
> WREG32(HDMI_VBI_PACKET_CONTROL + offset,
> HDMI_NULL_SEND); /* send null packets when required */
> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
> b/drivers/gpu/drm/radeon/r600_hdmi.c
> index 21f2b74..b8c444e 100644
> --- a/drivers/gpu/drm/radeon/r600_hdmi.c
> +++ b/drivers/gpu/drm/radeon/r600_hdmi.c
> @@ -219,16 +219,18 @@ static void r600_hdmi_audio_workaround(struct
> drm_encoder *encoder)
>value, ~HDMI0_AUDIO_TEST_EN);
> }
>
> -void r600_audio_set_dto(struct drm_encoder *encoder, u32 clock)
> +static void r600_audio_set_dto(struct drm_encoder *encoder)
> {
> struct drm_device *dev = encoder->dev;
> struct radeon_device *rdev = dev->dev_private;
> struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
> + struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
> u32 base_rate = 24000;
> - u32 max_ratio = clock / base_rate;
> + u32 max_ratio = radeon_crtc->pll_clock / base_rate;
> u32 dto_phase;
> - u32 dto_modulo = clock;
> + /* need to use the exact pll clock here to keep audio rate correct */
> + u32 dto_modulo = radeon_crtc->pll_clock;
> u32 wallclock_ratio;
> u32 dto_cntl;
>
> @@ -279,17 +281,17 @@ void r600_audio_set_dto(struct drm_encoder *encoder,
> u32 clock)
>*/
> if (dig->dig_encoder == 0) {
> WREG32(DCCG_AUDIO_DTO0_PHASE, base_rate * 100);
> - WREG32(DCCG_AUDIO_DTO0_MODULE, clock * 100);
> + WREG32(DCCG_AUDIO_DTO0_MODULE, dto_modulo * 100);
> WREG32(DCCG_AUDIO_DTO_SELECT, 0); /* select DTO0 */
> } else {
> WREG32(DCCG_AUDIO_DTO1_PHASE, base_rate * 100);
> - WREG32(DCCG_AUDIO_DTO1_MODULE, clock * 100);
> + WREG32(DCCG_AUDIO_DTO1_MODULE, dto_modulo * 100);
> WREG32(DCCG_AUDIO_DTO_SELECT, 1); /* select DTO1 */
>
[Bug 61941] Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1
https://bugzilla.kernel.org/show_bug.cgi?id=61941 --- Comment #9 from Ilya Tumaykin --- Changing gfx_clock_gating also doesn't help. There's one more thing though that I've changed alongside dpm: I've enabled aspm=1 for kernel driver. I will remove aspm=1 from modprobe.conf so the driver will choose itself whether it should be on or off. I'll report whether this helps or not. -- You are receiving this mail because: You are watching the assignee of the bug.
MmioTrace: Using the Instruction Decoder, etc.
Hi, 2013/10/25 Pekka Paalanen > > Just curious, how do you detect interesting instructions to > instrument from uninteresting instructions that do not access mmio > areas? > > As I currently use this for data race detection in general, there is no need to separate accesses to mmio areas from the accesses to other memory. The tool just tracks all except the accesses to the data on the stack (if it can know for sure the data are on the stack from the address of the memory area). These are usually not interested for data race detection in the kernel anyway. So, yes, almost all the instructions that may access memory (except some special instructions as well as MMX, SSE, AVX, ...) are instrumented. For some instructions, it is easy to determine in advance if they access memory, so I enhanced the decoder from Kprobes to provide that info. For other instructions (e.g. CMPXCHG, conditional MOVs), it is determined in runtime whether they access memory and whether this event should be reported. So, currently, it does not handle mmio areas in any special way. I am just evaluating, if it could be useful to create a tool based on the same technique for these purposes. mmio areas can be obtained by a driver through a few kernel functions. A set of currently obtained such areas could be used to filter the accesses and decide whether to report them or not. So, yes, basically, it is "instrument everything, filter before reporting to user space". I guess to be sure your approach does not miss anything, we'd still > need the page faulting setup as a safety net to know when or if > something is missed, right? And somehow have the instrumented code > circumvent it. > Page faulting as a safety net... I haven't thought that through yet. I suppose, I'll look at the code first when I have time and try to understand at least the common ways for a driver to access mmio areas. It will be clearer then how to make sure we do not lose anything. And - if it is possible with the techniques KernelStrider uses. > > We could use some comments from the real reverse-engineers. I used > to be mostly a tool writer. > Yes, if some experts could share their knowledge of this matter, this would be most welcome! Regards, Eugene P.S. If you are interested, more info concerning KernelStrider can be found in my recent talk at LinuxCon Europe. The slides and notes for them are available in "Talks and slides" section on the project page ( https://code.google.com/p/kernel-strider/). This is mostly about data races though. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131025/a6af0d5c/attachment.html>
[Bug 68804] 16 re-frames video decoding stutter on UVD with radeon driver
https://bugs.freedesktop.org/show_bug.cgi?id=68804 russianneuromancer at ya.ru changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from russianneuromancer at ya.ru --- Not reproducible anymore with current Mesa git and XBMC git. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131025/28a7aa63/attachment-0001.html>
[Bug 68803] Screen is green or black in beginning of video playback when "Adjust Refreshrate to match video" XBMC option is set to "Always"
https://bugs.freedesktop.org/show_bug.cgi?id=68803 russianneuromancer at ya.ru changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from russianneuromancer at ya.ru --- Not reproducible anymore with current Mesa git and XBMC git. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131025/1470666b/attachment-0001.html>
[Bug 68802] Blu-ray playback fine on UVD in mplayer2, but stutter in XBMC
https://bugs.freedesktop.org/show_bug.cgi?id=68802 russianneuromancer at ya.ru changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from russianneuromancer at ya.ru --- Doesn't stutter anymore with current Mesa git and XBMC git. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131025/f0cfc7b3/attachment-0001.html>
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
Sorry for some typos.
2013/10/24 Inki Dae :
> 2013/10/23 Rob Clark :
>> On Wed, Oct 23, 2013 at 9:18 AM, Inki Dae wrote:
>>> Look at omapdrm, nouveau, and radeon drm drivers.
>>
>>
>> btw, please don't look at omapdrm as a "good" example in this regard.
>> The layering is really not a good idea and for a long time caused a
>> lot of problems, which we essentially solved by bypassing parts of the
>> layering. I still think omapdss and omapdrm should be flattened into
>> a single drm driver, then net result would be a drop in # of lines of
>
> It seems that you proper to use duplicated driver. I mean... do you
s/proper/prefer
> proper that omapdss driver is placed in drm framework? Otherwise, is
s/proper/prefer
> there any way that omapdss and omapdrm can be flattened into a single
> drm driver without moving omapdss into drm framework? As I mentioned
> earlier, we wanted to reuse the existing panel driver so Exynos drm
> framework has the layer, wrappers to connector and encoder. Of course,
> for this, we have TODO works yet, and I still think it's better way to
> keep the wrapper if we should reuse the existing panel drivers.
>
> The below would be one design for the case,
>
>
> lcd panel
> drivers
> \ | /
>drm framework - drm_bridge
> / | \
> crtc
> drivers(display controller or hdmi)
>
>
> A header file of drm_bridge includes drm_panel structure having some
> callbacks related to connector, and some function to register crtc and
> panel driver's requests to the drm_bridge object. And the header file
> can be included in the existing panel drivers. In other words,
> drm_bridge will connect drm driver and lcd class based panel drivers.
>
> struct drm_bridge {
> struct list_head list;
> unsigned int type;
> struct drm_device *drm_dev;
> struct drm_panel *panel_ops;
> ...
> int (*drm_create_enc_conn)();
> };
>
> A drm_bridge object has drm_panel ops and drm_create_enc_conn
> callback. And once the crtc driver calls register function of the
> drm_bridge with drm_create_enc_conn callback pointer, a drm_crtc is
> created, and once the panel driver calls the register function with
> drm_panel ops, a encoder and a connector are created. At this time,
> drm_fb_helper_initial_config() can be called appropriately to connect
> crtc and connector, and to display framebuffer on lcd panel.
>
> The above is just my opinion for the case, and we are testing this way
> implementing it internally.
>
> Thanks,
> Inki Dae
>
>> code. I wish there were folks like the Sean and St?phane who cared
>> enough to do this for omapdrm ;-)
>>
>> Other drivers have some modularity to separate code that is
>> significantly different across genarations (but what form that takes
>> differs depending on what how the hw differs across generations).
>> This isn't a bad thing. But you need to look at the end result. For
>> example how I split out the phy code for the mdp4 code in msm (hdmi
>> and dsi phy differ between otherwise similar 28nm and 45nm parts, but
>> the rest of the display controller blocks are basically the same).
>>
>> BR,
>> -R
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60532] Suspend with dedicated graphics card switched off breaking with kernel version 3.8.0-25+
https://bugzilla.kernel.org/show_bug.cgi?id=60532 --- Comment #11 from rohankapadia at gmail.com --- How do I compile and install this kernel tree for ubuntu 13.10? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60532] Suspend with dedicated graphics card switched off breaking with kernel version 3.8.0-25+
https://bugzilla.kernel.org/show_bug.cgi?id=60532 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #10 from Alex Deucher --- It looks like the kernel is trying to access a gpu that has been powered down via acpi or the bios. Does it work properly with this kernel tree? http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.13-wip -- You are receiving this mail because: You are watching the assignee of the bug.
[RFR 2/2] drm/panel: Add simple panel support
in the driver using one specified > > > > > > > in the DT? That's obviously a backwards-compatible change, so it > > > > > > > could be added if or when it becomes necessary. > > > > > > > > > > > > I share Tomi's point of view here. Your three panels use the same > > > > > > power sequence, so I believe we should have a generic panel > > > > > > compatible string that would use modes described in DT for the > > > > > > common case. Only if a panel required something more complex which > > > > > > can't (or which could, but won't for any reason) accurately be > > > > > > described in DT would you need to extend the driver. > > > > > > > > > > I don't see the point quite frankly. You seem to be assuming that > > > > > every panel will only be used in a single board. > > > > > > > > No, but in practice that's often the case, at least for boards with > > > > .dts files in the mainline kernel. > > > > > > > > > However what you're proposing will require the mode timings to be > > > > > repeated in every board's DT file, if the same panel is ever used on > > > > > more than a single board. > > > > > > > > Is that a problem ? You could #include a .dtsi for the panel that > > > > would specify the video mode if you want to avoid multiple copies. > > > > > > Yes, I don't think it's desirable to duplicate data needlessly in DT. It > > > also makes the binding more difficult to use. If I know that the panel > > > is one supported by the simple-panel binding, I can just go and add the > > > right compatible value without having to bother looking up the mode > > > timings and duplicating them. That way DT writers get to concern > > > themselves only with the variable data. > > > > I've had a quick chat with Dave Airlie and Hans de Goede yesterday about > > this. As most panels will use standard timings, Hans proposed adding a > > timings property that would reference the standard timings the panel uses > > (this could be a string or integer defined in include/dt-bindings/...). > > In most case DT would just have a single property to select the timings, > > and only in more complex cases where the system designer wants to use > > custom timings would the timings need to be manually defined. > > We can do the same thing within the kernel. We already have a list of > standard EDID/HDMI/CEA display modes, so we could similarly add a new > list of common display panel modes and make each driver reference that > instead of defining a custom one. Sure. My point is that I would like to avoid adding zillions of compatible properties to the driver, when we could use a single property in the DT bindings that would specify the timings instead. This would lower the amount of changes made to the simple panel driver, while keeping DT simple enough (at least in my opinion). > And that still enables us to add a property that would allow DT writers > to override the display mode if they need to. -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131025/9daeaf39/attachment.pgp>
[Bug 60532] Suspend with dedicated graphics card switched off breaking with kernel version 3.8.0-25+
https://bugzilla.kernel.org/show_bug.cgi?id=60532 --- Comment #9 from rohankapadia at gmail.com --- Upgraded to kernel version 3.11. Same problem. An earlier report (see my comments above) had said that kernel version 3.10 fixed the issue but the problem persists. -- You are receiving this mail because: You are watching the assignee of the bug.
3.12-rc6 nouveau oops
On Fri, Oct 25 2013, Dave Airlie wrote: > On Fri, Oct 25, 2013 at 8:59 AM, Dave Airlie wrote: > >> Booting 3.12-rc6 on my macbook quickly freezes after logging in to X. I > >> was able to capture this oops. It's 100% consistent. 3.11 works > >> perfectly fine, as did previous kernels. > > > > Can you boot with nouveau.runpm=0 and see if it boots and survives > > suspend/resume. It does! > Oh also a complete dmesg so we can see the DCB table. Below. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.12.0-rc6+ (axboe at lenny) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-2ubuntu4) ) #68 SMP PREEMPT Fri Oct 25 13:07:23 BST 2013 [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.12 root=/dev/sda6 video=efifb i915.modeset=1 i915.i915_enable_rc6=3 i915.lvds_channel_mode=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 drm.vblankoffdelay=1 i915.i915_enable_ppgtt=0 nouveau.runpm=0 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0008dfff] usable [0.00] BIOS-e820: [mem 0x0008e000-0x0008] reserved [0.00] BIOS-e820: [mem 0x0009-0x0009] usable [0.00] BIOS-e820: [mem 0x000a-0x000b] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x40003fff] usable [0.00] BIOS-e820: [mem 0x40004000-0x40004fff] reserved [0.00] BIOS-e820: [mem 0x40005000-0x8ad13fff] usable [0.00] BIOS-e820: [mem 0x8ad14000-0x8ad52fff] ACPI NVS [0.00] BIOS-e820: [mem 0x8ad53000-0x8ad68fff] usable [0.00] BIOS-e820: [mem 0x8ad69000-0x8ad8efff] ACPI data [0.00] BIOS-e820: [mem 0x8ad8f000-0x8ae3afff] usable [0.00] BIOS-e820: [mem 0x8ae3b000-0x8ae8efff] reserved [0.00] BIOS-e820: [mem 0x8ae8f000-0x8aecdfff] usable [0.00] BIOS-e820: [mem 0x8aece000-0x8aefefff] reserved [0.00] BIOS-e820: [mem 0x8aeff000-0x8af91fff] usable [0.00] BIOS-e820: [mem 0x8af92000-0x8affefff] reserved [0.00] BIOS-e820: [mem 0x8afff000-0x8aff] usable [0.00] BIOS-e820: [mem 0x8b00-0x8f9f] reserved [0.00] BIOS-e820: [mem 0xe00f8000-0xe00f8fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xffe7-0xffe9] reserved [0.00] BIOS-e820: [mem 0x0001-0x00026f5f] usable [0.00] NX (Execute Disable) protection: active [0.00] efi: EFI v1.10 by Apple [0.00] efi: ACPI=0x8ad8e000 ACPI 2.0=0x8ad8e014 SMBIOS=0x8ad1b000 [0.00] efi: mem00: type=7, attr=0x80f, range=[0x-0x0008e000) (0MB) [0.00] efi: mem01: type=0, attr=0x80f, range=[0x0008e000-0x0009) (0MB) [0.00] efi: mem02: type=7, attr=0x80f, range=[0x0009-0x000a) (0MB) [0.00] efi: mem03: type=2, attr=0xf, range=[0x0010-0x0131) (18MB) [0.00] efi: mem04: type=7, attr=0xf, range=[0x0131-0x2000) (492MB) [0.00] efi: mem05: type=0, attr=0xf, range=[0x2000-0x2020) (2MB) [0.00] efi: mem06: type=7, attr=0xf, range=[0x2020-0x36006000) (350MB) [0.00] efi: mem07: type=2, attr=0xf, range=[0x36006000-0x36ffb000) (15MB) [0.00] efi: mem08: type=7, attr=0xf, range=[0x36ffb000-0x40004000) (144MB) [0.00] efi: mem09: type=0, attr=0xf, range=[0x40004000-0x40005000) (0MB) [0.00] efi: mem10: type=7, attr=0xf, range=[0x40005000-0x655bf000) (597MB) [0.00] efi: mem11: type=2, attr=0xf, range=[0x655bf000-0x8721a000) (540MB) [0.00] efi: mem12: type=1, attr=0xf, range=[0x8721a000-0x872d) (0MB) [0.00] efi: mem13: type=4, attr=0xf, range=[0x872d-0x872d1000) (0MB) [0.00] efi: mem14: type=7, attr=0xf, range=[0x872d1000-0x87383000) (0MB) [0.00] efi: mem15: type=4, attr=0xf, range=[0x87383000-0x87386000) (0MB) [0.00] efi: mem16: type=2, attr=0xf, range=[0x87386000-0x87387000) (0MB) [0.00] efi: mem17: type=4, attr=0xf,
[Bug 34495] Selecting objects in Blender 2.56 slow due the software gl_select mode
https://bugs.freedesktop.org/show_bug.cgi?id=34495 Alex Deucher changed: What|Removed |Added Assignee|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org Summary|Selecting objects in|Selecting objects in |Blender 2.56 slow with |Blender 2.56 slow due the |gallium r600 driver |software gl_select mode Component|Drivers/Gallium/r600|Mesa core --- Comment #73 from Alex Deucher --- (In reply to comment #71) > (In reply to comment #70) > > I wonder if the fix has been committed? I am using Debian testing with the > > mesa 9.1-7 package provided in the testing repository, and the selections > > with Blender are still very slow. > > It has been merged to master in mesa 9.2. It hasn't been merged yet. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131025/80ff3458/attachment.html>
[RFR 2/2] drm/panel: Add simple panel support
On 10/24/2013 12:52 PM, Tomi Valkeinen wrote:
> On 24/10/13 13:40, Laurent Pinchart wrote:
>
>>> panel {
>>> remote =<>;
>>> common-video-property =;
>>> };
>>>
>>> panel {
>>> port {
>>> endpoint {
>>> remote =<>;
>>> common-video-property =;
>>> };
>>> };
>>> };
>>
>> Please note that the common video properties would be in the panel node, not
>> in the endpoint node (unless you have specific requirements to do so, which
>> isn't the common case).
>
> Hmm, well, the panel driver must look for its properties either in the
> panel node, or in the endpoint node (I guess it could look them from
> both, but that doesn't sound good).
Presumably the OS could be searching for port node and any endpoint node
inside it first. If that's not found then it could be parsing the panel
node.
Please note that a port node may be required even if there is only one
port, when there are multiple physical bus interfaces, e.g. at an LCD
controller and only one of them is used. The reg property would select
the physical bus interface.
I wonder if a property like #video-port or #video-endpoint could be used
to indicate that a node contains video bus properties. Probably it's too
late to introduce it now and make it a required property for the endpoint
nodes or nodes containing the common video properties.
> If you write the panel driver, and in all your cases the properties work
> fine in the panel node, does that mean they'll work fine with everybody?
It's likely not safe to assume so. In V4L data bus properties are specified
a both the receiver and the transmitter endpoint nodes separately.
> I guess there are different kinds of properties. Something like a
> regulator is obviously property of the panel. But anything related to
> the video itself, like DPI's bus width, or perhaps even something like
> "orientation" if the panel supports such, could need to be in the
> endpoint node.
If we use port/endpoint nodes it all seems clear, the video bus properties
are put in an endpoint node.
But since we are considering a simplified binding all the properties would
be placed in the panel or display controller node.
> But yes, I understand what you mean. With "common-video-property" I
> meant common properties like DPI bus width.
>
>>> If that can be supported in the SW by adding complexity to a few functions,
>>> and it covers practically all the panels, isn't it worth it?
>>>
>>> Note that I have not tried this, so I don't know if there are issues.
>>> It's just a thought. Even if there's need for a endpoint node, perhaps
>>> the port node can be made optional.
>>
>> It can be worth it, as long as we make sure that simplified bindings cover
>> the
>> needs of the generic code.
>>
>> We could assume that, if the port subnode isn't present, the device will have
>> a single port, with a single endpoint. However, isn't the number of endpoints
>
> Right.
>
>> a system property rather than a device property ? If a port of a device is
>
> Yes.
>
>> connected to two remote ports it will require two endpoints. We could select
>> the simplified or full bindings based on the system topology though.
Yes, I guess it's all about the system topology. Any simplified binding
would
work only for very simple configuration like single-output LCD
controller with
single panel attached to it.
> The drivers should not know about simplified/normal bindings. They
> should use CDF DT helper functions to get the port and endpoint
> information. The helper functions would do the assuming.
Yes, anyway all the parsing is supposed to be done within the helpers.
--
Thanks,
Sylwester
[Bug 60929] [r600-llvm] mono games with opengl are blocking on start
https://bugs.freedesktop.org/show_bug.cgi?id=60929 --- Comment #21 from Radist Morse --- Confirm the bug on the several unity3d games. Quickfix works. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131025/d531a5c9/attachment-0001.html>
[PULL] drm-intel-fixes
Hi Dave, Just the edp bpp fix from Jani plus the pipe bpp readout code from Ville to make it work. There's a 3 pipe ivb regression fix pending from me, but Ville's review convinced me that my first stab is broken. Cheers, Daniel The following changes since commit 828c79087cec61eaf4c76bb32c222fbe35ac3930: drm/i915: Disable GGTT PTEs on GEN6+ suspend (2013-10-18 15:44:47 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-10-25 for you to fetch changes up to 52e1e223456e3aa747e9932f95948381f04b3b26: drm/i915/dp: workaround BIOS eDP bpp clamping issue (2013-10-21 09:57:02 +0200) Jani Nikula (1): drm/i915/dp: workaround BIOS eDP bpp clamping issue Ville Syrj?l? (1): drm/i915: Add support for pipe_bpp readout drivers/gpu/drm/i915/intel_ddi.c | 17 + drivers/gpu/drm/i915/intel_display.c | 36 drivers/gpu/drm/i915/intel_dp.c | 20 3 files changed, 73 insertions(+) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
MmioTrace: Using the Instruction Decoder, etc.
On Sat, 19 Oct 2013 17:12:20 +0400 Eugene Shatokhin wrote: > Hi, > > > Ah, you are not using the ftrace framework nor relayfs? Mmiotrace > used to be relayfs at one point and then converted to ftrace. > > Yes, I considered these when I started working on KernelStrider but finally > borrowed ideas from Perf and implemented them. A mmapped ring buffer does > its job well and has a higher throughput than Ftrace in my case. > > > Are you saying that you intercept function calls, and *never* rely > > on page faulting? > > The system intercepts both function calls *and* memory operations made by > the driver itself. Yes, it never relies on page faulting. > > > Does that mean that if a driver does the ugly thing and > > dereferences an iomem pointer directly, you won't catch that? > > It will be caught. > > What my system actually does is as follows. > > When the target kernel module has been loaded into memory but before it has > begun its initialization, KernelStrider processes it, function after > function. It creates an instrumented variant of each function in the module > mapping space and places a jump at the beginning of the original function > to point to the instrumented one. After instrumentation is done, the target > driver may start executing. Oh, that works on a completely different way than I even imagined, a whole another level of complexity. <...snip code you corrected in another email> > That is, the address which is about to be accessed is determined and stored > in 'local_storage', a special memory structure. At the end of the block of > instructions, the information from the local storage is sent to the output > system. So the addresses and sizes of the accessed memory areas as well as > the types of the accesses (read/write/update) will be available for reading > from the user space. Just curious, how do you detect interesting instructions to instrument from uninteresting instructions that do not access mmio areas? Does it rely on post-processing, in that you instrument practically everything, and then in post-processing you check if the accessed memory address actually was interesting before sending the data to user space? > It is actually more complex than that (KernelStrider has to deal with > register allocation, relocations and other things) but the principle is as > I described. > > The function calls are processed too so that we can set our own handlers to > execute at the beginning of a function and right before its exit. > > Yes, the functions like read[bwql]() and write[bwlq]() are usually inline > but they pose no problem: on x86 they compile to ordinary MOV instructions > and the like which are handled as I described above. > > The instrumented code will access the ioremapped area the same way as the > original code would, no need for single-stepping or emulation in this case. That is very cool, the possibility never even occurred to me. > What I wrote in my previous letter is that there is a special case when the > target driver uses some non-inline function provided by the kernel proper > or by another driver and that function accesses the ioremapped memory area > of interest. > > KernelStrider needs to track all such functions in order not to miss some > memory accesses to that ioremapped area. Perhaps, that's manageable. There > are not too many such functions, aren't they? I don't really know, and personally I was never even interested, since the page faulting approach was a catch-all method. We could even detect when we hit some access we couldn't handle right due to lacking instruction decoding. I guess to be sure your approach does not miss anything, we'd still need the page faulting setup as a safety net to know when or if something is missed, right? And somehow have the instrumented code circumvent it. We could use some comments from the real reverse-engineers. I used to be mostly a tool writer. Thanks, pq
[v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert "Revert "drm/i915: revert eDP bpp clamping code changes""
On 10/16/2013 05:02 PM, Daniel Vetter wrote: > On Wed, Oct 16, 2013 at 04:34:57PM -0400, Joseph Salisbury wrote: >> BugLink: http://bugs.launchpad.net/bugs/1195483 >> >> This reverts commit 657445fe8660100ad174600ebfa61536392b7624. >> >> Signed-off-by: Joseph Salisbury >> Cc: Daniel Vetter >> Cc: Paulo Zanoni >> Cc: David Airlie >> Cc: stable at vger.kernel.org > It's by far not that simple. Jani is working on both the underlying bug > and a better w/a. See > > https://bugzilla.kernel.org/show_bug.cgi?id=59841 > > for the full story in its entire glory. > > Cheers, Daniel Thanks for the feedback, Daniel. Is there an estimate on what mainline release might contain Jani's work? Thanks again, Joe
[PATCH v5 0/4] Fix Win8 backlight issue
On Thu, 2013-10-24 at 16:13 +0800, Aaron Lu wrote: > On 10/16/2013 07:33 AM, Rafael J. Wysocki wrote: > > On Friday, October 11, 2013 09:27:42 PM Aaron Lu wrote: > >> v5: > >> 1 Introduce video.use_native_backlight module parameter and set its > >> value to false by default as suggested by Rafael. For Win8 systems > >> which have broken ACPI video backlight control, the parameter can be > >> set to 1 in kernel cmdline to skip registering ACPI video's backlight > >> interface. Due to this change, the acpi_video_verify_backlight_support > >> is moved from video_detect.c to video.c - patch 3/4; > >> 2 Rename bd_list_head and bd_list_mutex in backlight.c to > >> backlight_dev_list and backlight_dev_list_mutex as suggested by Rafael > >> - patch 1/4. > >> > >> v4: > >> Remove decleration and stub for acpi_video_unregister_backlight in > >> video.h of patch 2/4 since that function doesn't exist anymore in v3. > >> > >> v3: > >> 1 Add a new patch 4/4 to fix some problems in thinkpad-acpi module; > >> 2 Remove unnecessary function acpi_video_unregister_backlight introduced > >> in patch 2/4 as pointed out by Jani Nikula. > >> > >> v2: > >> v1 has the subject of "Rework ACPI video driver" and is posted here: > >> http://lkml.org/lkml/2013/9/9/74 > >> Since the objective is really to fix Win8 backlight issues, I changed > >> the subject in this version, sorry about that. > >> > >> This patchset has four patches, the first introduced a new API named > >> backlight_device_registered in backlight layer that can be used for > >> backlight interface provider module to check if a specific type backlight > >> interface has been registered, see changelog for patch 1/4 for details. > >> Then patch 2/4 does the cleanup to sepeate the backlight control and > >> event delivery functionality in the ACPI video module and patch 3/4 > >> solves some Win8 backlight control problems by avoiding register ACPI > >> video's backlight interface if: > >> 1 Kernel cmdline option acpi_backlight=video is not given; > >> 2 This is a Win8 system; > >> 3 Native backlight control interface exists. > >> Patch 4/4 fixes some problems in thinkpad-acpi module. > >> > >> Technically, patch 2/4 is not required to fix the issue here. So if you > >> think it is not necessary, I can remove it from the series. > >> > >> Aaron Lu (4): > >> backlight: introduce backlight_device_registered > >> ACPI / video: seperate backlight control and event interface > >> ACPI / video: Do not register backlight if win8 and native interface > >> exists > >> thinkpad-acpi: fix handle locate for video and query of _BCL > >> > >> drivers/acpi/internal.h | 4 +- > >> drivers/acpi/video.c | 457 > >> --- > >> drivers/acpi/video_detect.c | 4 +- > >> drivers/platform/x86/thinkpad_acpi.c | 31 ++- > >> drivers/video/backlight/backlight.c | 31 +++ > >> include/linux/backlight.h| 4 + > >> 6 files changed, 326 insertions(+), 205 deletions(-) > > > > I've added this series to my queue for 3.13. > > > > Since the next step will be to introduce a list of systems that need > > video.use_native_backlight=1 *and* don't break in that configuration, I > > don't > > see much point adding another Kconfig option for the default. > > > > Hopefully, in the future we'll be able to fix the problems causing > > video.use_native_backlight=1 to fail of the systems where it fails and then > > we'll be able to make that the default behavior and drop the option > > altogether. > > I've prepared a patch(at the end of the mail) to set use_native_backlight > by default for some systems. There are 3 systems currently that I'm > kind of sure that should be added: > > The ThinkPad T430s and X230 is: > Reported-by: Theodore Tso > Reported-and-tested-by: Peter Weber > Reported-by: Igor Gnatenko > Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51231 > > The Lenovo Yoga is: > Reported-by: Lennart Poettering > Reference: https://lkml.org/lkml/2013/10/13/178 > > From: Aaron Lu > Subject: [PATCH] ACPI / video: Add systems that should favor native backlight > interface > > Some system's ACPI video backlight control interface is broken and the > native backlight control interface should be used by default. This patch > sets the use_native_backlight parameter to true for those systems so > that video backlight control interface will not be created. To be > clear, the ThinkPad T430s/X230 and Lenovo Yoga 13 are added here. > > Reported-by: Theodore Tso > Reported-and-tested-by: Peter Weber > Reported-by: Lennart Poettering > Reported-by: Igor Gnatenko > Signed-off-by: Aaron Lu > --- > drivers/acpi/video.c | 30 ++ > 1 file changed, 30 insertions(+) > > diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c > index d020df5..9a80a94 100644 > --- a/drivers/acpi/video.c > +++ b/drivers/acpi/video.c > @@ -412,6 +412,12 @@ static int
[RFC 04/12] phy: Add simple-phy driver
Hi,
Please refer to the comments below.
On 10/24/2013 05:52 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Monday 21 October 2013 07:48 PM, Tomasz Stanislawski wrote:
>> Add simple-phy driver to support a single register
>> PHY interfaces present on Exynos4 SoC.
>
> How are these PHY interfaces modelled in the SoC? Where does the register
> actually reside?
Initially, I was planning to add PHY for HDMI_PHY register in
power management register set on s5pv310 soc.
However other PHYs use very similar interface (setting bit 0).
This includes DAC_PHY, ADC_PHY, PCIe_PHY, SATA_PHY.
Moreover it suits well to USBDEVICE_PHY, USBHOST_PHY.
That is why I thought about using something more generic
to handle all those phys without introducing a herd of
200-lines-long drivers.
>>
>> Signed-off-by: Tomasz Stanislawski
>> ---
>> drivers/phy/Kconfig |5 ++
>> drivers/phy/Makefile |1 +
>> drivers/phy/phy-simple.c | 128
>> ++
>> 3 files changed, 134 insertions(+)
>> create mode 100644 drivers/phy/phy-simple.c
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index ac239ac..619c657 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -38,4 +38,9 @@ config TWL4030_USB
>>This transceiver supports high and full speed devices plus,
>>in host mode, low speed.
>>
>> +config PHY_SIMPLE
>> +tristate "Simple PHY driver"
>
> This is too generic a name to be used. Lets name it something specific to what
> it is used for (EXYNOS/HDMI.. ?).
Ok. It could be renamed to EXYNOS-SIMPLE-PHY or EXYNOS-1BIT-PHY or
EXYNOS-GENERIC-PHY
or something similar. Any ideas?
>> +help
>> + Support for PHY controllers configured using single register.
>> +
>> endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 0dd8a98..3d68e19 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -5,3 +5,4 @@
>> obj-$(CONFIG_GENERIC_PHY) += phy-core.o
>> obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
>> obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
>> +obj-$(CONFIG_PHY_SIMPLE)+= phy-simple.o
>> diff --git a/drivers/phy/phy-simple.c b/drivers/phy/phy-simple.c
>> new file mode 100644
>> index 000..4a28af7
>> --- /dev/null
>> +++ b/drivers/phy/phy-simple.c
>> @@ -0,0 +1,128 @@
>> +/*
>> + * Simple PHY driver
>> + *
>> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
>> + * Author: Tomasz Stanislawski
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +struct simple_phy {
>> +spinlock_t slock;
>> +u32 on_value;
>> +u32 off_value;
>> +u32 mask;
>> +void __iomem *regs;
>> +};
>> +
>> +static int sphy_set(struct simple_phy *sphy, bool on)
>> +{
>> +u32 reg;
>> +
>> +spin_lock(>slock);
>
> Lets add spin_lock only when it is absolutely necessary. When your PHY
> provider
> implements only a single PHY, it is not needed. phy_power_on and phy_power_off
> is already protected by the framework.
ok
>> +
>> +reg = readl(sphy->regs);
>> +reg &= ~sphy->mask;
>> +reg |= sphy->mask & (on ? sphy->on_value : sphy->off_value);
>> +writel(reg, sphy->regs);
>> +
>> +spin_unlock(>slock);
>> +
>> +return 0;
>> +}
>> +
>> +static int simple_phy_power_on(struct phy *phy)
>> +{
>> +return sphy_set(phy_get_drvdata(phy), 1);
>> +}
>> +
>> +static int simple_phy_power_off(struct phy *phy)
>> +{
>> +return sphy_set(phy_get_drvdata(phy), 0);
>> +}
>> +
>> +static struct phy_ops simple_phy_ops = {
>> +.power_on = simple_phy_power_on,
>> +.power_off = simple_phy_power_off,
>> +.owner = THIS_MODULE,
>> +};
>> +
>> +static int simple_phy_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = >dev;
>> +struct simple_phy *sphy;
>> +struct resource *res;
>> +struct phy_provider *phy_provider;
>> +struct phy *phy;
>> +
>> +sphy = devm_kzalloc(dev, sizeof(*sphy), GFP_KERNEL);
>> +if (!sphy)
>> +return -ENOMEM;
>> +
>> +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +
>> +sphy->regs = devm_ioremap_resource(dev, res);
>> +if (IS_ERR(sphy->regs)) {
>> +dev_err(dev, "failed to ioremap registers\n");
>> +return PTR_ERR(sphy->regs);
>> +}
>> +
>> +spin_lock_init(>slock);
>> +
>> +phy_provider = devm_of_phy_provider_register(dev, NULL);
>
> pass 'of_phy_simple_xlate' instead of NULL.
>> +if (IS_ERR(phy_provider)) {
>> +dev_err(dev, "failed to register PHY provider\n");
>> +return PTR_ERR(phy_provider);
>> +}
>> +
>> +phy = devm_phy_create(dev, _phy_ops, NULL);
>> +if (IS_ERR(phy)) {
>> +
[pull] radeon drm-fixes-3.12
Hi Dave, Just a few small fixes for radeon (audio regression fix, stability fix, and an endian bug noticed by coverity). The following changes since commit 579123fdfc23ad2147f041dfec305c2308f068ba: Merge branch 'drm-fixes-3.12' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2013-10-22 07:35:17 +0100) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.12 for you to fetch changes up to cdf6e8058415ba4d808537e30a0a6be9fb29e95a: drm/radeon/dpm: fix incompatible casting on big endian (2013-10-23 16:25:18 -0400) Alex Deucher (3): drm/radeon: use sw CTS/N values for audio on DCE4+ drm/radeon: disable bapm on KB drm/radeon/dpm: fix incompatible casting on big endian drivers/gpu/drm/radeon/evergreen_hdmi.c | 1 + drivers/gpu/drm/radeon/kv_dpm.c | 2 +- drivers/gpu/drm/radeon/radeon.h | 4 ++-- 3 files changed, 4 insertions(+), 3 deletions(-)
[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #20 from darkbasic --- Interesting... what may be the difference between your 7950 and mine? Is there a dev who has any clue? If you want I can make a video, I don't think you realize how *SLOW* it is, you can't even type something in Konsole without going crazy :) I just switched to fglrx after 4 years with just FOSS drivers and KDE is quite fast (but not as fast as with my HD4000), anyway even the slow radeon was better than fglrx in Left 4 Dead 2 (framerate is high with fglrx but still the game is unplayable). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131025/3fcff0b6/attachment.html>
[Bug 34495] Selecting objects in Blender 2.56 slow with gallium r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=34495 --- Comment #72 from kao_chen --- Ok thanks, it seems that mesa 9.2 is approaching Debian testing: http://packages.qa.debian.org/m/mesa.html I will wait. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131025/a3fe9992/attachment-0001.html>
[Intel-gfx] drm/i915: Avoid accessing the stolen address when it is unavailable
On Fri, Oct 25, 2013 at 12:27:42AM +, Liu, Chuansheng wrote: > Hello Chris and Ben, > > > -Original Message- > > From: Ben Widawsky [mailto:ben at bwidawsk.net] > > Sent: Friday, October 25, 2013 4:57 AM > > To: Chris Wilson; Liu, Chuansheng; daniel.vetter at ffwll.ch; airlied at > > linux.ie; > > intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; > > linux-kernel at vger.kernel.org; Li, Fei > > Subject: Re: [Intel-gfx] drm/i915: Avoid accessing the stolen address when > > it is > > unavailable > > > > On Thu, Oct 24, 2013 at 01:17:06PM +0100, Chris Wilson wrote: > > > On Fri, Oct 25, 2013 at 12:33:47AM +0800, Chuansheng Liu wrote: > > > > > > > > In our platform, we hit the the stolen region initialization failure > > > > case, > > > > such as below log: > > > > [drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen > > region: [0x7b00] > > > > > > > > And it causes the dev_priv->mm.stolen_base is NULL, in this case, we > > should > > > > avoid accessing it any more. > > > > > > > > Here is possible call trace: > > > > intel_enable_gt_powersave -- > > > > > valleyview_enable_rps -- > > > > > valleyview_setup_pctx > > > > > > The two create_stolen routines are no-ops in that case so all that > > > happens instead is that we read VLV_PCBR. However, really if > > > i915_gem_object_create_stolen_for_preallocated() fails we should abort > > > loading the driver as it means we have a hardware conflict and undefined > > > behaviour. > In case of dev_priv->mm.stolen_base == NULL, and the valleyview_setup_pctx() > is called > at the first time, it will call > i915_gem_object_create_stolen_for_preallocated(), which should > should return NULL always due to (!drm_mm_initialized(_priv->mm.stolen)). > > After that, every time specially when doing pm operation, the above scenario > will > be called again and again. > > Here this patch is to save some time for PM operation, we do not need to read > VLV_PCBR and pcbr_offset calculation in case of stolen_base == NULL. > > Is it making sense? Thanks. I see. No, it is a pointless optimisation that leaks knowledge about internals of another subsystem to paper over a kernel bug. -Chris -- Chris Wilson, Intel Open Source Technology Centre
3.12-rc6 nouveau oops
> Booting 3.12-rc6 on my macbook quickly freezes after logging in to X. I > was able to capture this oops. It's 100% consistent. 3.11 works > perfectly fine, as did previous kernels. Can you boot with nouveau.runpm=0 and see if it boots and survives suspend/resume. Dave.
[Bug 34495] Selecting objects in Blender 2.56 slow with gallium r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=34495 --- Comment #71 from hapoofesgeli at goingon.ir --- (In reply to comment #70) > I wonder if the fix has been committed? I am using Debian testing with the > mesa 9.1-7 package provided in the testing repository, and the selections > with Blender are still very slow. It has been merged to master in mesa 9.2. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131025/6eb36a83/attachment-0001.html>
drm/i915: Avoid accessing the stolen address when it is unavailable
In our platform, we hit the the stolen region initialization failure case,
such as below log:
[drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen region:
[0x7b00]
And it causes the dev_priv->mm.stolen_base is NULL, in this case, we should
avoid accessing it any more.
Here is possible call trace:
intel_enable_gt_powersave -- >
valleyview_enable_rps -- >
valleyview_setup_pctx
Cc: Li Fei
Signed-off-by: Liu, Chuansheng
---
drivers/gpu/drm/i915/intel_pm.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 26c2ea3..1069b24 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3735,6 +3735,9 @@ static void valleyview_setup_pctx(struct drm_device *dev)
u32 pcbr;
int pctx_size = 24*1024;
+ if (!dev_priv->mm.stolen_base)
+ return;
+
pcbr = I915_READ(VLV_PCBR);
if (pcbr) {
/* BIOS set it up already, grab the pre-alloc'd space */
--
1.7.9.5
[Intel-gfx] drm/i915: Avoid accessing the stolen address when it is unavailable
Hello Chris and Ben, > -Original Message- > From: Ben Widawsky [mailto:ben at bwidawsk.net] > Sent: Friday, October 25, 2013 4:57 AM > To: Chris Wilson; Liu, Chuansheng; daniel.vetter at ffwll.ch; airlied at > linux.ie; > intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; > linux-kernel at vger.kernel.org; Li, Fei > Subject: Re: [Intel-gfx] drm/i915: Avoid accessing the stolen address when it > is > unavailable > > On Thu, Oct 24, 2013 at 01:17:06PM +0100, Chris Wilson wrote: > > On Fri, Oct 25, 2013 at 12:33:47AM +0800, Chuansheng Liu wrote: > > > > > > In our platform, we hit the the stolen region initialization failure case, > > > such as below log: > > > [drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen > region: [0x7b00] > > > > > > And it causes the dev_priv->mm.stolen_base is NULL, in this case, we > should > > > avoid accessing it any more. > > > > > > Here is possible call trace: > > > intel_enable_gt_powersave -- > > > > valleyview_enable_rps -- > > > > valleyview_setup_pctx > > > > The two create_stolen routines are no-ops in that case so all that > > happens instead is that we read VLV_PCBR. However, really if > > i915_gem_object_create_stolen_for_preallocated() fails we should abort > > loading the driver as it means we have a hardware conflict and undefined > > behaviour. In case of dev_priv->mm.stolen_base == NULL, and the valleyview_setup_pctx() is called at the first time, it will call i915_gem_object_create_stolen_for_preallocated(), which should should return NULL always due to (!drm_mm_initialized(_priv->mm.stolen)). After that, every time specially when doing pm operation, the above scenario will be called again and again. Here this patch is to save some time for PM operation, we do not need to read VLV_PCBR and pcbr_offset calculation in case of stolen_base == NULL. Is it making sense? Thanks. > > I agree. We should start treating these things as errors since no > RPS/RC6 is essentially not what anyone wants. > > DRM_DEBUG_DRIVER, and add a check in valleyview_enable_rps for the pctx > value. The pctx is already checked in valleyview_disable_rps(). Do we need more checking in case of pctx == NULL?
