[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #11 from Timoth?e Ravier --- Created attachment 84362 --> https://bugs.freedesktop.org/attachment.cgi?id=84362&action=edit X server logs Note: if I quickly kill the second mplayer right after the start of the video I can avoid the crash, but UVD won't work anymore and mplayer will permanently end with some errors (if VDPAU is forced): Selected video codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (VDPAU acceleration) [libavcodec] Selected audio codec: ATSC A/52A (AC-3) [libavcodec] AUDIO: 48000 Hz, 2 ch, floatle, 384.0 kbit/12.50% (ratio: 48000->384000) AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample) Starting playback... VIDEO: 1280x720 23.976 fps0.0 kbps ( 0.0 kB/s) VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU acceleration [ vdpau] Failed creating VDPAU decoder: An invalid/unsupported VdpDecoderProfile value was supplied. FATAL: Cannot initialize video driver. VIDEO: 1280x720 23.976 fps0.0 kbps ( 0.0 kB/s) VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU acceleration [ vdpau] Failed creating VDPAU decoder: An invalid/unsupported VdpDecoderProfile value was supplied. FATAL: Cannot initialize video driver. [h264_vdpau @ 0x7f736c111cc0]decode_slice_header error [h264_vdpau @ 0x7f736c111cc0]no frame! Error while decoding frame! FATAL: Could not initialize video filters (-vf) or video output (-vo). But right after that my X session was killed and the X server kept exiting with bus errors when starting new ones (see attached log). -- 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/20130820/ed3a46ec/attachment.html>
Re: [PATCH/RFC v3 06/19] video: display: OF support
Hi Philipp,
On Tuesday 13 August 2013 16:37:07 Philipp Zabel wrote:
> Hi Laurent,
>
> thanks for this update. I'm very happy about the move to the display entity
> model, given that the i.MX6 IPU has both drm/display and v4l2/capture ports
> in a single device - this will allow to use a unified device tree binding
> scheme.
Thanks for the support :-)
> I'm still trying to see how this all fits together, so far I have only one
> comment, below.
>
> Am Freitag, den 09.08.2013, 19:14 +0200 schrieb Laurent Pinchart:
> [...]
>
> > +static int display_of_parse_dt(struct display_entity_notifier *notifier,
> > + struct list_head *entities,
> > + struct device_node *node)
> > +{
> > + struct display_entity_of *entity;
> > + struct device_node *remote;
> > + struct device_node *ep = NULL;
> > + struct device_node *next;
> > + unsigned int num_entities = 0;
> > + int ret = 0;
> > +
> > + /* Walk the device tree and build a list of nodes. */
> > + dev_dbg(notifier->dev, "parsing node %s\n", node->full_name);
> > +
> > + while (1) {
> > + next = display_of_get_next_endpoint(node, ep);
> > + if (next == NULL)
> > + break;
> > +
> > + of_node_put(ep);
> > + ep = next;
> > +
> > + dev_dbg(notifier->dev, "handling endpoint %s\n", ep->full_name);
> > +
> > + remote = display_of_get_remote_port_parent(ep);
> > + if (remote == NULL)
> > + continue;
> > +
> > + /* Skip entities that we have already processed. */
> > + if (display_of_find_entity(entities, remote) || remote == node)
> > {
> > + dev_dbg(notifier->dev,
> > + "entity %s already in list, skipping\n",
> > + remote->full_name);
> > + continue;
> > + }
>
> device tree nodes with status = "disabled" should be skipped here:
>
> if (!of_device_is_available(remote)) {
> dev_dbg(notifier->dev,
> "entity %s is disabled, skipping\n",
> remote->full_name);
> continue;
> }
>
> Otherwise the completion notification will never be delivered if there
> are any disabled entities in the graph.
That's a good point, but if a device is disabled, why would it be in the DT
graph in the first place ? Do you have a use case for this ?
> > + entity = kzalloc(sizeof(*entity), GFP_KERNEL);
> > + if (entity == NULL) {
> > + of_node_put(remote);
> > + ret = -ENOMEM;
> > + break;
> > + }
> > +
> > + dev_dbg(notifier->dev, "adding remote entity %s to list\n",
> > + remote->full_name);
> > +
> > + entity->node = remote;
> > + list_add_tail(&entity->list, entities);
> > + num_entities++;
> > + }
> > +
> > + of_node_put(ep);
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > + return num_entities;
> > +}
>
> [...]
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
Quoting Fabio Estevam (2013-08-20 08:40:52) > On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote: > > > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > index 5a90a72..90e923e 100644 > > --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > @@ -89,8 +89,6 @@ clocks and IDs. > > gpu3d_shader74 > > ipu1_podf 75 > > ipu2_podf 76 > > - ldb_di0_podf77 > > - ldb_di1_podf78 > > ipu1_di0_pre79 > > ipu1_di1_pre80 > > ipu2_di0_pre81 > > This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc How does this fit in with the idea of having a stable binding/ABI? Seems like changing this would be a bad idea for devices in the field that have older DTBs. Regards, Mike > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
i915 producing warnings with kernel 3.11-rc5
I see lots of warning like this with 3.11-rc5 on my thinkpad t40. [197481.739272] [drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.flags (expected 1, found 0) [197481.739283] [ cut here ] [197481.739352] WARNING: CPU: 0 PID: 556 at drivers/gpu/drm/i915/intel_display.c:8286 check_crtc_state+0x5cf/0xa50 [i915]() [197481.739355] pipe state doesn't match! [197481.739358] Modules linked in: fuse ebtable_nat xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 bridge nf_defrag_ipv6 stp llc iptable_nat nf_nat_ipv4 nf_nat be2iscsi iscsi_boot_sysfs iptable_mangle bnx2i nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack lockd nf_conntrack sunrpc cnic ebtable_filter uio cxgb4i cxgb4 ebtables ip6table_filter ip6_tables cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp rfcomm libiscsi scsi_transport_iscsi bnep arc4 iwldvm mac80211 btusb snd_hda_codec_hdmi iwlwifi snd_hda_codec_conexant snd_hda_intel snd_hda_codec bluetooth vhost_net cfg80211 tun macvtap macvlan iTCO_wdt uvcvideo iTCO_vendor_support snd_usb_audio vhost snd_usbmidi_lib videobuf2_vmalloc [197481.739440] snd_hwdep kvm_intel videobuf2_memops videobuf2_core videodev snd_rawmidi thinkpad_acpi e1000e kvm snd_seq rfkill i2c_i801 snd_seq_device snd_pcm snd_page_alloc snd_timer pcspkr lpc_ich mfd_core snd ptp tpm_tis pps_core wmi soundcore tpm tpm_bios binfmt_misc uinput i915 firewire_ohci firewire_core crc_itu_t i2c_algo_bit drm_kms_helper sdhci_pci sdhci drm mmc_core i2c_core video [197481.739492] CPU: 0 PID: 556 Comm: X Tainted: GW3.11.0-rc5-mst #253 [197481.739497] Hardware name: LENOVO 4243BQ9/4243BQ9, BIOS 8AET57WW (1.37 ) 04/05/2012 [197481.739501] 205e 88020be47828 81672e9d 88020be47868 [197481.739509] 8105c52c 88021270fc70 88021241d000 [197481.739516] 0001 88021270fc78 88021270f800 88020be47948 [197481.739523] Call Trace: [197481.739537] [] dump_stack+0x6a/0x7d [197481.739547] [] warn_slowpath_common+0x8c/0xc0 [197481.739555] [] warn_slowpath_fmt+0x6e/0x70 [197481.739589] [] ? i915_read32+0x75/0x130 [i915] [197481.739617] [] ? i915_read32+0x75/0x130 [i915] [197481.739657] [] ? intel_lvds_get_config+0x45/0xb0 [i915] [197481.739692] [] check_crtc_state+0x5cf/0xa50 [i915] [197481.739730] [] intel_modeset_check_state+0x2e5/0x7c0 [i915] [197481.739758] [] ? i915_write32+0xdb/0x140 [i915] [197481.739792] [] intel_crt_dpms+0x8c/0xd0 [i915] [197481.739826] [] drm_mode_obj_set_property_ioctl+0x393/0x3b0 [drm] [197481.739854] [] drm_mode_connector_property_set_ioctl+0x32/0x40 [drm] [197481.739880] [] drm_ioctl+0x3da/0x660 [drm] [197481.739893] [] ? __free_pages+0x45/0x50 [197481.739923] [] ? drm_mode_obj_set_property_ioctl+0x3b0/0x3b0 [drm] [197481.739933] [] ? file_has_perm+0xaa/0xb0 [197481.739977] [] i915_compat_ioctl+0x45/0x50 [i915] [197481.739985] [] compat_sys_ioctl+0x106/0x13a0 [197481.739994] [] ? file_sb_list_del+0x49/0x50 [197481.740001] [] ? task_work_add+0x55/0x70 [197481.740008] [] ? fput+0x75/0xb0 [197481.740017] [] ? __audit_syscall_exit+0x23b/0x2e0 [197481.740027] [] sysenter_dispatch+0x7/0x21 [197481.740031] ---[ end trace 60b3bfa00b791b28 ]--- The graphics card is: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) Anyone interested in debugging the source of these warnings? -- MST ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 00/19] Common Display Framework
On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart wrote: > Hi Rob, > > On Tuesday 13 August 2013 20:43:50 Rob Clark wrote: >> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote: >> > Hi everybody, >> > >> > Here's the third RFC of the Common Display Framework. >> > >> > I won't repeat all the background information from the versions one and >> > two here, you can read it at http://lwn.net/Articles/512363/ and >> > http://lwn.net/Articles/526965/. >> > >> > This RFC isn't final. Given the high interest in CDF and the urgent tasks >> > that kept delaying the next version of the patch set, I've decided to >> > release v3 before completing all parts of the implementation. Known >> > missing items are >> > >> > - documentation: kerneldoc and this cover letter should provide basic >> > information, more extensive documentation will likely make it to v4. >> > >> > - pipeline configuration and control: generic code to configure and >> > control display pipelines (in a nutshell, translating high-level mode >> > setting and DPMS calls to low-level entity operations) is missing. Video >> > and stream control operations have been carried over from v2, but will >> > need to be revised for v4. >> > >> > - DSI support: I still have no DSI hardware I can easily test the code on. >> >> tbh, I kinda think that DSI and bridge chips are the things we should focus >> on first.. that seems what is most important for current and new hardware. >> Back-filling to handle older/simpler panels can be done later. > > That sounds reasonable (although I still believe DSI is only part of the > issue), but I'll need help with that, as the Renesas platforms I work on don't > have a DSI bus. > >> > Special thanks go to >> > >> > - Renesas for inviting me to LinuxCon Japan 2013 where I had the >> > opportunity to validate the CDF v3 concepts with Alexandre Courbot >> > (NVidia) and Tomasz Figa (Samsung). >> > >> > - Tomi Valkeinen (TI) for taking the time to deeply brainstorm v3 with me. >> > >> > - Linaro for inviting me to Linaro Connect Europe 2013, the discussions we >> > had there greatly helped moving CDF forward. >> > >> > - And of course all the developers who showed interest in CDF and spent >> > time sharing ideas, reviewing patches and testing code. >> > >> > I have to confess I was a bit lost and discouraged after all the CDF- >> > related meetings during which we have discussed how to move from v2 to v3. >> > With every meeting I was hoping to run the implementation through use >> > cases of various interesting parties and narrow down the scope of the huge >> > fuzzy beast that CDF was. With every meeting the scope actually broadened, >> > with no clear path at sight anywhere. >> > >> > Earlier this year I was about to drop one of the requirements on which I >> > had based CDF v2: sharing drivers between DRM/KMS and V4L2. With only two >> > HDMI transmitters as use cases for that feature (with only out-of-tree >> > drivers so far), I just thought the involved completely wasn't worth it >> > and that I should implement CDF v3 as a DRM/KMS-only helper framework. >> > However, a seemingly unrelated discussion with Xilinx developers showed >> > me that hybrid SoC-FPGA platforms such as the Xilinx Zynq 7000 have a >> > larger library of IP cores that can be used in camera capture pipelines >> > and in display pipelines. The two use cases suddenly became tens or even >> > hundreds of use cases that I couldn't ignore anymore. >> >> Hmm, I'm still not really convinced ;-) >> >> Or maybe, put another way, I still think we should still optimize for the >> common case. I mean I'm sure you *can* design hw that has an LVDS->DP bridge >> in the capture path, and if you had something like an FPGA where that was >> cheap to do maybe you even would (for fun). But if in the real world, there >> are only one or two cases of actual hw using the same bridge in a capture >> pipeline which is normally used in display pipelines, then duplicating some >> small bit of code for that abnormal case if it makes things easier for the >> common case, seems like a reasonable trade-off to me. > > That was my opinion as well until I started working on a Xilinx platform. > There's dozens of IP cores there that are used in both capture and display > pipelines. or maybe just some helper lib's to handling the register level programming? Anyways, I guess you can call it a "worse is better" thing, but if you can get 90% of the desired effect for 10% of the work, take the simpler solution. I don't think we should make things more layered or more difficult for one exceptional case. > Furthermore, FPGA display pipelines being made of individual IP cores, we need > a way to write one driver per IP core and make them all interact. The recently > proposed drm_bridge is one possible solution to this issue (and to a different > but similar issue that trigerred the development of drm_bridge), but it's in > my opinion not generic enough. We're facin
Re: [PATCH/RFC v3 00/19] Common Display Framework
Hi Rob, On Tuesday 13 August 2013 20:43:50 Rob Clark wrote: > On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote: > > Hi everybody, > > > > Here's the third RFC of the Common Display Framework. > > > > I won't repeat all the background information from the versions one and > > two here, you can read it at http://lwn.net/Articles/512363/ and > > http://lwn.net/Articles/526965/. > > > > This RFC isn't final. Given the high interest in CDF and the urgent tasks > > that kept delaying the next version of the patch set, I've decided to > > release v3 before completing all parts of the implementation. Known > > missing items are > > > > - documentation: kerneldoc and this cover letter should provide basic > > information, more extensive documentation will likely make it to v4. > > > > - pipeline configuration and control: generic code to configure and > > control display pipelines (in a nutshell, translating high-level mode > > setting and DPMS calls to low-level entity operations) is missing. Video > > and stream control operations have been carried over from v2, but will > > need to be revised for v4. > > > > - DSI support: I still have no DSI hardware I can easily test the code on. > > tbh, I kinda think that DSI and bridge chips are the things we should focus > on first.. that seems what is most important for current and new hardware. > Back-filling to handle older/simpler panels can be done later. That sounds reasonable (although I still believe DSI is only part of the issue), but I'll need help with that, as the Renesas platforms I work on don't have a DSI bus. > > Special thanks go to > > > > - Renesas for inviting me to LinuxCon Japan 2013 where I had the > > opportunity to validate the CDF v3 concepts with Alexandre Courbot > > (NVidia) and Tomasz Figa (Samsung). > > > > - Tomi Valkeinen (TI) for taking the time to deeply brainstorm v3 with me. > > > > - Linaro for inviting me to Linaro Connect Europe 2013, the discussions we > > had there greatly helped moving CDF forward. > > > > - And of course all the developers who showed interest in CDF and spent > > time sharing ideas, reviewing patches and testing code. > > > > I have to confess I was a bit lost and discouraged after all the CDF- > > related meetings during which we have discussed how to move from v2 to v3. > > With every meeting I was hoping to run the implementation through use > > cases of various interesting parties and narrow down the scope of the huge > > fuzzy beast that CDF was. With every meeting the scope actually broadened, > > with no clear path at sight anywhere. > > > > Earlier this year I was about to drop one of the requirements on which I > > had based CDF v2: sharing drivers between DRM/KMS and V4L2. With only two > > HDMI transmitters as use cases for that feature (with only out-of-tree > > drivers so far), I just thought the involved completely wasn't worth it > > and that I should implement CDF v3 as a DRM/KMS-only helper framework. > > However, a seemingly unrelated discussion with Xilinx developers showed > > me that hybrid SoC-FPGA platforms such as the Xilinx Zynq 7000 have a > > larger library of IP cores that can be used in camera capture pipelines > > and in display pipelines. The two use cases suddenly became tens or even > > hundreds of use cases that I couldn't ignore anymore. > > Hmm, I'm still not really convinced ;-) > > Or maybe, put another way, I still think we should still optimize for the > common case. I mean I'm sure you *can* design hw that has an LVDS->DP bridge > in the capture path, and if you had something like an FPGA where that was > cheap to do maybe you even would (for fun). But if in the real world, there > are only one or two cases of actual hw using the same bridge in a capture > pipeline which is normally used in display pipelines, then duplicating some > small bit of code for that abnormal case if it makes things easier for the > common case, seems like a reasonable trade-off to me. That was my opinion as well until I started working on a Xilinx platform. There's dozens of IP cores there that are used in both capture and display pipelines. Furthermore, FPGA display pipelines being made of individual IP cores, we need a way to write one driver per IP core and make them all interact. The recently proposed drm_bridge is one possible solution to this issue (and to a different but similar issue that trigerred the development of drm_bridge), but it's in my opinion not generic enough. We're facing several problems that are related, it would really be a shame not to solve them with a good enough framework. > I mean, take a DSI panel driver, for example.. anything but a trivial panel > driver, you are going to want to expose some custom properties on the > connector for controlling non-standard features. So you end up with both > cdf_foo for the common part, and drm_foo for gluing in the properties. And > now these two parts which otherwise would b
Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
Hi Rob,
On Tuesday 13 August 2013 20:52:15 Rob Clark wrote:
> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
> > MIPI DBI is a configurable-width parallel display bus that transmits
> > commands and data.
> >
> > Add a new DBI Linux bus type that implements the usual bus
> > infrastructure (including devices and drivers (un)registration and
> > matching, and bus configuration and access functions).
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
> > drivers/video/display/Kconfig| 8 ++
> > drivers/video/display/Makefile | 1 +
> > drivers/video/display/mipi-dbi-bus.c | 234 ++
> > include/video/display.h | 4 +
> > include/video/mipi-dbi-bus.h | 125 +++
> > 5 files changed, 372 insertions(+)
> > create mode 100644 drivers/video/display/mipi-dbi-bus.c
> > create mode 100644 include/video/mipi-dbi-bus.h
[snip]
> > diff --git a/include/video/mipi-dbi-bus.h b/include/video/mipi-dbi-bus.h
> > new file mode 100644
> > index 000..876b69d
> > --- /dev/null
> > +++ b/include/video/mipi-dbi-bus.h
[snip]
> > +struct mipi_dbi_device {
> > + const char *name;
> > + int id;
> > + struct device dev;
>
> just fwiw, we need the "framework" to be agnostic of the association between
> devices and entities in the framework. Some things that are multiple
> entities may actually map to a single device in hw
I haven't written down that requirement, but I've kept it in mind while
designing CDF. We have similar use cases in V4L2.
> (and possibly visa versa?).
I don't think that would be needed, but if you can think of a use case I'm all
ears.
> Otherwise we end up having to create fake devices in some cases. Really the
> entities, or objects, or whatever you call 'em should just extend some
> kref'd base class. Sort of like how existing kms objects extend
> drm_mode_object.
struct display_entity {
struct list_head list;
struct device *dev;
struct module *owner;
struct kref ref;
char name[32];
struct media_entity entity;
const struct display_entity_ops *ops;
void(*release)(struct display_entity *ent);
};
(from patch 02/19)
> So any 'struct device' moves down into the derived class, not in the base
> class. Configuration data is passed in separate, not grabbed out of dev->
> platform_data, etc. Probably there is room for some helpers to pull stuff
> out of DT/ACPI/whatever.
struct mipi_dbi_device is not a display entity, it's a physical device plugged
on a DBI bus. It's thus similar in purpose to struct pci_device or struct
platform_device. The DBI device driver will then create one or more display
entities depending on its needs.
> > + const struct mipi_dbi_device_id *id_entry;
> > + struct mipi_dbi_bus *bus;
> > +
> > + unsigned int flags;
> > + unsigned int bus_width;
> > + unsigned int data_width;
> > +};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 --- Comment #5 from prettyvanilla at posteo.at --- I am running a current mainline kernel until dpm stabilises, so I am on 3.11rc6 currently, which has the patch mentioned already applied. Sadly, no change in behaviour. I updated the dmesg output attachment and added xrandr and X.org log output. Anything in particular I should look for to get to the root of the problem? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 --- Comment #4 from prettyvanilla at posteo.at --- Created attachment 107260 --> https://bugzilla.kernel.org/attachment.cgi?id=107260&action=edit Xorg.0.log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 --- Comment #3 from prettyvanilla at posteo.at --- Created attachment 107259 --> https://bugzilla.kernel.org/attachment.cgi?id=107259&action=edit xrandr --verbose -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 prettyvanilla at posteo.at changed: What|Removed |Added Attachment #106381|0 |1 is obsolete|| --- Comment #2 from prettyvanilla at posteo.at --- Created attachment 107258 --> https://bugzilla.kernel.org/attachment.cgi?id=107258&action=edit dmesg output with dvi and displayport connected (drm.debug=0xE) -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm: Use correct spinlock flavor in drm_vblank_get()
The irq flags state is already established by the outer
spin_lock_irqsave(); re-disabling irqs is redundant.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/drm_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index f92da0a..c7d4af5 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -952,13 +952,13 @@ static void drm_update_vblank_count(struct drm_device
*dev, int crtc)
*/
int drm_vblank_get(struct drm_device *dev, int crtc)
{
- unsigned long irqflags, irqflags2;
+ unsigned long irqflags;
int ret = 0;
spin_lock_irqsave(&dev->vbl_lock, irqflags);
/* Going from 0->1 means we have to enable interrupts again */
if (atomic_add_return(1, &dev->vblank_refcount[crtc]) == 1) {
- spin_lock_irqsave(&dev->vblank_time_lock, irqflags2);
+ spin_lock(&dev->vblank_time_lock);
if (!dev->vblank_enabled[crtc]) {
/* Enable vblank irqs under vblank_time_lock protection.
* All vblank count & timestamp updates are held off
@@ -976,7 +976,7 @@ int drm_vblank_get(struct drm_device *dev, int crtc)
drm_update_vblank_count(dev, crtc);
}
}
- spin_unlock_irqrestore(&dev->vblank_time_lock, irqflags2);
+ spin_unlock(&dev->vblank_time_lock);
} else {
if (!dev->vblank_enabled[crtc]) {
atomic_dec(&dev->vblank_refcount[crtc]);
--
1.8.1.2
[Bug 60775] Installing NVIDIA proprietary drivers on kernel 3.10.7-100.fc18.x86_64 errors out . . . can't find kernel source files
https://bugzilla.kernel.org/show_bug.cgi?id=60775 --- Comment #1 from Ryan Letourneau --- Just tried solution here http://ewaldertl.blogspot.ca/2013/02/update-fedora-18-to-kernel-376-let-fail.html but did not resolve issue -- You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
On 08/20/2013 11:40 PM, Fabio Estevam wrote: > On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote: > >> diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt >> b/Documentation/devicetree/bindings/clock/imx6q-clock.txt >> index 5a90a72..90e923e 100644 >> --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt >> +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt >> @@ -89,8 +89,6 @@ clocks and IDs. >> gpu3d_shader74 >> ipu1_podf 75 >> ipu2_podf 76 >> - ldb_di0_podf77 >> - ldb_di1_podf78 >> ipu1_di0_pre79 >> ipu1_di1_pre80 >> ipu2_di0_pre81 > > This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc > I find there is a 'hole' in Documentation/devicetree/bindings/clock/imx5-clock.txt as well. The 'hole' was taken by tve_di(26) clock before. Is this more acceptable? ldb_di0_podf_unused77 ldb_di1_podf_unused78 Liu Ying ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #42 from Alex Deucher --- I can reproduce it in Fedora 17 as well (gcc 4.7). So it seems to be something about Fedora 16 (gcc 4.6). -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #41 from Alex Deucher --- Well, it helps a little, but I'm still able to reproduce it eventually even with the patch. The same kernel source is working fine on a fedora 16 system and now exhibits this problem on Fedora 19. So maybe it's not all gcc. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #40 from queryv+fd at gmail.com --- (In reply to Alex Deucher from comment #39) > Created attachment 107254 [details] > fix for 3.11 > > The attached patch seems to fix it for me. That doesn't seem to fix it for me (6870). I first tried 3.11-rc6 + drm-next-3.12-wip (ee31b2b), and then 3.11-rc6 + the standalone patch you attached. In the former case, when trying to force a performance level I still got: echo: write error: Invalid argument And the power level still idles at: power level 2sclk: 9 mclk: 105000 vddc: 1175 vddci: 1150 gcc --version gcc (GCC) 4.8.1 20130725 (prerelease) -- You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 0/3] refactor some ldb related clocks
On 08/21/2013 09:59 AM, Shawn Guo wrote: > Hi Ying, > > On Tue, Aug 20, 2013 at 06:08:48PM +0800, Liu Ying wrote: >>> While I admit to having introduced the combination of 1/3.5 fixed >>> divider and configurable 1/1,1/2 divder clocks to describe this >>> fractional divider for the reasons you state, I think the correct >>> solution would be to improve the table divider to support fractional >>> values and get rid of the virtual ldb_di_div_3_5 clocks, not >>> introduce more virtual clocks. >> >> Yes, it's good to support fractional values for the table divider(not sure >> if there is any plan for this). >> I see there is something similar in 'include/linux/sh_clk.h'. > > Yeah, I agree with Philipp on improving table divider to support > fractional values. Would you like to work on that? > > Shawn > I don't have a plan to work on that now. Liu Ying ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
i915 producing warnings with kernel 3.11-rc5
I see lots of warning like this with 3.11-rc5 on my thinkpad t40. [197481.739272] [drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.flags (expected 1, found 0) [197481.739283] [ cut here ] [197481.739352] WARNING: CPU: 0 PID: 556 at drivers/gpu/drm/i915/intel_display.c:8286 check_crtc_state+0x5cf/0xa50 [i915]() [197481.739355] pipe state doesn't match! [197481.739358] Modules linked in: fuse ebtable_nat xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 bridge nf_defrag_ipv6 stp llc iptable_nat nf_nat_ipv4 nf_nat be2iscsi iscsi_boot_sysfs iptable_mangle bnx2i nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack lockd nf_conntrack sunrpc cnic ebtable_filter uio cxgb4i cxgb4 ebtables ip6table_filter ip6_tables cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp rfcomm libiscsi scsi_transport_iscsi bnep arc4 iwldvm mac80211 btusb snd_hda_codec_hdmi iwlwifi snd_hda_codec_conexant snd_hda_intel snd_hda_codec bluetooth vhost_net cfg80211 tun macvtap macvlan iTCO_wdt uvcvideo iTCO_vendor_support snd_usb_audio vhost snd_usbmidi_lib videobuf2_vmalloc [197481.739440] snd_hwdep kvm_intel videobuf2_memops videobuf2_core videodev snd_rawmidi thinkpad_acpi e1000e kvm snd_seq rfkill i2c_i801 snd_seq_device snd_pcm snd_page_alloc snd_timer pcspkr lpc_ich mfd_core snd ptp tpm_tis pps_core wmi soundcore tpm tpm_bios binfmt_misc uinput i915 firewire_ohci firewire_core crc_itu_t i2c_algo_bit drm_kms_helper sdhci_pci sdhci drm mmc_core i2c_core video [197481.739492] CPU: 0 PID: 556 Comm: X Tainted: GW3.11.0-rc5-mst #253 [197481.739497] Hardware name: LENOVO 4243BQ9/4243BQ9, BIOS 8AET57WW (1.37 ) 04/05/2012 [197481.739501] 205e 88020be47828 81672e9d 88020be47868 [197481.739509] 8105c52c 88021270fc70 88021241d000 [197481.739516] 0001 88021270fc78 88021270f800 88020be47948 [197481.739523] Call Trace: [197481.739537] [] dump_stack+0x6a/0x7d [197481.739547] [] warn_slowpath_common+0x8c/0xc0 [197481.739555] [] warn_slowpath_fmt+0x6e/0x70 [197481.739589] [] ? i915_read32+0x75/0x130 [i915] [197481.739617] [] ? i915_read32+0x75/0x130 [i915] [197481.739657] [] ? intel_lvds_get_config+0x45/0xb0 [i915] [197481.739692] [] check_crtc_state+0x5cf/0xa50 [i915] [197481.739730] [] intel_modeset_check_state+0x2e5/0x7c0 [i915] [197481.739758] [] ? i915_write32+0xdb/0x140 [i915] [197481.739792] [] intel_crt_dpms+0x8c/0xd0 [i915] [197481.739826] [] drm_mode_obj_set_property_ioctl+0x393/0x3b0 [drm] [197481.739854] [] drm_mode_connector_property_set_ioctl+0x32/0x40 [drm] [197481.739880] [] drm_ioctl+0x3da/0x660 [drm] [197481.739893] [] ? __free_pages+0x45/0x50 [197481.739923] [] ? drm_mode_obj_set_property_ioctl+0x3b0/0x3b0 [drm] [197481.739933] [] ? file_has_perm+0xaa/0xb0 [197481.739977] [] i915_compat_ioctl+0x45/0x50 [i915] [197481.739985] [] compat_sys_ioctl+0x106/0x13a0 [197481.739994] [] ? file_sb_list_del+0x49/0x50 [197481.740001] [] ? task_work_add+0x55/0x70 [197481.740008] [] ? fput+0x75/0xb0 [197481.740017] [] ? __audit_syscall_exit+0x23b/0x2e0 [197481.740027] [] sysenter_dispatch+0x7/0x21 [197481.740031] ---[ end trace 60b3bfa00b791b28 ]--- The graphics card is: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) Anyone interested in debugging the source of these warnings? -- MST
[Bug 60775] New: Installing NVIDIA proprietary drivers on kernel 3.10.7-100.fc18.x86_64 errors out . . . can't find kernel source files
https://bugzilla.kernel.org/show_bug.cgi?id=60775 Bug ID: 60775 Summary: Installing NVIDIA proprietary drivers on kernel 3.10.7-100.fc18.x86_64 errors out . . . can't find kernel source files Product: Drivers Version: 2.5 Kernel Version: Linux 3.10.7-100.fc18.x86_64 SMP Hardware: x86-64 OS: Linux Tree: Fedora Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: letourneau.ryan at gmail.com Regression: No Trying to install NVIDIA-Linux-x86_64-319.32.run proprietary drivers on kernel 3.10.7-100.fc18.x86_64 does not work. Error; "The kernel header file '/usr/src/linux/include/linux/version.h' does not exist. The most likely reason for this is that the kernel source files in '/usr/src/linux' have not been configured." All necessary source rpms are installed ; kernel-headers-3.10.7-100.fc18.x86_64 kernel-devel-3.10.7-100.fc18.x86_64 and all dependencies. Also downloaded kernel source rpm and installed but did not resolve issue; yumdownloader --source kernel rpm -ivh kernel-3.10.7-100.fc18.src.rpm Tried solution here; http://moldvan.com/blog/?p=824 Did not resolve issue when linking /usr/include/linux/version.h to /usr/src/kernels/`uname -r`/include/linux/version.h But once linked, this error pops up; "If you are using a Linux 2.6 kernel, please make sure you have configured kernel sources matching your kernel installed on your system. If you specified a separate output directory using either the \?KBUILD_OUTPUT\? or the \?O\? KBUILD parameter, make sure to specify this directory with the SYSOUT environment variable or with the equivalent nvidia-installer command line option. Depending on where and how the kernel sources (or the kernel headers) were installed, you may need to specify their location with the SYSSRC environment variable or the equivalent nvidia-installer command line option." The NVIDIA proprietary driver does successfully build on kernel 3.6.10-4.fc18.x86_64. Tried uninstalling kernel-headers and kernel-devel rpms and re-installing, did not resolve issue. Expected results would be, for the NVIDIA proprietary drivers to find correct kernel sources, and successfully build and install driver module. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm: Use correct spinlock flavor in drm_vblank_get()
The irq flags state is already established by the outer
spin_lock_irqsave(); re-disabling irqs is redundant.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/drm_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index f92da0a..c7d4af5 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -952,13 +952,13 @@ static void drm_update_vblank_count(struct drm_device
*dev, int crtc)
*/
int drm_vblank_get(struct drm_device *dev, int crtc)
{
- unsigned long irqflags, irqflags2;
+ unsigned long irqflags;
int ret = 0;
spin_lock_irqsave(&dev->vbl_lock, irqflags);
/* Going from 0->1 means we have to enable interrupts again */
if (atomic_add_return(1, &dev->vblank_refcount[crtc]) == 1) {
- spin_lock_irqsave(&dev->vblank_time_lock, irqflags2);
+ spin_lock(&dev->vblank_time_lock);
if (!dev->vblank_enabled[crtc]) {
/* Enable vblank irqs under vblank_time_lock protection.
* All vblank count & timestamp updates are held off
@@ -976,7 +976,7 @@ int drm_vblank_get(struct drm_device *dev, int crtc)
drm_update_vblank_count(dev, crtc);
}
}
- spin_unlock_irqrestore(&dev->vblank_time_lock, irqflags2);
+ spin_unlock(&dev->vblank_time_lock);
} else {
if (!dev->vblank_enabled[crtc]) {
atomic_dec(&dev->vblank_refcount[crtc]);
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] refactor some ldb related clocks
Hi Ying, On Tue, Aug 20, 2013 at 06:08:48PM +0800, Liu Ying wrote: > > While I admit to having introduced the combination of 1/3.5 fixed > > divider and configurable 1/1,1/2 divder clocks to describe this > > fractional divider for the reasons you state, I think the correct > > solution would be to improve the table divider to support fractional > > values and get rid of the virtual ldb_di_div_3_5 clocks, not > > introduce more virtual clocks. > > Yes, it's good to support fractional values for the table divider(not sure if > there is any plan for this). > I see there is something similar in 'include/linux/sh_clk.h'. Yeah, I agree with Philipp on improving table divider to support fractional values. Would you like to work on that? Shawn ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
On Tue, Aug 20, 2013 at 02:18:27PM -0700, Mike Turquette wrote: > Quoting Fabio Estevam (2013-08-20 08:40:52) > > On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote: > > > > > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > > index 5a90a72..90e923e 100644 > > > --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > > +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > > @@ -89,8 +89,6 @@ clocks and IDs. > > > gpu3d_shader74 > > > ipu1_podf 75 > > > ipu2_podf 76 > > > - ldb_di0_podf77 > > > - ldb_di1_podf78 > > > ipu1_di0_pre79 > > > ipu1_di1_pre80 > > > ipu2_di0_pre81 > > > > This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc > > How does this fit in with the idea of having a stable binding/ABI? Seems > like changing this would be a bad idea for devices in the field that > have older DTBs. We should be safe since none of existing DTBs refers to the clocks (they are not leaf clocks in the whole clock tree but some interconnection ones). Shawn ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 Timoth?e Ravier changed: What|Removed |Added Attachment #84347|0 |1 is obsolete|| --- Comment #10 from Timoth?e Ravier --- Created attachment 84354 --> https://bugs.freedesktop.org/attachment.cgi?id=84354&action=edit New dmesg log with patched kernel This is the new dmesg log. I tried the patch but the bug is still here in my case. However the "Bad LCD record" error is different now and some lines in the end are not in the new log. -- 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/20130820/d1331b1c/attachment.html>
[PATCH 0/3] refactor some ldb related clocks
On 08/20/2013 05:43 PM, Philipp Zabel wrote: > Am Dienstag, den 20.08.2013, 16:38 +0800 schrieb Liu Ying: >> The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register >> of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5 >> drivider or a 1/7 divider. The common clock framework cannot >> deal with the two dividers directly even with the divider table >> which only supports integral dividers. So, the idea is to take >> the 1/3.5 and 1/7 dividers as separate fixed factor dividers and >> introduce a new multiplexer clock to be derived from the them. >> Then, the ldb display clock trees can be setup correctly. >> This series contains the necessary clock driver changes, dts code >> changes and imx-drm/ldb driver changes to fullfill the task. > > I don't see how this improves the situation. Does this solve any real > problem? > I don't see any functional problem without this series. But, it may correct ldb_di[n] clock frequency returned from clk_get_rate() when using 1/7 divider. Furthermore, since this series makes the ldb related clocks from pll to ldb_di[0/1] have the CLK_SET_RATE_PARENT flag set, the imx-drm/ldb driver may set the clocks' frequency more flexibly, i.e., only calling clk_set_rate() for ldb_di[n] clock would be an alternative. > While I admit to having introduced the combination of 1/3.5 fixed > divider and configurable 1/1,1/2 divder clocks to describe this > fractional divider for the reasons you state, I think the correct > solution would be to improve the table divider to support fractional > values and get rid of the virtual ldb_di_div_3_5 clocks, not > introduce more virtual clocks. Yes, it's good to support fractional values for the table divider(not sure if there is any plan for this). I see there is something similar in 'include/linux/sh_clk.h'. > > regards > Philipp > > Regards, Liu Ying
[PATCH] drm/radeon/atombios: fix variable sized arrays for newer gccs (v2)
Ignore this patch for now. there are still problems with newer gcc
versions that aren't fixed yet.
Alex
On Tue, Aug 20, 2013 at 1:16 PM, Alex Deucher wrote:
> Newer versions of gcc seem to wander off into no-man's land
> when using variably sized arrays. Atombios tends to do things
> like:
>
> struct object {
> u8 version;
> u8 num_elements;
> u32 elements[1]; /* num_elements entries */
> };
>
> We then do things like the following in the driver code:
>
> for (i = 0; i < atom_object->num_elements; i++) {
> driver_object[i] = atom_object->elements[i];
> }
>
> With previous versions of gcc this used to work fine, but with
> 4.7 and 4.8, it seems to generate code that wanders off into the
> weeds.
>
> According to:
> http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> The traditional way of handling variably sized arrays (ISO C90)
> is to use an array length of 1. Gcc allows you to use an array
> length of 0 and newer versions of gcc only seem to do the
> right thing when 0 is used.
>
> This is tricky in this case because atombios.h is shared between
> multiple components and is used for allocation in the vbios.
>
> v2: update commit message
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/radeon/atombios.h | 100
> +++---
> 1 file changed, 50 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios.h
> b/drivers/gpu/drm/radeon/atombios.h
> index 16b120c..3f1f011 100644
> --- a/drivers/gpu/drm/radeon/atombios.h
> +++ b/drivers/gpu/drm/radeon/atombios.h
> @@ -3592,7 +3592,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD
> {
>UCHAR ucRecordType;
>UCHAR ucFakeEDIDLength;
> - UCHAR ucFakeEDIDString[1];// This actually has ucFakeEdidLength
> elements.
> + UCHAR ucFakeEDIDString[0];// This actually has ucFakeEdidLength
> elements.
> } ATOM_FAKE_EDID_PATCH_RECORD;
>
> typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD
> @@ -3868,7 +3868,7 @@ typedef struct _ATOM_GPIO_PIN_ASSIGNMENT
> typedef struct _ATOM_GPIO_PIN_LUT
> {
>ATOM_COMMON_TABLE_HEADER sHeader;
> - ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[1];
> + ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[0];
> }ATOM_GPIO_PIN_LUT;
>
>
> //
> @@ -3995,7 +3995,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH
>USHORTusSize;//the size of
> ATOM_DISPLAY_OBJECT_PATH
>USHORTusConnObjectId;//Connector
> Object ID
>USHORTusGPUObjectId; //GPU ID
> - USHORTusGraphicObjIds[1]; //1st Encoder
> Obj source from GPU to last Graphic Obj destinate to connector.
> + USHORTusGraphicObjIds[0]; //1st Encoder
> Obj source from GPU to last Graphic Obj destinate to connector.
> }ATOM_DISPLAY_OBJECT_PATH;
>
> typedef struct _ATOM_DISPLAY_EXTERNAL_OBJECT_PATH
> @@ -4012,7 +4012,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH_TABLE
>UCHAR ucNumOfDispPath;
>UCHAR ucVersion;
>UCHAR ucPadding[2];
> - ATOM_DISPLAY_OBJECT_PATHasDispPath[1];
> + ATOM_DISPLAY_OBJECT_PATHasDispPath[0];
> }ATOM_DISPLAY_OBJECT_PATH_TABLE;
>
>
> @@ -4028,15 +4028,15 @@ typedef struct _ATOM_OBJECT_TABLE
> //Above 4 object table
> {
>UCHAR ucNumberOfObjects;
>UCHAR ucPadding[3];
> - ATOM_OBJECT asObjects[1];
> + ATOM_OBJECT asObjects[0];
> }ATOM_OBJECT_TABLE;
>
> typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT
> //usSrcDstTableOffset pointing to this structure
> {
>UCHAR ucNumberOfSrc;
> - USHORT usSrcObjectID[1];
> + USHORT usSrcObjectID[0];
>UCHAR ucNumberOfDst;
> - USHORT usDstObjectID[1];
> + USHORT usDstObjectID[0];
> }ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;
>
>
> @@ -4208,7 +4208,7 @@ typedef struct _ATOM_CONNECTOR_DEVICE_TAG_RECORD
>ATOM_COMMON_RECORD_HEADER sheader;
>UCHAR ucNumberOfDevice;
>UCHAR ucReserved;
> - ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[1]; //This Id is same as
> "ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
> + ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[0]; //This Id is same as
> "ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
> }ATOM_CONNECTOR_DEVICE_TAG_RECORD;
>
>
> @@ -4268,7 +4268,7 @@ typedef struct _ATOM_OBJECT_GPIO_CNTL_RECORD
>ATOM_COMMON_RECORD_HEADER sheader;
>UCHAR ucFlags;// Future expnadibility
>UCHAR ucNumberOfPins; // Number of GPIO pins
> used to control the object
> - ATOM_GPIO_PIN_CONTROL_PAIR asGpio[1];
Re: [PATCH] nouveau: fix reclocking on nv40
On Mon, Aug 19, 2013 at 4:59 PM, Pali Rohár wrote: > On Friday 16 August 2013 14:57:07 Pali Rohár wrote: >> In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was >> introduced error which cause that reclocking on nv40 not >> working anymore. There is missing assigment of return value >> from pll_calc to ret. >> >> Signed-off-by: Pali Rohár >> Signed-off-by: Martin Peres >> --- >> drivers/gpu/drm/nouveau/nv40_pm.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c >> b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d >> 100644 >> --- a/drivers/gpu/drm/nouveau/nv40_pm.c >> +++ b/drivers/gpu/drm/nouveau/nv40_pm.c >> @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32 >> reg, struct nvbios_pll *pll, if (clk < pll->vco1.max_freq) >> pll->vco2.max_freq = 0; >> >> - pclk->pll_calc(pclk, pll, clk, &coef); >> + ret = pclk->pll_calc(pclk, pll, clk, &coef); >> if (ret == 0) >> return -ERANGE; > > Hello, it is possible to include this patch in 3.11? > Or it is too late now and need to wait for 3.12? I've picked up the patch and will submit it in my next 3.11-fixes pull request. Thanks, Ben. > > -- > Pali Rohár > pali.ro...@gmail.com > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC v3 00/19] Common Display Framework
Hi Rob, On Tuesday 13 August 2013 20:43:50 Rob Clark wrote: > On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote: > > Hi everybody, > > > > Here's the third RFC of the Common Display Framework. > > > > I won't repeat all the background information from the versions one and > > two here, you can read it at http://lwn.net/Articles/512363/ and > > http://lwn.net/Articles/526965/. > > > > This RFC isn't final. Given the high interest in CDF and the urgent tasks > > that kept delaying the next version of the patch set, I've decided to > > release v3 before completing all parts of the implementation. Known > > missing items are > > > > - documentation: kerneldoc and this cover letter should provide basic > > information, more extensive documentation will likely make it to v4. > > > > - pipeline configuration and control: generic code to configure and > > control display pipelines (in a nutshell, translating high-level mode > > setting and DPMS calls to low-level entity operations) is missing. Video > > and stream control operations have been carried over from v2, but will > > need to be revised for v4. > > > > - DSI support: I still have no DSI hardware I can easily test the code on. > > tbh, I kinda think that DSI and bridge chips are the things we should focus > on first.. that seems what is most important for current and new hardware. > Back-filling to handle older/simpler panels can be done later. That sounds reasonable (although I still believe DSI is only part of the issue), but I'll need help with that, as the Renesas platforms I work on don't have a DSI bus. > > Special thanks go to > > > > - Renesas for inviting me to LinuxCon Japan 2013 where I had the > > opportunity to validate the CDF v3 concepts with Alexandre Courbot > > (NVidia) and Tomasz Figa (Samsung). > > > > - Tomi Valkeinen (TI) for taking the time to deeply brainstorm v3 with me. > > > > - Linaro for inviting me to Linaro Connect Europe 2013, the discussions we > > had there greatly helped moving CDF forward. > > > > - And of course all the developers who showed interest in CDF and spent > > time sharing ideas, reviewing patches and testing code. > > > > I have to confess I was a bit lost and discouraged after all the CDF- > > related meetings during which we have discussed how to move from v2 to v3. > > With every meeting I was hoping to run the implementation through use > > cases of various interesting parties and narrow down the scope of the huge > > fuzzy beast that CDF was. With every meeting the scope actually broadened, > > with no clear path at sight anywhere. > > > > Earlier this year I was about to drop one of the requirements on which I > > had based CDF v2: sharing drivers between DRM/KMS and V4L2. With only two > > HDMI transmitters as use cases for that feature (with only out-of-tree > > drivers so far), I just thought the involved completely wasn't worth it > > and that I should implement CDF v3 as a DRM/KMS-only helper framework. > > However, a seemingly unrelated discussion with Xilinx developers showed > > me that hybrid SoC-FPGA platforms such as the Xilinx Zynq 7000 have a > > larger library of IP cores that can be used in camera capture pipelines > > and in display pipelines. The two use cases suddenly became tens or even > > hundreds of use cases that I couldn't ignore anymore. > > Hmm, I'm still not really convinced ;-) > > Or maybe, put another way, I still think we should still optimize for the > common case. I mean I'm sure you *can* design hw that has an LVDS->DP bridge > in the capture path, and if you had something like an FPGA where that was > cheap to do maybe you even would (for fun). But if in the real world, there > are only one or two cases of actual hw using the same bridge in a capture > pipeline which is normally used in display pipelines, then duplicating some > small bit of code for that abnormal case if it makes things easier for the > common case, seems like a reasonable trade-off to me. That was my opinion as well until I started working on a Xilinx platform. There's dozens of IP cores there that are used in both capture and display pipelines. Furthermore, FPGA display pipelines being made of individual IP cores, we need a way to write one driver per IP core and make them all interact. The recently proposed drm_bridge is one possible solution to this issue (and to a different but similar issue that trigerred the development of drm_bridge), but it's in my opinion not generic enough. We're facing several problems that are related, it would really be a shame not to solve them with a good enough framework. > I mean, take a DSI panel driver, for example.. anything but a trivial panel > driver, you are going to want to expose some custom properties on the > connector for controlling non-standard features. So you end up with both > cdf_foo for the common part, and drm_foo for gluing in the properties. And > now these two parts which otherwise would b
[PATCH 2/2] drm/i915: add fast boot support for Haswell
Hi
2013/8/19 Furquan Shaikh :
> Enables getting correct mode clock when reading pipe config
> This patch has been tested successfully on top of drm-intel-nightly tree
>
> Signed-off-by: Furquan Shaikh
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6
> drivers/gpu/drm/i915/intel_ddi.c | 70
>
> drivers/gpu/drm/i915/intel_display.c | 1 +
> 3 files changed, 77 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2b96d6b..9511129 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4970,6 +4970,7 @@
> #define SPLL_PLL_NON_SSC (2<<28)
> #define SPLL_PLL_FREQ_810MHz (0<<26)
> #define SPLL_PLL_FREQ_1350MHz (1<<26)
> +#define SPLL_PLL_FREQ_MASK (3<<26)
>
> /* WRPLL */
> #define WRPLL_CTL1 0x46040
> @@ -4983,6 +4984,10 @@
> #define WRPLL_DIVIDER_POST(x) ((x)<<8)
> #define WRPLL_DIVIDER_FEEDBACK(x) ((x)<<16)
>
> +#define WRPLL_DIVIDER_REFERENCE_BITS(reg)(reg & 0xff)
> +#define WRPLL_DIVIDER_POST_BITS(reg) ((reg >> 8) & 0x3f)
> +#define WRPLL_DIVIDER_FEEDBACK_BITS(reg) ((reg >> 16) & 0xff)
> +
> /* Port clock selection */
> #define PORT_CLK_SEL_A 0x46100
> #define PORT_CLK_SEL_B 0x46104
> @@ -4994,6 +4999,7 @@
> #define PORT_CLK_SEL_WRPLL1 (4<<29)
> #define PORT_CLK_SEL_WRPLL2 (5<<29)
> #define PORT_CLK_SEL_NONE (7<<29)
> +#define PORT_CLK_SEL_MASK (7<<29)
>
> /* Transcoder clock selection */
> #define TRANS_CLK_SEL_A0x46140
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b8c096b..a24a375 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1246,6 +1246,74 @@ static void intel_ddi_hot_plug(struct intel_encoder
> *intel_encoder)
> intel_dp_check_link_status(intel_dp);
> }
>
> +static void intel_ddi_get_clock(struct intel_encoder *encoder,
> + struct intel_crtc_config *pipe_config)
> +{
> + struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> + int port = intel_ddi_get_encoder_port(encoder);
> + u32 temp = I915_READ(PORT_CLK_SEL(port)) & PORT_CLK_SEL_MASK;
> + u8 link_bw;
> +
> + if ((temp == PORT_CLK_SEL_LCPLL_810) ||
> + (temp == PORT_CLK_SEL_LCPLL_1350) ||
> + (temp == PORT_CLK_SEL_LCPLL_2700)) {
> +
> + switch (temp) {
> + case PORT_CLK_SEL_LCPLL_810:
> + link_bw = DP_LINK_BW_1_62;
> + break;
> + case PORT_CLK_SEL_LCPLL_1350:
> + link_bw = DP_LINK_BW_2_7;
> + break;
> + case PORT_CLK_SEL_LCPLL_2700:
> + link_bw = DP_LINK_BW_5_4;
> + break;
> + }
> + pipe_config->port_clock =
> drm_dp_bw_code_to_link_rate(link_bw);
drivers/gpu/drm/i915/intel_ddi.c:1275:56: aviso: ?link_bw? may be used
uninitialized in this function [-Wmaybe-uninitialized]
Looks like gcc 4.7.3 isn't that smart :( You should probably add a
"default" case with a WARN_ON(1) inside it.
> + } else if ((temp == PORT_CLK_SEL_WRPLL1) ||
> + (temp == PORT_CLK_SEL_WRPLL2)) {
> + uint64_t p, n2, r2;
> + u32 val, reg;
> + uint64_t freq2k;
> +
> + switch (temp) {
> + case PORT_CLK_SEL_WRPLL1:
> + reg = WRPLL_CTL1;
> + break;
> + case PORT_CLK_SEL_WRPLL2:
> + reg = WRPLL_CTL2;
> + break;
> + }
> + val = I915_READ(reg);
drivers/gpu/drm/i915/intel_ddi.c:1290:7: aviso: ?reg? may be used
uninitialized in this function [-Wmaybe-uninitialized]
Same thing here.
> + r2 = WRPLL_DIVIDER_REFERENCE_BITS(val);
> + p = WRPLL_DIVIDER_POST_BITS(val);
> + n2 = WRPLL_DIVIDER_FEEDBACK_BITS(val);
> +
> + freq2k = DIV_ROUND_UP_ULL(LC_FREQ * n2, r2 * p);
> + pipe_config->port_clock = freq2k / 10;
If you put the "/ 10" on the line above so it becomes
DIV_ROUND_UP_ULL(LC_FREQ * n2, r2 * p * 10) you'll avoid the rounding
errors of 1 division.
By the way, I applied your patch + Daniel's suggestion on -nightly and
now I see "unclaimed register" errors when booting with HDMI + eDP.
The problem is that we try to read disabled LINK_M/LINK_N registers
due to the power well disabled, so we get the error messages. I also
once saw a "pipe state mismatch" error, but I can't find a way to
reproduce it now. I'm also not sure whether VGA will really work since
we don't touch intel_crt.c (I can't test it for now). When testing the
patches,
[PATCH 8/8] drm: Make drm_get_platform_dev() static
On Tue, Aug 20, 2013 at 07:56:42AM -0700, Ian Romanick wrote:
> On 08/19/2013 04:53 PM, Damien Lespiau wrote:
> >It's only used in drm_platform.c.
> >
> >Signed-off-by: Damien Lespiau
> >---
> > drivers/gpu/drm/drm_platform.c | 7 +++
> > include/drm/drmP.h | 3 ---
> > 2 files changed, 3 insertions(+), 7 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
> >index b8a282e..400024b 100644
> >--- a/drivers/gpu/drm/drm_platform.c
> >+++ b/drivers/gpu/drm/drm_platform.c
> >@@ -28,7 +28,7 @@
> > #include
> > #include
> >
> >-/**
> >+/*
> > * Register.
> > *
> > * \param platdev - Platform device struture
>
> Was this change intentional? The rest of the comment is doxygen still.
It was indeed, just to stop documentation tools from picking up that
symbol that is not exported anymore. The documentation blob still
contains markup to tag the parameters though, might as well leave it
there.
--
Damien
>
> >@@ -39,8 +39,8 @@
> > * Try and register, if we fail to register, backout previous work.
> > */
> >
> >-int drm_get_platform_dev(struct platform_device *platdev,
> >- struct drm_driver *driver)
> >+static int drm_get_platform_dev(struct platform_device *platdev,
> >+struct drm_driver *driver)
> > {
> > struct drm_device *dev;
> > int ret;
> >@@ -107,7 +107,6 @@ err_g1:
> > mutex_unlock(&drm_global_mutex);
> > return ret;
> > }
> >-EXPORT_SYMBOL(drm_get_platform_dev);
> >
> > static int drm_platform_get_irq(struct drm_device *dev)
> > {
> >diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> >index 046a7db..1a7a78f 100644
> >--- a/include/drm/drmP.h
> >+++ b/include/drm/drmP.h
> >@@ -1657,9 +1657,6 @@ extern int drm_pcie_get_speed_cap_mask(struct
> >drm_device *dev, u32 *speed_mask);
> > extern int drm_platform_init(struct drm_driver *driver, struct
> > platform_device *platform_device);
> > extern void drm_platform_exit(struct drm_driver *driver, struct
> > platform_device *platform_device);
> >
> >-extern int drm_get_platform_dev(struct platform_device *pdev,
> >-struct drm_driver *driver);
> >-
> > /* returns true if currently okay to sleep */
> > static __inline__ bool drm_can_sleep(void)
> > {
> >
>
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #9 from Alex Deucher --- You might try this patch: http://people.freedesktop.org/~agd5f/0001-drm-radeon-atombios-fix-variable-sized-arrays-for.patch -- 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/20130820/92adecf1/attachment.html>
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #39 from Alex Deucher --- Created attachment 107254 --> https://bugzilla.kernel.org/attachment.cgi?id=107254&action=edit fix for 3.11 The attached patch seems to fix it for me. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 3/3] staging: drm/imx: ldb: correct the ldb di clock trees
In ldb split mode, the ldb_di[0/1]_ipu_div dividers should
be configured as clock dividers of 1/3.5, while in others
ldb modes of 1/7. This patch gets the di[0/1]_div_3_5,
di[0/1]_div_7 and di[0/1]_div_sel clocks and sets the
di[0/1]_div_3_5 or di[0/1]_div_7 clocks to be the parents of
di[0/1]_div_sel clocks according to the ldb mode. The real
dividers are the two fixed factors bewteen the ldb_di[0/1] and
the pll clocks, so it's unnecessary to set the frequency for
the ldb_di[0/1] clocks again after pll clock frequency is set.
This patch removes the redundant clock frequency setting code
as well.
Signed-off-by: Liu Ying
---
drivers/staging/imx-drm/imx-ldb.c | 38 +
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-ldb.c
b/drivers/staging/imx-drm/imx-ldb.c
index 8af7f3b..7c553b8 100644
--- a/drivers/staging/imx-drm/imx-ldb.c
+++ b/drivers/staging/imx-drm/imx-ldb.c
@@ -81,6 +81,9 @@ struct imx_ldb {
struct clk *clk[2]; /* our own clock */
struct clk *clk_sel[4]; /* parent of display clock */
struct clk *clk_pll[2]; /* upstream clock we can adjust */
+ struct clk *clk_div_3_5[2]; /* fixed factor of 1/3.5 */
+ struct clk *clk_div_7[2]; /* fixed factor of 1/7 */
+ struct clk *clk_div_sel[2]; /* 1/3.5 or 1/7 */
u32 ldb_ctrl;
const struct bus_mux *lvds_mux;
};
@@ -150,6 +153,18 @@ static void imx_ldb_set_clock(struct imx_ldb *ldb, int
mux, int chno,
{
int ret;
+ if (ldb->ldb_ctrl & LDB_SPLIT_MODE_EN) {
+ ret = clk_set_parent(ldb->clk_div_sel[chno],
ldb->clk_div_3_5[chno]);
+ if (ret)
+ dev_err(ldb->dev, "unable to set di%d_div_sel parent
clock "
+ "to di%d_div_3_5\n", chno, chno);
+ } else {
+ ret = clk_set_parent(ldb->clk_div_sel[chno],
ldb->clk_div_7[chno]);
+ if (ret)
+ dev_err(ldb->dev, "unable to set di%d_div_sel parent
clock "
+ "to di%d_div_7\n", chno, chno);
+ }
+
dev_dbg(ldb->dev, "%s: now: %ld want: %ld\n", __func__,
clk_get_rate(ldb->clk_pll[chno]), serial_clk);
clk_set_rate(ldb->clk_pll[chno], serial_clk);
@@ -157,14 +172,6 @@ static void imx_ldb_set_clock(struct imx_ldb *ldb, int
mux, int chno,
dev_dbg(ldb->dev, "%s after: %ld\n", __func__,
clk_get_rate(ldb->clk_pll[chno]));
- dev_dbg(ldb->dev, "%s: now: %ld want: %ld\n", __func__,
- clk_get_rate(ldb->clk[chno]),
- (long int)di_clk);
- clk_set_rate(ldb->clk[chno], di_clk);
-
- dev_dbg(ldb->dev, "%s after: %ld\n", __func__,
- clk_get_rate(ldb->clk[chno]));
-
/* set display clock mux to LDB input clock */
ret = clk_set_parent(ldb->clk_sel[mux], ldb->clk[chno]);
if (ret) {
@@ -362,6 +369,21 @@ static int imx_ldb_get_clk(struct imx_ldb *ldb, int chno)
if (IS_ERR(ldb->clk_pll[chno]))
return PTR_ERR(ldb->clk_pll[chno]);
+ sprintf(clkname, "di%d_div_3_5", chno);
+ ldb->clk_div_3_5[chno] = devm_clk_get(ldb->dev, clkname);
+ if (IS_ERR(ldb->clk_div_3_5[chno]))
+ return PTR_ERR(ldb->clk_div_3_5[chno]);
+
+ sprintf(clkname, "di%d_div_7", chno);
+ ldb->clk_div_7[chno] = devm_clk_get(ldb->dev, clkname);
+ if (IS_ERR(ldb->clk_div_7[chno]))
+ return PTR_ERR(ldb->clk_div_7[chno]);
+
+ sprintf(clkname, "di%d_div_sel", chno);
+ ldb->clk_div_sel[chno] = devm_clk_get(ldb->dev, clkname);
+ if (IS_ERR(ldb->clk_div_sel[chno]))
+ return PTR_ERR(ldb->clk_div_sel[chno]);
+
return 0;
}
--
1.7.9.5
[PATCH 2/3] ARM: dts: imx6q/imx6dl: add necessary clocks for ldb node
This patch adds di[0/1]_div_3_5, di[0/1]_div_7 and di[0/1]_div_sel
clocks to the ldb nodes so that the ldb driver may use them to
setup the display clock trees.
Signed-off-by: Liu Ying
---
arch/arm/boot/dts/imx6dl.dtsi |8 ++--
arch/arm/boot/dts/imx6q.dtsi |8 ++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 9e8ae11..ff0d743 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -75,10 +75,14 @@
&ldb {
clocks = <&clks 33>, <&clks 34>,
<&clks 39>, <&clks 40>,
-<&clks 135>, <&clks 136>;
+<&clks 135>, <&clks 136>,
+<&clks 184>, <&clks 185>, <&clks 203>, <&clks 204>,
+<&clks 205>, <&clks 206>;
clock-names = "di0_pll", "di1_pll",
"di0_sel", "di1_sel",
- "di0", "di1";
+ "di0", "di1",
+ "di0_div_3_5", "di1_div_3_5", "di0_div_7", "di1_div_7",
+ "di0_div_sel", "di1_div_sel";
lvds-channel at 0 {
crtcs = <&ipu1 0>, <&ipu1 1>;
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index f024ef2..b078a42 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -146,10 +146,14 @@
&ldb {
clocks = <&clks 33>, <&clks 34>,
<&clks 39>, <&clks 40>, <&clks 41>, <&clks 42>,
-<&clks 135>, <&clks 136>;
+<&clks 135>, <&clks 136>,
+<&clks 184>, <&clks 185>, <&clks 203>, <&clks 204>,
+<&clks 205>, <&clks 206>;
clock-names = "di0_pll", "di1_pll",
"di0_sel", "di1_sel", "di2_sel", "di3_sel",
- "di0", "di1";
+ "di0", "di1",
+ "di0_div_3_5", "di1_div_3_5", "di0_div_7", "di1_div_7",
+ "di0_div_sel", "di1_div_sel";
lvds-channel at 0 {
crtcs = <&ipu1 0>, <&ipu1 1>, <&ipu2 0>, <&ipu2 1>;
--
1.7.9.5
[PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
The ldb_di[0/1]_ipu_div dividers may divide their parent clock
frequencies by either 3.5 or 7. The non-integral dividers cannot
be dealt with the common clock framework directly, so they cannot
be registered as common clock dividers. So this patch adds a fixed
factor clock of 1/7 and introduces ldb_di[0/1]_div_sel multiplexers
so that the fixed factor clocks of 1/3.5 and 1/7 can be set to be
the parents of ldb_di[0/1]_div_sel multiplexers. The ldb_di[0/1]_podf
dividers are no longer used then.
Signed-off-by: Liu Ying
---
.../devicetree/bindings/clock/imx6q-clock.txt |6 +++--
arch/arm/mach-imx/clk-imx6q.c | 25
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 5a90a72..90e923e 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -89,8 +89,6 @@ clocks and IDs.
gpu3d_shader74
ipu1_podf 75
ipu2_podf 76
- ldb_di0_podf77
- ldb_di1_podf78
ipu1_di0_pre79
ipu1_di1_pre80
ipu2_di0_pre81
@@ -215,6 +213,10 @@ clocks and IDs.
cko2200
cko 201
vdoa202
+ ldb_di0_div_7 203
+ ldb_di1_div_7 204
+ ldb_di0_div_sel 205
+ ldb_di1_div_sel 206
Examples:
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 9181a24..2b5be96 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -189,6 +189,8 @@ static const char *gpu3d_core_sels[]= {
"mmdc_ch0_axi", "pll3_usb_otg", "pll2_p
static const char *gpu3d_shader_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg",
"pll2_pfd1_594m", "pll3_pfd0_720m", };
static const char *ipu_sels[] = { "mmdc_ch0_axi", "pll2_pfd2_396m",
"pll3_120m", "pll3_pfd1_540m", };
static const char *ldb_di_sels[] = { "pll5_video_div", "pll2_pfd0_352m",
"pll2_pfd2_396m", "mmdc_ch1_axi", "pll3_usb_otg", };
+static const char *ldb_di0_div_sels[] = { "ldb_di0_div_3_5", "ldb_di0_div_7",
};
+static const char *ldb_di1_div_sels[] = { "ldb_di1_div_3_5", "ldb_di1_div_7",
};
static const char *ipu_di_pre_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg",
"pll5_video_div", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd1_540m", };
static const char *ipu1_di0_sels[] = { "ipu1_di0_pre", "dummy", "dummy",
"ldb_di0", "ldb_di1", };
static const char *ipu1_di1_sels[] = { "ipu1_di1_pre", "dummy", "dummy",
"ldb_di0", "ldb_di1", };
@@ -233,11 +235,11 @@ enum mx6q_clks {
periph_clk2, periph2_clk2, ipg, ipg_per, esai_pred, esai_podf,
asrc_pred, asrc_podf, spdif_pred, spdif_podf, can_root, ecspi_root,
gpu2d_core_podf, gpu3d_core_podf, gpu3d_shader, ipu1_podf, ipu2_podf,
- ldb_di0_podf, ldb_di1_podf, ipu1_di0_pre, ipu1_di1_pre, ipu2_di0_pre,
- ipu2_di1_pre, hsi_tx_podf, ssi1_pred, ssi1_podf, ssi2_pred, ssi2_podf,
- ssi3_pred, ssi3_podf, uart_serial_podf, usdhc1_podf, usdhc2_podf,
- usdhc3_podf, usdhc4_podf, enfc_pred, enfc_podf, emi_podf,
- emi_slow_podf, vpu_axi_podf, cko1_podf, axi, mmdc_ch0_axi_podf,
+ ldb_di0_podf_unused, ldb_di1_podf_unused, ipu1_di0_pre, ipu1_di1_pre,
+ ipu2_di0_pre, ipu2_di1_pre, hsi_tx_podf, ssi1_pred, ssi1_podf,
+ ssi2_pred, ssi2_podf, ssi3_pred, ssi3_podf, uart_serial_podf,
+ usdhc1_podf, usdhc2_podf, usdhc3_podf, usdhc4_podf, enfc_pred,
enfc_podf,
+ emi_podf, emi_slow_podf, vpu_axi_podf, cko1_podf, axi,
mmdc_ch0_axi_podf,
mmdc_ch1_axi_podf, arm, ahb, apbh_dma, asrc, can1_ipg, can1_serial,
can2_ipg, can2_serial, ecspi1, ecspi2, ecspi3, ecspi4, ecspi5, enet,
esai, gpt_ipg, gpt_ipg_per, gpu2d_core, gpu3d_core, hdmi_iahb,
@@ -251,7 +253,8 @@ enum mx6q_clks {
ssi2_ipg, ssi3_ipg, rom, usbphy1, usbphy2, ldb_di0_div_3_5,
ldb_di1_div_3_5,
sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref,
usbphy1_gate,
usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
- spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, clk_max
+ spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, ldb_di0_div_7,
ldb_di1_div_7,
+ ldb_di0_div_sel, ldb_di1_div_sel, clk_max
};
static struct clk *clk[clk_max];
@@ -387,6 +390,8 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[ipu2_sel] = imx_clk_mux("ipu2_sel", base + 0x3c,
14, 2, ipu_sels, ARRAY_SIZE(ipu_sels));
clk[ldb_di0_sel] = imx_clk_mux_flags("ldb_di0_sel", base + 0x2c,
9, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels), CLK_SET_RATE_PARENT);
clk[ldb_di1_sel] = imx_clk_mux_flags("ldb_di1_sel", base +
[PATCH 0/3] refactor some ldb related clocks
The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5 drivider or a 1/7 divider. The common clock framework cannot deal with the two dividers directly even with the divider table which only supports integral dividers. So, the idea is to take the 1/3.5 and 1/7 dividers as separate fixed factor dividers and introduce a new multiplexer clock to be derived from the them. Then, the ldb display clock trees can be setup correctly. This series contains the necessary clock driver changes, dts code changes and imx-drm/ldb driver changes to fullfill the task. Liu Ying (3): ARM: imx6q: refactor some ldb related clocks ARM: dts: imx6q/imx6dl: add necessary clocks for ldb node staging: drm/imx: ldb: correct the ldb di clock trees .../devicetree/bindings/clock/imx6q-clock.txt |6 ++-- arch/arm/boot/dts/imx6dl.dtsi |8 +++-- arch/arm/boot/dts/imx6q.dtsi |8 +++-- arch/arm/mach-imx/clk-imx6q.c | 25 +++-- drivers/staging/imx-drm/imx-ldb.c | 38 +++- 5 files changed, 61 insertions(+), 24 deletions(-) -- 1.7.9.5
Re: [PATCH 0/2] update pixel format setting to fimd driver
Hi Inki, On Tuesday 20 of August 2013 14:45:10 Inki Dae wrote: > This patch series fix pixel format setting according to > drm_framebuffer's pixel_format, and check if a given window > supports alpha channel or not. > > Inki Dae (2): > drm/exynos: fix fimd pixel format setting > drm/exynos: check a pixel format to a particular window layer > > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 45 > -- 1 files changed, 24 insertions(+), 21 > deletions(-) For the whole series: Reviewed-by: Tomasz Figa Best regards, Tomasz ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #8 from Timoth?e Ravier --- Look alike bug here: screen goes black and freeze for a while when playing the second video using VDPAU with mplayer. Upon "screen return", the whole display is corrupted and unusable, requiring reboot. Arch Linux testing packages except for the kernel which is custom build. Card: Radeon Mobility 4650 HD Linux kernel: 3.11rc6 (commit: b36f4be, it's called -dirty in the dmesg log but I don't know why, will try to figure that out) Mesa: 9.2.0rc1 OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0-rc1 OpenGL core profile shading language version string: 1.40 OpenGL core profile context flags: (none) OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 9.2.0-rc1 OpenGL shading language version string: 1.30 -- 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/20130820/8622e425/attachment.html>
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #11 from Timothée Ravier --- Created attachment 84362 --> https://bugs.freedesktop.org/attachment.cgi?id=84362&action=edit X server logs Note: if I quickly kill the second mplayer right after the start of the video I can avoid the crash, but UVD won't work anymore and mplayer will permanently end with some errors (if VDPAU is forced): Selected video codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (VDPAU acceleration) [libavcodec] Selected audio codec: ATSC A/52A (AC-3) [libavcodec] AUDIO: 48000 Hz, 2 ch, floatle, 384.0 kbit/12.50% (ratio: 48000->384000) AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample) Starting playback... VIDEO: 1280x720 23.976 fps0.0 kbps ( 0.0 kB/s) VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU acceleration [ vdpau] Failed creating VDPAU decoder: An invalid/unsupported VdpDecoderProfile value was supplied. FATAL: Cannot initialize video driver. VIDEO: 1280x720 23.976 fps0.0 kbps ( 0.0 kB/s) VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU acceleration [ vdpau] Failed creating VDPAU decoder: An invalid/unsupported VdpDecoderProfile value was supplied. FATAL: Cannot initialize video driver. [h264_vdpau @ 0x7f736c111cc0]decode_slice_header error [h264_vdpau @ 0x7f736c111cc0]no frame! Error while decoding frame! FATAL: Could not initialize video filters (-vf) or video output (-vo). But right after that my X session was killed and the X server kept exiting with bus errors when starting new ones (see attached log). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #7 from Timoth?e Ravier --- Created attachment 84347 --> https://bugs.freedesktop.org/attachment.cgi?id=84347&action=edit dmesg log -- 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/20130820/7579641f/attachment-0001.html>
[RFC PATCH] drm/radeon: rework to new fence interface
Am 20.08.2013 15:21, schrieb Maarten Lankhorst:
> Op 20-08-13 11:51, Christian K?nig schreef:
>> Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
>> [SNIP]
>>
>>> [SNIP]
>>> +/**
>>> + * radeon_fence_enable_signaling - enable signalling on fence
>>> + * @fence: fence
>>> + *
>>> + * This function is called with fence_queue lock held, and adds a
>>> callback
>>> + * to fence_queue that checks if this fence is signaled, and if so it
>>> + * signals the fence and removes itself.
>>> + */
>>> +static bool radeon_fence_enable_signaling(struct fence *f)
>>> +{
>>> +struct radeon_fence *fence = to_radeon_fence(f);
>>> +
>>> +if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq)
>>> >= fence->seq ||
>>> +!fence->rdev->ddev->irq_enabled)
>>> +return false;
>>> +
>> Do I get that right that you rely on IRQs to be enabled and working
>> here? Cause that would be a quite bad idea from the conceptual side.
> For cross-device synchronization it would be nice to have working irqs,
> it allows signalling fences faster,
> and it allows for callbacks on completion to be called. For internal
> usage it's no more required than it was before.
That's a big NAK.
The fence processing is actually very fine tuned to avoid IRQs and as far
as I can see you just leave them enabled by decrementing the atomic from
IRQ context. Additional to that we need allot of special handling in case
of a hardware lockup here, which isn't done if you abuse the fence
interface like this.
>>> I think it's not needed to leave the irq enabled, it's a leftover from when
>>> I was debugging the mac and no interrupt occurred at all.
>>>
Also your approach of leaking the IRQ context outside of the driver is a
very bad idea from the conceptual side. Please don't modify the fence
interface at all and instead use the wait functions already exposed by
radeon_fence.c. If you need some kind of signaling mechanism then wait
inside a workqueue instead.
>>> The fence takes up the role of a single shot workqueue here. Manually
>>> resetting the counter and calling wake_up_all would end up waking all
>>> active fences, there's no special handling needed inside radeon for this.
>> Yeah that's actually the point here, you NEED to activate ALL fences,
>> otherwise the fence handling inside the driver won't work.
> It's done in a lazy fashion. If there's no need for an activated fence the
> interrupt will not be enabled.
>>> The fence api does provide a synchronous wait function, but this causes a
>>> stall of whomever waits on it.
>> Which is perfectly fine. What actually is the use case of not stalling a
>> process who wants to wait for something?
> Does radeon call ttm_bo_wait on all bo's before doing a command submission?
> No? Why should other drivers do that..
Sure it does if hardware synchronization isn't supported.
>>> When I was testing this with intel I used the fence callback to poke a
>>> register in i915, this allowed it to not block until it hits the wait op in
>>> the command stream, and even then only if the callback was not called first.
>>>
>>> It's documented that the callbacks can be called from any context and will
>>> be called with irqs disabled, so nothing scary should be done. The kernel
>>> provides enough debug mechanisms to find any violators.
>>> PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
>> No thanks, we even abandoned that concept internal in the driver. Please use
>> the blocking wait functions instead.
> No, this just stalls all gpu's that share a bo.
>
> The idea is to provide a standardized api so bo's can be synchronized without
> stalling. The first step to this is ww_mutex.
> If this lock is shared between multiple gpu's the same object can be reserved
> between multiple devices without causing
> a deadlock with circular dependencies. With some small patches it's possible
> to do this already between multiple drivers
> that use ttm. ttm_bo_reserve, ttm_bo_unreserve and all the other code dealing
> with ttm reservations have been converted
> to use ww_mutex locking.
>
> Fencing is the next step. When all buffers are locked a callback should be
> added to any previous fence, and a single new fence
> signaling completion of the command submission should be placed on all locked
> objects. Because the common path is that no
> objects are shared, the callback and FIFO stalling will only be needed for
> dma-bufs. When all callbacks have fired the FIFO can be
> unblocked. This prevents having to sync the gpu to the cpu. If a bo is
> submitted to 1 gpu, and then immediately to another it will not
> stall unless needed. For example in a optimus configuration an application
> could copy a rendered frame from VRAM to a shared
> dma-buf (xorg's buffer), then have Xorg copying it again (on intel's gpu)
> from the d
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #38 from Tobias Droste --- I don't want to say that it's not a gcc bug, but I'm using gcc 4.7: gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
Hi Rob,
On Tuesday 13 August 2013 20:52:15 Rob Clark wrote:
> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
> > MIPI DBI is a configurable-width parallel display bus that transmits
> > commands and data.
> >
> > Add a new DBI Linux bus type that implements the usual bus
> > infrastructure (including devices and drivers (un)registration and
> > matching, and bus configuration and access functions).
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
> > drivers/video/display/Kconfig| 8 ++
> > drivers/video/display/Makefile | 1 +
> > drivers/video/display/mipi-dbi-bus.c | 234 ++
> > include/video/display.h | 4 +
> > include/video/mipi-dbi-bus.h | 125 +++
> > 5 files changed, 372 insertions(+)
> > create mode 100644 drivers/video/display/mipi-dbi-bus.c
> > create mode 100644 include/video/mipi-dbi-bus.h
[snip]
> > diff --git a/include/video/mipi-dbi-bus.h b/include/video/mipi-dbi-bus.h
> > new file mode 100644
> > index 000..876b69d
> > --- /dev/null
> > +++ b/include/video/mipi-dbi-bus.h
[snip]
> > +struct mipi_dbi_device {
> > + const char *name;
> > + int id;
> > + struct device dev;
>
> just fwiw, we need the "framework" to be agnostic of the association between
> devices and entities in the framework. Some things that are multiple
> entities may actually map to a single device in hw
I haven't written down that requirement, but I've kept it in mind while
designing CDF. We have similar use cases in V4L2.
> (and possibly visa versa?).
I don't think that would be needed, but if you can think of a use case I'm all
ears.
> Otherwise we end up having to create fake devices in some cases. Really the
> entities, or objects, or whatever you call 'em should just extend some
> kref'd base class. Sort of like how existing kms objects extend
> drm_mode_object.
struct display_entity {
struct list_head list;
struct device *dev;
struct module *owner;
struct kref ref;
char name[32];
struct media_entity entity;
const struct display_entity_ops *ops;
void(*release)(struct display_entity *ent);
};
(from patch 02/19)
> So any 'struct device' moves down into the derived class, not in the base
> class. Configuration data is passed in separate, not grabbed out of dev->
> platform_data, etc. Probably there is room for some helpers to pull stuff
> out of DT/ACPI/whatever.
struct mipi_dbi_device is not a display entity, it's a physical device plugged
on a DBI bus. It's thus similar in purpose to struct pci_device or struct
platform_device. The DBI device driver will then create one or more display
entities depending on its needs.
> > + const struct mipi_dbi_device_id *id_entry;
> > + struct mipi_dbi_bus *bus;
> > +
> > + unsigned int flags;
> > + unsigned int bus_width;
> > + unsigned int data_width;
> > +};
--
Regards,
Laurent Pinchart
[PATCH 1/2] [RFC PATCH v6] dmabuf-sync: Add a buffer synchronization framework
On Tue, Aug 13, 2013 at 06:19:35PM +0900, Inki Dae wrote: > This patch adds a buffer synchronization framework based on DMA BUF[1] > and and based on ww-mutexes[2] for lock mechanism. > > The purpose of this framework is to provide not only buffer access control > to CPU and DMA but also easy-to-use interfaces for device drivers and > user application. This framework can be used for all dma devices using > system memory as dma buffer, especially for most ARM based SoCs. > > Changelog v6: > - Fix sync lock to multiple reads. > - Add select system call support. > . Wake up poll_wait when a dmabuf is unlocked. > - Remove unnecessary the use of mutex lock. > - Add private backend ops callbacks. > . This ops has one callback for device drivers to clean up their > sync object resource when the sync object is freed. For this, > device drivers should implement the free callback properly. > - Update document file. > > Changelog v5: > - Rmove a dependence on reservation_object: the reservation_object is used > to hook up to ttm and dma-buf for easy sharing of reservations across > devices. However, the dmabuf sync can be used for all dma devices; v4l2 > and drm based drivers, so doesn't need the reservation_object anymore. > With regared to this, it adds 'void *sync' to dma_buf structure. > - All patches are rebased on mainline, Linux v3.10. > > Changelog v4: > - Add user side interface for buffer synchronization mechanism and update > descriptions related to the user side interface. > > Changelog v3: > - remove cache operation relevant codes and update document file. > > Changelog v2: > - use atomic_add_unless to avoid potential bug. > - add a macro for checking valid access type. > - code clean. > > The mechanism of this framework has the following steps, > 1. Register dmabufs to a sync object - A task gets a new sync object and > can add one or more dmabufs that the task wants to access. > This registering should be performed when a device context or an event > context such as a page flip event is created or before CPU accesses a > shared > buffer. > > dma_buf_sync_get(a sync object, a dmabuf); > > 2. Lock a sync object - A task tries to lock all dmabufs added in its own > sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead > lock issue and for race condition between CPU and CPU, CPU and DMA, and > DMA > and DMA. Taking a lock means that others cannot access all locked dmabufs > until the task that locked the corresponding dmabufs, unlocks all the > locked > dmabufs. > This locking should be performed before DMA or CPU accesses these dmabufs. > > dma_buf_sync_lock(a sync object); > > 3. Unlock a sync object - The task unlocks all dmabufs added in its own > sync > object. The unlock means that the DMA or CPU accesses to the dmabufs have > been completed so that others may access them. > This unlocking should be performed after DMA or CPU has completed accesses > to the dmabufs. > > dma_buf_sync_unlock(a sync object); > > 4. Unregister one or all dmabufs from a sync object - A task unregisters > the given dmabufs from the sync object. This means that the task dosen't > want to lock the dmabufs. > The unregistering should be performed after DMA or CPU has completed > accesses to the dmabufs or when dma_buf_sync_lock() is failed. > > dma_buf_sync_put(a sync object, a dmabuf); > dma_buf_sync_put_all(a sync object); > > The described steps may be summarized as: > get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put > > This framework includes the following two features. > 1. read (shared) and write (exclusive) locks - A task is required to > declare > the access type when the task tries to register a dmabuf; > READ, WRITE, READ DMA, or WRITE DMA. > > The below is example codes, > struct dmabuf_sync *sync; > > sync = dmabuf_sync_init(...); > ... > > dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R); > ... > > And the below can be used as access types: > DMA_BUF_ACCESS_R - CPU will access a buffer for read. > DMA_BUF_ACCESS_W - CPU will access a buffer for read or write. > DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read > DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or > write. > > 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. > A task may never try to unlock a buffer after taking a lock to the buffer. > In this case, a timer handler to the corresponding sync object is called > in five (default) seconds and then the timed-out buffer is unlocked by > work > queue handler to avoid lockups and to enforce resources of the buffer. > > The below is how to use interfaces for device driver: > 1. Allocate an
[RFC PATCH] drm/radeon: rework to new fence interface
Op 20-08-13 11:51, Christian K?nig schreef:
> Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
> [SNIP]
>
>> [SNIP]
>> +/**
>> + * radeon_fence_enable_signaling - enable signalling on fence
>> + * @fence: fence
>> + *
>> + * This function is called with fence_queue lock held, and adds a
>> callback
>> + * to fence_queue that checks if this fence is signaled, and if so it
>> + * signals the fence and removes itself.
>> + */
>> +static bool radeon_fence_enable_signaling(struct fence *f)
>> +{
>> +struct radeon_fence *fence = to_radeon_fence(f);
>> +
>> +if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
>> fence->seq ||
>> +!fence->rdev->ddev->irq_enabled)
>> +return false;
>> +
> Do I get that right that you rely on IRQs to be enabled and working here?
> Cause that would be a quite bad idea from the conceptual side.
For cross-device synchronization it would be nice to have working irqs, it
allows signalling fences faster,
and it allows for callbacks on completion to be called. For internal usage
it's no more required than it was before.
>>> That's a big NAK.
>>>
>>> The fence processing is actually very fine tuned to avoid IRQs and as far
>>> as I can see you just leave them enabled by decrementing the atomic from
>>> IRQ context. Additional to that we need allot of special handling in case
>>> of a hardware lockup here, which isn't done if you abuse the fence
>>> interface like this.
>> I think it's not needed to leave the irq enabled, it's a leftover from when
>> I was debugging the mac and no interrupt occurred at all.
>>
>>> Also your approach of leaking the IRQ context outside of the driver is a
>>> very bad idea from the conceptual side. Please don't modify the fence
>>> interface at all and instead use the wait functions already exposed by
>>> radeon_fence.c. If you need some kind of signaling mechanism then wait
>>> inside a workqueue instead.
>> The fence takes up the role of a single shot workqueue here. Manually
>> resetting the counter and calling wake_up_all would end up waking all active
>> fences, there's no special handling needed inside radeon for this.
>
> Yeah that's actually the point here, you NEED to activate ALL fences,
> otherwise the fence handling inside the driver won't work.
It's done in a lazy fashion. If there's no need for an activated fence the
interrupt will not be enabled.
>> The fence api does provide a synchronous wait function, but this causes a
>> stall of whomever waits on it.
>
> Which is perfectly fine. What actually is the use case of not stalling a
> process who wants to wait for something?
Does radeon call ttm_bo_wait on all bo's before doing a command submission? No?
Why should other drivers do that..
>> When I was testing this with intel I used the fence callback to poke a
>> register in i915, this allowed it to not block until it hits the wait op in
>> the command stream, and even then only if the callback was not called first.
>>
>> It's documented that the callbacks can be called from any context and will
>> be called with irqs disabled, so nothing scary should be done. The kernel
>> provides enough debug mechanisms to find any violators.
>> PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
>
> No thanks, we even abandoned that concept internal in the driver. Please use
> the blocking wait functions instead.
No, this just stalls all gpu's that share a bo.
The idea is to provide a standardized api so bo's can be synchronized without
stalling. The first step to this is ww_mutex.
If this lock is shared between multiple gpu's the same object can be reserved
between multiple devices without causing
a deadlock with circular dependencies. With some small patches it's possible to
do this already between multiple drivers
that use ttm. ttm_bo_reserve, ttm_bo_unreserve and all the other code dealing
with ttm reservations have been converted
to use ww_mutex locking.
Fencing is the next step. When all buffers are locked a callback should be
added to any previous fence, and a single new fence
signaling completion of the command submission should be placed on all locked
objects. Because the common path is that no
objects are shared, the callback and FIFO stalling will only be needed for
dma-bufs. When all callbacks have fired the FIFO can be
unblocked. This prevents having to sync the gpu to the cpu. If a bo is
submitted to 1 gpu, and then immediately to another it will not
stall unless needed. For example in a optimus configuration an application
could copy a rendered frame from VRAM to a shared
dma-buf (xorg's buffer), then have Xorg copying it again (on intel's gpu) from
the dma-buf to a framebuffer .
~Maarten
[PATCH] drm/radeon: fix LCD record parsing
If the LCD table contains an EDID record, properly account for the edid size when walking through the records. This should fix error messages about unknown LCD records. Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/radeon_atombios.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c index 4ac5f40..112c963 100644 --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c @@ -1681,7 +1681,9 @@ struct radeon_encoder_atom_dig *radeon_atombios_get_lvds_info(struct kfree(edid); } } - record += sizeof(ATOM_FAKE_EDID_PATCH_RECORD); + record += fake_edid_record->ucFakeEDIDLength ? + fake_edid_record->ucFakeEDIDLength + 2 : + sizeof(ATOM_FAKE_EDID_PATCH_RECORD); break; case LCD_PANEL_RESOLUTION_RECORD_TYPE: panel_res_record = (ATOM_PANEL_RESOLUTION_PATCH_RECORD *)record; -- 1.8.3.1
[PATCH] drm: add MIPI DSI encoder and connector types
From: Shobhit Kumar
Signed-off-by: Shobhit Kumar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc.c |2 ++
include/uapi/drm/drm_mode.h |2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a691764..dc279f4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -209,6 +209,7 @@ static struct drm_conn_prop_enum_list
drm_connector_enum_list[] =
{ DRM_MODE_CONNECTOR_TV, "TV" },
{ DRM_MODE_CONNECTOR_eDP, "eDP" },
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
+ { DRM_MODE_CONNECTOR_DSI, "DSI" },
};
static const struct drm_prop_enum_list drm_encoder_enum_list[] =
@@ -218,6 +219,7 @@ static const struct drm_prop_enum_list
drm_encoder_enum_list[] =
{ DRM_MODE_ENCODER_LVDS, "LVDS" },
{ DRM_MODE_ENCODER_TVDAC, "TV" },
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
+ { DRM_MODE_ENCODER_DSI, "DSI" },
};
void drm_connector_ida_init(void)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 53db7ce..589114e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -165,6 +165,7 @@ struct drm_mode_get_plane_res {
#define DRM_MODE_ENCODER_LVDS 3
#define DRM_MODE_ENCODER_TVDAC 4
#define DRM_MODE_ENCODER_VIRTUAL 5
+#define DRM_MODE_ENCODER_DSI 6
struct drm_mode_get_encoder {
__u32 encoder_id;
@@ -203,6 +204,7 @@ struct drm_mode_get_encoder {
#define DRM_MODE_CONNECTOR_TV 13
#define DRM_MODE_CONNECTOR_eDP 14
#define DRM_MODE_CONNECTOR_VIRTUAL 15
+#define DRM_MODE_CONNECTOR_DSI 16
struct drm_mode_get_connector {
--
1.7.9.5
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 --- Comment #5 from prettyvani...@posteo.at --- I am running a current mainline kernel until dpm stabilises, so I am on 3.11rc6 currently, which has the patch mentioned already applied. Sadly, no change in behaviour. I updated the dmesg output attachment and added xrandr and X.org log output. Anything in particular I should look for to get to the root of the problem? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 --- Comment #4 from prettyvani...@posteo.at --- Created attachment 107260 --> https://bugzilla.kernel.org/attachment.cgi?id=107260&action=edit Xorg.0.log -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 --- Comment #3 from prettyvani...@posteo.at --- Created attachment 107259 --> https://bugzilla.kernel.org/attachment.cgi?id=107259&action=edit xrandr --verbose -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 prettyvani...@posteo.at changed: What|Removed |Added Attachment #106381|0 |1 is obsolete|| --- Comment #2 from prettyvani...@posteo.at --- Created attachment 107258 --> https://bugzilla.kernel.org/attachment.cgi?id=107258&action=edit dmesg output with dvi and displayport connected (drm.debug=0xE) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/atombios: fix variable sized arrays for newer gccs (v2)
Ignore this patch for now. there are still problems with newer gcc
versions that aren't fixed yet.
Alex
On Tue, Aug 20, 2013 at 1:16 PM, Alex Deucher wrote:
> Newer versions of gcc seem to wander off into no-man's land
> when using variably sized arrays. Atombios tends to do things
> like:
>
> struct object {
> u8 version;
> u8 num_elements;
> u32 elements[1]; /* num_elements entries */
> };
>
> We then do things like the following in the driver code:
>
> for (i = 0; i < atom_object->num_elements; i++) {
> driver_object[i] = atom_object->elements[i];
> }
>
> With previous versions of gcc this used to work fine, but with
> 4.7 and 4.8, it seems to generate code that wanders off into the
> weeds.
>
> According to:
> http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> The traditional way of handling variably sized arrays (ISO C90)
> is to use an array length of 1. Gcc allows you to use an array
> length of 0 and newer versions of gcc only seem to do the
> right thing when 0 is used.
>
> This is tricky in this case because atombios.h is shared between
> multiple components and is used for allocation in the vbios.
>
> v2: update commit message
>
> Signed-off-by: Alex Deucher
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/radeon/atombios.h | 100
> +++---
> 1 file changed, 50 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios.h
> b/drivers/gpu/drm/radeon/atombios.h
> index 16b120c..3f1f011 100644
> --- a/drivers/gpu/drm/radeon/atombios.h
> +++ b/drivers/gpu/drm/radeon/atombios.h
> @@ -3592,7 +3592,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD
> {
>UCHAR ucRecordType;
>UCHAR ucFakeEDIDLength;
> - UCHAR ucFakeEDIDString[1];// This actually has ucFakeEdidLength
> elements.
> + UCHAR ucFakeEDIDString[0];// This actually has ucFakeEdidLength
> elements.
> } ATOM_FAKE_EDID_PATCH_RECORD;
>
> typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD
> @@ -3868,7 +3868,7 @@ typedef struct _ATOM_GPIO_PIN_ASSIGNMENT
> typedef struct _ATOM_GPIO_PIN_LUT
> {
>ATOM_COMMON_TABLE_HEADER sHeader;
> - ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[1];
> + ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[0];
> }ATOM_GPIO_PIN_LUT;
>
>
> //
> @@ -3995,7 +3995,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH
>USHORTusSize;//the size of
> ATOM_DISPLAY_OBJECT_PATH
>USHORTusConnObjectId;//Connector
> Object ID
>USHORTusGPUObjectId; //GPU ID
> - USHORTusGraphicObjIds[1]; //1st Encoder
> Obj source from GPU to last Graphic Obj destinate to connector.
> + USHORTusGraphicObjIds[0]; //1st Encoder
> Obj source from GPU to last Graphic Obj destinate to connector.
> }ATOM_DISPLAY_OBJECT_PATH;
>
> typedef struct _ATOM_DISPLAY_EXTERNAL_OBJECT_PATH
> @@ -4012,7 +4012,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH_TABLE
>UCHAR ucNumOfDispPath;
>UCHAR ucVersion;
>UCHAR ucPadding[2];
> - ATOM_DISPLAY_OBJECT_PATHasDispPath[1];
> + ATOM_DISPLAY_OBJECT_PATHasDispPath[0];
> }ATOM_DISPLAY_OBJECT_PATH_TABLE;
>
>
> @@ -4028,15 +4028,15 @@ typedef struct _ATOM_OBJECT_TABLE
> //Above 4 object table
> {
>UCHAR ucNumberOfObjects;
>UCHAR ucPadding[3];
> - ATOM_OBJECT asObjects[1];
> + ATOM_OBJECT asObjects[0];
> }ATOM_OBJECT_TABLE;
>
> typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT
> //usSrcDstTableOffset pointing to this structure
> {
>UCHAR ucNumberOfSrc;
> - USHORT usSrcObjectID[1];
> + USHORT usSrcObjectID[0];
>UCHAR ucNumberOfDst;
> - USHORT usDstObjectID[1];
> + USHORT usDstObjectID[0];
> }ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;
>
>
> @@ -4208,7 +4208,7 @@ typedef struct _ATOM_CONNECTOR_DEVICE_TAG_RECORD
>ATOM_COMMON_RECORD_HEADER sheader;
>UCHAR ucNumberOfDevice;
>UCHAR ucReserved;
> - ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[1]; //This Id is same as
> "ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
> + ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[0]; //This Id is same as
> "ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
> }ATOM_CONNECTOR_DEVICE_TAG_RECORD;
>
>
> @@ -4268,7 +4268,7 @@ typedef struct _ATOM_OBJECT_GPIO_CNTL_RECORD
>ATOM_COMMON_RECORD_HEADER sheader;
>UCHAR ucFlags;// Future expnadibility
>UCHAR ucNumberOfPins; // Number of GPIO pins
> used to control the object
> - ATOM_GPIO_PIN_CONTROL_PAIR asGpio[1];
[PATCH 2/2] drm/exynos: check a pixel format to a particular window layer
This patch checks if a requested window supports alpha channel or not.
In case of s3c64xx, window 0 doesn't support alpha channel so if
the request pixel format is ARGB then change it to XRGB.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 13d5afb..f8889d2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -66,11 +66,13 @@ struct fimd_driver_data {
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
+ unsigned int has_limited_fmt:1;
};
static struct fimd_driver_data s3c64xx_fimd_driver_data = {
.timing_base = 0x0,
.has_clksel = 1,
+ .has_limited_fmt = 1,
};
static struct fimd_driver_data exynos4_fimd_driver_data = {
@@ -420,6 +422,15 @@ static void fimd_win_set_pixfmt(struct device *dev,
unsigned int win)
val = WINCONx_ENWIN;
+ /*
+* In case of s3c64xx, window 0 doesn't support alpha channel.
+* So the request format is ARGB then change it to XRGB.
+*/
+ if (ctx->driver_data->has_limited_fmt && !win) {
+ if (win_data->pixel_format == DRM_FORMAT_ARGB)
+ win_data->pixel_format = DRM_FORMAT_XRGB;
+ }
+
switch (win_data->pixel_format) {
case DRM_FORMAT_C8:
val |= WINCON0_BPPMODE_8BPP_PALETTE;
--
1.7.5.4
[PATCH 1/2] drm/exynos: fix fimd pixel format setting
This patch fixes wrong pixel format setting.
A pixel format is decided according to bpp and depth, or user-requested
format but fimd driver considered only bpp value to decide a proper pixel
format. So this patch makes a proper pixel format to be set according
to drm_framebuffer's pixel_format which is set by addfb with bpp and
depth, or addfb2 with user-requested format.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 34 +++--
1 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index b8aa8fe..13d5afb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -91,6 +91,7 @@ struct fimd_win_data {
unsigned intfb_width;
unsigned intfb_height;
unsigned intbpp;
+ unsigned intpixel_format;
dma_addr_t dma_addr;
unsigned intbuf_offsize;
unsigned intline_size; /* bytes */
@@ -397,6 +398,7 @@ static void fimd_win_mode_set(struct device *dev,
win_data->fb_height = overlay->fb_height;
win_data->dma_addr = overlay->dma_addr[0] + offset;
win_data->bpp = overlay->bpp;
+ win_data->pixel_format = overlay->pixel_format;
win_data->buf_offsize = (overlay->fb_width - overlay->crtc_width) *
(overlay->bpp >> 3);
win_data->line_size = overlay->crtc_width * (overlay->bpp >> 3);
@@ -418,39 +420,29 @@ static void fimd_win_set_pixfmt(struct device *dev,
unsigned int win)
val = WINCONx_ENWIN;
- switch (win_data->bpp) {
- case 1:
- val |= WINCON0_BPPMODE_1BPP;
- val |= WINCONx_BITSWP;
- val |= WINCONx_BURSTLEN_4WORD;
- break;
- case 2:
- val |= WINCON0_BPPMODE_2BPP;
- val |= WINCONx_BITSWP;
- val |= WINCONx_BURSTLEN_8WORD;
- break;
- case 4:
- val |= WINCON0_BPPMODE_4BPP;
- val |= WINCONx_BITSWP;
- val |= WINCONx_BURSTLEN_8WORD;
- break;
- case 8:
+ switch (win_data->pixel_format) {
+ case DRM_FORMAT_C8:
val |= WINCON0_BPPMODE_8BPP_PALETTE;
val |= WINCONx_BURSTLEN_8WORD;
val |= WINCONx_BYTSWP;
break;
- case 16:
+ case DRM_FORMAT_XRGB1555:
+ val |= WINCON0_BPPMODE_16BPP_1555;
+ val |= WINCONx_HAWSWP;
+ val |= WINCONx_BURSTLEN_16WORD;
+ break;
+ case DRM_FORMAT_RGB565:
val |= WINCON0_BPPMODE_16BPP_565;
val |= WINCONx_HAWSWP;
val |= WINCONx_BURSTLEN_16WORD;
break;
- case 24:
+ case DRM_FORMAT_XRGB:
val |= WINCON0_BPPMODE_24BPP_888;
val |= WINCONx_WSWP;
val |= WINCONx_BURSTLEN_16WORD;
break;
- case 32:
- val |= WINCON1_BPPMODE_28BPP_A4888
+ case DRM_FORMAT_ARGB:
+ val |= WINCON1_BPPMODE_25BPP_A1888
| WINCON1_BLD_PIX | WINCON1_ALPHA_SEL;
val |= WINCONx_WSWP;
val |= WINCONx_BURSTLEN_16WORD;
--
1.7.5.4
[PATCH 0/2] update pixel format setting to fimd driver
This patch series fix pixel format setting according to drm_framebuffer's pixel_format, and check if a given window supports alpha channel or not. Inki Dae (2): drm/exynos: fix fimd pixel format setting drm/exynos: check a pixel format to a particular window layer drivers/gpu/drm/exynos/exynos_drm_fimd.c | 45 -- 1 files changed, 24 insertions(+), 21 deletions(-) -- 1.7.5.4
[Bug 60775] Installing NVIDIA proprietary drivers on kernel 3.10.7-100.fc18.x86_64 errors out . . . can't find kernel source files
https://bugzilla.kernel.org/show_bug.cgi?id=60775 --- Comment #1 from Ryan Letourneau --- Just tried solution here http://ewaldertl.blogspot.ca/2013/02/update-fedora-18-to-kernel-376-let-fail.html but did not resolve issue -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC v3 00/19] Common Display Framework
On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart wrote: > Hi Rob, > > On Tuesday 13 August 2013 20:43:50 Rob Clark wrote: >> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote: >> > Hi everybody, >> > >> > Here's the third RFC of the Common Display Framework. >> > >> > I won't repeat all the background information from the versions one and >> > two here, you can read it at http://lwn.net/Articles/512363/ and >> > http://lwn.net/Articles/526965/. >> > >> > This RFC isn't final. Given the high interest in CDF and the urgent tasks >> > that kept delaying the next version of the patch set, I've decided to >> > release v3 before completing all parts of the implementation. Known >> > missing items are >> > >> > - documentation: kerneldoc and this cover letter should provide basic >> > information, more extensive documentation will likely make it to v4. >> > >> > - pipeline configuration and control: generic code to configure and >> > control display pipelines (in a nutshell, translating high-level mode >> > setting and DPMS calls to low-level entity operations) is missing. Video >> > and stream control operations have been carried over from v2, but will >> > need to be revised for v4. >> > >> > - DSI support: I still have no DSI hardware I can easily test the code on. >> >> tbh, I kinda think that DSI and bridge chips are the things we should focus >> on first.. that seems what is most important for current and new hardware. >> Back-filling to handle older/simpler panels can be done later. > > That sounds reasonable (although I still believe DSI is only part of the > issue), but I'll need help with that, as the Renesas platforms I work on don't > have a DSI bus. > >> > Special thanks go to >> > >> > - Renesas for inviting me to LinuxCon Japan 2013 where I had the >> > opportunity to validate the CDF v3 concepts with Alexandre Courbot >> > (NVidia) and Tomasz Figa (Samsung). >> > >> > - Tomi Valkeinen (TI) for taking the time to deeply brainstorm v3 with me. >> > >> > - Linaro for inviting me to Linaro Connect Europe 2013, the discussions we >> > had there greatly helped moving CDF forward. >> > >> > - And of course all the developers who showed interest in CDF and spent >> > time sharing ideas, reviewing patches and testing code. >> > >> > I have to confess I was a bit lost and discouraged after all the CDF- >> > related meetings during which we have discussed how to move from v2 to v3. >> > With every meeting I was hoping to run the implementation through use >> > cases of various interesting parties and narrow down the scope of the huge >> > fuzzy beast that CDF was. With every meeting the scope actually broadened, >> > with no clear path at sight anywhere. >> > >> > Earlier this year I was about to drop one of the requirements on which I >> > had based CDF v2: sharing drivers between DRM/KMS and V4L2. With only two >> > HDMI transmitters as use cases for that feature (with only out-of-tree >> > drivers so far), I just thought the involved completely wasn't worth it >> > and that I should implement CDF v3 as a DRM/KMS-only helper framework. >> > However, a seemingly unrelated discussion with Xilinx developers showed >> > me that hybrid SoC-FPGA platforms such as the Xilinx Zynq 7000 have a >> > larger library of IP cores that can be used in camera capture pipelines >> > and in display pipelines. The two use cases suddenly became tens or even >> > hundreds of use cases that I couldn't ignore anymore. >> >> Hmm, I'm still not really convinced ;-) >> >> Or maybe, put another way, I still think we should still optimize for the >> common case. I mean I'm sure you *can* design hw that has an LVDS->DP bridge >> in the capture path, and if you had something like an FPGA where that was >> cheap to do maybe you even would (for fun). But if in the real world, there >> are only one or two cases of actual hw using the same bridge in a capture >> pipeline which is normally used in display pipelines, then duplicating some >> small bit of code for that abnormal case if it makes things easier for the >> common case, seems like a reasonable trade-off to me. > > That was my opinion as well until I started working on a Xilinx platform. > There's dozens of IP cores there that are used in both capture and display > pipelines. or maybe just some helper lib's to handling the register level programming? Anyways, I guess you can call it a "worse is better" thing, but if you can get 90% of the desired effect for 10% of the work, take the simpler solution. I don't think we should make things more layered or more difficult for one exceptional case. > Furthermore, FPGA display pipelines being made of individual IP cores, we need > a way to write one driver per IP core and make them all interact. The recently > proposed drm_bridge is one possible solution to this issue (and to a different > but similar issue that trigerred the development of drm_bridge), but it's in > my opinion not generic enough. We're facin
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #37 from Alex Deucher --- I was finally able to reproduce this, but only with gcc 4.8. Older versions of gcc work fine. Looks like the gcc bug has struck again. See: https://bugs.freedesktop.org/show_bug.cgi?id=66932 Now to find what other part gcc doesn't like... -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #42 from Alex Deucher --- I can reproduce it in Fedora 17 as well (gcc 4.7). So it seems to be something about Fedora 16 (gcc 4.6). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/i915: add fast boot support for Haswell
On Tue, Aug 20, 2013 at 3:33 AM, Furquan Shaikh wrote:
> Enables getting correct mode clock when reading pipe config
> This patch has been tested successfully on top of drm-intel-nightly tree
>
> Signed-off-by: Furquan Shaikh
This is missing a hunk to enable the pipe_config consistency checks:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7a40427..e8b73ac 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8416,13 +8416,11 @@ intel_pipe_config_compare(struct drm_device *dev,
#undef PIPE_CONF_CHECK_FLAGS
#undef PIPE_CONF_QUIRK
- if (!IS_HASWELL(dev)) {
- if (!intel_fuzzy_clock_check(current_config, pipe_config)) {
- DRM_ERROR("mismatch in clock (expected %d, found %d)\n",
- current_config->adjusted_mode.clock,
- pipe_config->adjusted_mode.clock);
- return false;
- }
+ if (!intel_fuzzy_clock_check(current_config, pipe_config)) {
+ DRM_ERROR("mismatch in clock (expected %d, found %d)\n",
+ current_config->adjusted_mode.clock,
+ pipe_config->adjusted_mode.clock);
+ return false;
}
return true;
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6
> drivers/gpu/drm/i915/intel_ddi.c | 70
>
> drivers/gpu/drm/i915/intel_display.c | 1 +
> 3 files changed, 77 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2b96d6b..9511129 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4970,6 +4970,7 @@
> #define SPLL_PLL_NON_SSC (2<<28)
> #define SPLL_PLL_FREQ_810MHz (0<<26)
> #define SPLL_PLL_FREQ_1350MHz (1<<26)
> +#define SPLL_PLL_FREQ_MASK (3<<26)
>
> /* WRPLL */
> #define WRPLL_CTL1 0x46040
> @@ -4983,6 +4984,10 @@
> #define WRPLL_DIVIDER_POST(x) ((x)<<8)
> #define WRPLL_DIVIDER_FEEDBACK(x) ((x)<<16)
>
> +#define WRPLL_DIVIDER_REFERENCE_BITS(reg)(reg & 0xff)
> +#define WRPLL_DIVIDER_POST_BITS(reg) ((reg >> 8) & 0x3f)
> +#define WRPLL_DIVIDER_FEEDBACK_BITS(reg) ((reg >> 16) & 0xff)
> +
> /* Port clock selection */
> #define PORT_CLK_SEL_A 0x46100
> #define PORT_CLK_SEL_B 0x46104
> @@ -4994,6 +4999,7 @@
> #define PORT_CLK_SEL_WRPLL1 (4<<29)
> #define PORT_CLK_SEL_WRPLL2 (5<<29)
> #define PORT_CLK_SEL_NONE (7<<29)
> +#define PORT_CLK_SEL_MASK (7<<29)
>
> /* Transcoder clock selection */
> #define TRANS_CLK_SEL_A0x46140
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b8c096b..a24a375 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1246,6 +1246,74 @@ static void intel_ddi_hot_plug(struct intel_encoder
> *intel_encoder)
> intel_dp_check_link_status(intel_dp);
> }
>
> +static void intel_ddi_get_clock(struct intel_encoder *encoder,
> + struct intel_crtc_config *pipe_config)
> +{
> + struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> + int port = intel_ddi_get_encoder_port(encoder);
> + u32 temp = I915_READ(PORT_CLK_SEL(port)) & PORT_CLK_SEL_MASK;
> + u8 link_bw;
> +
> + if ((temp == PORT_CLK_SEL_LCPLL_810) ||
> + (temp == PORT_CLK_SEL_LCPLL_1350) ||
> + (temp == PORT_CLK_SEL_LCPLL_2700)) {
> +
> + switch (temp) {
> + case PORT_CLK_SEL_LCPLL_810:
> + link_bw = DP_LINK_BW_1_62;
> + break;
> + case PORT_CLK_SEL_LCPLL_1350:
> + link_bw = DP_LINK_BW_2_7;
> + break;
> + case PORT_CLK_SEL_LCPLL_2700:
> + link_bw = DP_LINK_BW_5_4;
> + break;
> + }
> + pipe_config->port_clock =
> drm_dp_bw_code_to_link_rate(link_bw);
> + } else if ((temp == PORT_CLK_SEL_WRPLL1) ||
> + (temp == PORT_CLK_SEL_WRPLL2)) {
> + uint64_t p, n2, r2;
> + u32 val, reg;
> + uint64_t freq2k;
> +
> + switch (temp) {
> + case PORT_CLK_SEL_WRPLL1:
> + reg = WRPLL_CTL1;
> + break;
> + case PORT_CLK_SEL_WRPLL2:
> + reg = WRPLL_CTL2;
> + break;
> + }
> + val = I915_READ(reg);
> + r2 = WRPLL_DIVIDER_REFERENCE_BITS(val);
> + p = WRPLL_DIVIDER_POST_BITS(val);
> + n2 = WRPLL_DIVIDER_FEEDBACK
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #41 from Alex Deucher --- Well, it helps a little, but I'm still able to reproduce it eventually even with the patch. The same kernel source is working fine on a fedora 16 system and now exhibits this problem on Fedora 19. So maybe it's not all gcc. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #40 from queryv...@gmail.com --- (In reply to Alex Deucher from comment #39) > Created attachment 107254 [details] > fix for 3.11 > > The attached patch seems to fix it for me. That doesn't seem to fix it for me (6870). I first tried 3.11-rc6 + drm-next-3.12-wip (ee31b2b), and then 3.11-rc6 + the standalone patch you attached. In the former case, when trying to force a performance level I still got: echo: write error: Invalid argument And the power level still idles at: power level 2sclk: 9 mclk: 105000 vddc: 1175 vddci: 1150 gcc --version gcc (GCC) 4.8.1 20130725 (prerelease) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
Quoting Fabio Estevam (2013-08-20 08:40:52) > On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote: > > > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > index 5a90a72..90e923e 100644 > > --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > @@ -89,8 +89,6 @@ clocks and IDs. > > gpu3d_shader74 > > ipu1_podf 75 > > ipu2_podf 76 > > - ldb_di0_podf77 > > - ldb_di1_podf78 > > ipu1_di0_pre79 > > ipu1_di1_pre80 > > ipu2_di0_pre81 > > This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc How does this fit in with the idea of having a stable binding/ABI? Seems like changing this would be a bad idea for devices in the field that have older DTBs. Regards, Mike > > ___ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[Bug 60775] New: Installing NVIDIA proprietary drivers on kernel 3.10.7-100.fc18.x86_64 errors out . . . can't find kernel source files
https://bugzilla.kernel.org/show_bug.cgi?id=60775 Bug ID: 60775 Summary: Installing NVIDIA proprietary drivers on kernel 3.10.7-100.fc18.x86_64 errors out . . . can't find kernel source files Product: Drivers Version: 2.5 Kernel Version: Linux 3.10.7-100.fc18.x86_64 SMP Hardware: x86-64 OS: Linux Tree: Fedora Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: letourneau.r...@gmail.com Regression: No Trying to install NVIDIA-Linux-x86_64-319.32.run proprietary drivers on kernel 3.10.7-100.fc18.x86_64 does not work. Error; "The kernel header file '/usr/src/linux/include/linux/version.h' does not exist. The most likely reason for this is that the kernel source files in '/usr/src/linux' have not been configured." All necessary source rpms are installed ; kernel-headers-3.10.7-100.fc18.x86_64 kernel-devel-3.10.7-100.fc18.x86_64 and all dependencies. Also downloaded kernel source rpm and installed but did not resolve issue; yumdownloader --source kernel rpm -ivh kernel-3.10.7-100.fc18.src.rpm Tried solution here; http://moldvan.com/blog/?p=824 Did not resolve issue when linking /usr/include/linux/version.h to /usr/src/kernels/`uname -r`/include/linux/version.h But once linked, this error pops up; "If you are using a Linux 2.6 kernel, please make sure you have configured kernel sources matching your kernel installed on your system. If you specified a separate output directory using either the \”KBUILD_OUTPUT\” or the \”O\” KBUILD parameter, make sure to specify this directory with the SYSOUT environment variable or with the equivalent nvidia-installer command line option. Depending on where and how the kernel sources (or the kernel headers) were installed, you may need to specify their location with the SYSSRC environment variable or the equivalent nvidia-installer command line option." The NVIDIA proprietary driver does successfully build on kernel 3.6.10-4.fc18.x86_64. Tried uninstalling kernel-headers and kernel-devel rpms and re-installing, did not resolve issue. Expected results would be, for the NVIDIA proprietary drivers to find correct kernel sources, and successfully build and install driver module. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/i915: add fast boot support for Haswell
Hi
2013/8/19 Furquan Shaikh :
> Enables getting correct mode clock when reading pipe config
> This patch has been tested successfully on top of drm-intel-nightly tree
>
> Signed-off-by: Furquan Shaikh
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6
> drivers/gpu/drm/i915/intel_ddi.c | 70
>
> drivers/gpu/drm/i915/intel_display.c | 1 +
> 3 files changed, 77 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2b96d6b..9511129 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4970,6 +4970,7 @@
> #define SPLL_PLL_NON_SSC (2<<28)
> #define SPLL_PLL_FREQ_810MHz (0<<26)
> #define SPLL_PLL_FREQ_1350MHz (1<<26)
> +#define SPLL_PLL_FREQ_MASK (3<<26)
>
> /* WRPLL */
> #define WRPLL_CTL1 0x46040
> @@ -4983,6 +4984,10 @@
> #define WRPLL_DIVIDER_POST(x) ((x)<<8)
> #define WRPLL_DIVIDER_FEEDBACK(x) ((x)<<16)
>
> +#define WRPLL_DIVIDER_REFERENCE_BITS(reg)(reg & 0xff)
> +#define WRPLL_DIVIDER_POST_BITS(reg) ((reg >> 8) & 0x3f)
> +#define WRPLL_DIVIDER_FEEDBACK_BITS(reg) ((reg >> 16) & 0xff)
> +
> /* Port clock selection */
> #define PORT_CLK_SEL_A 0x46100
> #define PORT_CLK_SEL_B 0x46104
> @@ -4994,6 +4999,7 @@
> #define PORT_CLK_SEL_WRPLL1 (4<<29)
> #define PORT_CLK_SEL_WRPLL2 (5<<29)
> #define PORT_CLK_SEL_NONE (7<<29)
> +#define PORT_CLK_SEL_MASK (7<<29)
>
> /* Transcoder clock selection */
> #define TRANS_CLK_SEL_A0x46140
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b8c096b..a24a375 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1246,6 +1246,74 @@ static void intel_ddi_hot_plug(struct intel_encoder
> *intel_encoder)
> intel_dp_check_link_status(intel_dp);
> }
>
> +static void intel_ddi_get_clock(struct intel_encoder *encoder,
> + struct intel_crtc_config *pipe_config)
> +{
> + struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> + int port = intel_ddi_get_encoder_port(encoder);
> + u32 temp = I915_READ(PORT_CLK_SEL(port)) & PORT_CLK_SEL_MASK;
> + u8 link_bw;
> +
> + if ((temp == PORT_CLK_SEL_LCPLL_810) ||
> + (temp == PORT_CLK_SEL_LCPLL_1350) ||
> + (temp == PORT_CLK_SEL_LCPLL_2700)) {
> +
> + switch (temp) {
> + case PORT_CLK_SEL_LCPLL_810:
> + link_bw = DP_LINK_BW_1_62;
> + break;
> + case PORT_CLK_SEL_LCPLL_1350:
> + link_bw = DP_LINK_BW_2_7;
> + break;
> + case PORT_CLK_SEL_LCPLL_2700:
> + link_bw = DP_LINK_BW_5_4;
> + break;
> + }
> + pipe_config->port_clock =
> drm_dp_bw_code_to_link_rate(link_bw);
drivers/gpu/drm/i915/intel_ddi.c:1275:56: aviso: ‘link_bw’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
Looks like gcc 4.7.3 isn't that smart :( You should probably add a
"default" case with a WARN_ON(1) inside it.
> + } else if ((temp == PORT_CLK_SEL_WRPLL1) ||
> + (temp == PORT_CLK_SEL_WRPLL2)) {
> + uint64_t p, n2, r2;
> + u32 val, reg;
> + uint64_t freq2k;
> +
> + switch (temp) {
> + case PORT_CLK_SEL_WRPLL1:
> + reg = WRPLL_CTL1;
> + break;
> + case PORT_CLK_SEL_WRPLL2:
> + reg = WRPLL_CTL2;
> + break;
> + }
> + val = I915_READ(reg);
drivers/gpu/drm/i915/intel_ddi.c:1290:7: aviso: ‘reg’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
Same thing here.
> + r2 = WRPLL_DIVIDER_REFERENCE_BITS(val);
> + p = WRPLL_DIVIDER_POST_BITS(val);
> + n2 = WRPLL_DIVIDER_FEEDBACK_BITS(val);
> +
> + freq2k = DIV_ROUND_UP_ULL(LC_FREQ * n2, r2 * p);
> + pipe_config->port_clock = freq2k / 10;
If you put the "/ 10" on the line above so it becomes
DIV_ROUND_UP_ULL(LC_FREQ * n2, r2 * p * 10) you'll avoid the rounding
errors of 1 division.
By the way, I applied your patch + Daniel's suggestion on -nightly and
now I see "unclaimed register" errors when booting with HDMI + eDP.
The problem is that we try to read disabled LINK_M/LINK_N registers
due to the power well disabled, so we get the error messages. I also
once saw a "pipe state mismatch" error, but I can't find a way to
reproduce it now. I'm also not sure whether VGA will really work since
we don't touch intel_crt.c (I can't test it for now). When testing the
patches,
[Bug 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem
https://bugzilla.kernel.org/show_bug.cgi?id=60674 --- Comment #15 from Alex Deucher --- (In reply to Dave from comment #14) > (In reply to Michel D?nzer from comment #13) > > Michel you could well be 100% right. While the symptoms may be similar, your issue is completely different, and not kernel related. Please open a new bug on https://bugs.freedesktop.org (for the ddx: product xorg, component Driver/Radeon). -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/radeon/atombios: fix variable sized arrays for newer gccs (v2)
Newer versions of gcc seem to wander off into no-man's land
when using variably sized arrays. Atombios tends to do things
like:
struct object {
u8 version;
u8 num_elements;
u32 elements[1]; /* num_elements entries */
};
We then do things like the following in the driver code:
for (i = 0; i < atom_object->num_elements; i++) {
driver_object[i] = atom_object->elements[i];
}
With previous versions of gcc this used to work fine, but with
4.7 and 4.8, it seems to generate code that wanders off into the
weeds.
According to:
http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
The traditional way of handling variably sized arrays (ISO C90)
is to use an array length of 1. Gcc allows you to use an array
length of 0 and newer versions of gcc only seem to do the
right thing when 0 is used.
This is tricky in this case because atombios.h is shared between
multiple components and is used for allocation in the vbios.
v2: update commit message
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/atombios.h | 100 +++---
1 file changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios.h
b/drivers/gpu/drm/radeon/atombios.h
index 16b120c..3f1f011 100644
--- a/drivers/gpu/drm/radeon/atombios.h
+++ b/drivers/gpu/drm/radeon/atombios.h
@@ -3592,7 +3592,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD
{
UCHAR ucRecordType;
UCHAR ucFakeEDIDLength;
- UCHAR ucFakeEDIDString[1];// This actually has ucFakeEdidLength elements.
+ UCHAR ucFakeEDIDString[0];// This actually has ucFakeEdidLength elements.
} ATOM_FAKE_EDID_PATCH_RECORD;
typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD
@@ -3868,7 +3868,7 @@ typedef struct _ATOM_GPIO_PIN_ASSIGNMENT
typedef struct _ATOM_GPIO_PIN_LUT
{
ATOM_COMMON_TABLE_HEADER sHeader;
- ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[1];
+ ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[0];
}ATOM_GPIO_PIN_LUT;
//
@@ -3995,7 +3995,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH
USHORTusSize;//the size of
ATOM_DISPLAY_OBJECT_PATH
USHORTusConnObjectId;//Connector Object
ID
USHORTusGPUObjectId; //GPU ID
- USHORTusGraphicObjIds[1]; //1st Encoder Obj
source from GPU to last Graphic Obj destinate to connector.
+ USHORTusGraphicObjIds[0]; //1st Encoder Obj
source from GPU to last Graphic Obj destinate to connector.
}ATOM_DISPLAY_OBJECT_PATH;
typedef struct _ATOM_DISPLAY_EXTERNAL_OBJECT_PATH
@@ -4012,7 +4012,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH_TABLE
UCHAR ucNumOfDispPath;
UCHAR ucVersion;
UCHAR ucPadding[2];
- ATOM_DISPLAY_OBJECT_PATHasDispPath[1];
+ ATOM_DISPLAY_OBJECT_PATHasDispPath[0];
}ATOM_DISPLAY_OBJECT_PATH_TABLE;
@@ -4028,15 +4028,15 @@ typedef struct _ATOM_OBJECT_TABLE
//Above 4 object table
{
UCHAR ucNumberOfObjects;
UCHAR ucPadding[3];
- ATOM_OBJECT asObjects[1];
+ ATOM_OBJECT asObjects[0];
}ATOM_OBJECT_TABLE;
typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT
//usSrcDstTableOffset pointing to this structure
{
UCHAR ucNumberOfSrc;
- USHORT usSrcObjectID[1];
+ USHORT usSrcObjectID[0];
UCHAR ucNumberOfDst;
- USHORT usDstObjectID[1];
+ USHORT usDstObjectID[0];
}ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;
@@ -4208,7 +4208,7 @@ typedef struct _ATOM_CONNECTOR_DEVICE_TAG_RECORD
ATOM_COMMON_RECORD_HEADER sheader;
UCHAR ucNumberOfDevice;
UCHAR ucReserved;
- ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[1]; //This Id is same as
"ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
+ ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[0]; //This Id is same as
"ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
}ATOM_CONNECTOR_DEVICE_TAG_RECORD;
@@ -4268,7 +4268,7 @@ typedef struct _ATOM_OBJECT_GPIO_CNTL_RECORD
ATOM_COMMON_RECORD_HEADER sheader;
UCHAR ucFlags;// Future expnadibility
UCHAR ucNumberOfPins; // Number of GPIO pins
used to control the object
- ATOM_GPIO_PIN_CONTROL_PAIR asGpio[1]; // the real gpio pin
pair determined by number of pins ucNumberOfPins
+ ATOM_GPIO_PIN_CONTROL_PAIR asGpio[0]; // the real gpio pin
pair determined by number of pins ucNumberOfPins
}ATOM_OBJECT_GPIO_CNTL_RECORD;
//Definitions for GPIO pin state
@@ -4549,7 +4549,7 @@ typedef struct _ATOM_I2C_VOLTAGE_OBJECT_V3
UCHARucVoltageControlAddress;
UCHARucVolt
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Possibly related to bug 60639. Can you try the patch on that bug? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/radeon/atombios: fix variable sized arrays for
Newer versions of gcc seem to wander off into no-man's land
when using variably sized arrays. Atombios tends to do things
like:
struct object {
u8 version;
u8 num_elements;
u32 elements[1]; /* num_elements entries */
};
We then do things like the following in the driver code:
for (i = 0; i < atom_object->num_elements; i++) {
driver_object[i] = atom_object->elements[i];
}
With previous versions of gcc this used to work fine, but with
4.8, it seems to generate code that wanders off into the weeds.
I'm not sure if array[1] is valid or not for variably sized
arrays in the C standard. switching to array[0] seems to avoid
the problem.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
This patch is against 3.11. I have a different version in my drm-next-3.12-wip
tree for 3.12 due to changes in atombios.h
drivers/gpu/drm/radeon/atombios.h | 100 +++---
1 file changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios.h
b/drivers/gpu/drm/radeon/atombios.h
index 16b120c..3f1f011 100644
--- a/drivers/gpu/drm/radeon/atombios.h
+++ b/drivers/gpu/drm/radeon/atombios.h
@@ -3592,7 +3592,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD
{
UCHAR ucRecordType;
UCHAR ucFakeEDIDLength;
- UCHAR ucFakeEDIDString[1];// This actually has ucFakeEdidLength elements.
+ UCHAR ucFakeEDIDString[0];// This actually has ucFakeEdidLength elements.
} ATOM_FAKE_EDID_PATCH_RECORD;
typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD
@@ -3868,7 +3868,7 @@ typedef struct _ATOM_GPIO_PIN_ASSIGNMENT
typedef struct _ATOM_GPIO_PIN_LUT
{
ATOM_COMMON_TABLE_HEADER sHeader;
- ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[1];
+ ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[0];
}ATOM_GPIO_PIN_LUT;
//
@@ -3995,7 +3995,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH
USHORTusSize;//the size of
ATOM_DISPLAY_OBJECT_PATH
USHORTusConnObjectId;//Connector Object
ID
USHORTusGPUObjectId; //GPU ID
- USHORTusGraphicObjIds[1]; //1st Encoder Obj
source from GPU to last Graphic Obj destinate to connector.
+ USHORTusGraphicObjIds[0]; //1st Encoder Obj
source from GPU to last Graphic Obj destinate to connector.
}ATOM_DISPLAY_OBJECT_PATH;
typedef struct _ATOM_DISPLAY_EXTERNAL_OBJECT_PATH
@@ -4012,7 +4012,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH_TABLE
UCHAR ucNumOfDispPath;
UCHAR ucVersion;
UCHAR ucPadding[2];
- ATOM_DISPLAY_OBJECT_PATHasDispPath[1];
+ ATOM_DISPLAY_OBJECT_PATHasDispPath[0];
}ATOM_DISPLAY_OBJECT_PATH_TABLE;
@@ -4028,15 +4028,15 @@ typedef struct _ATOM_OBJECT_TABLE
//Above 4 object table
{
UCHAR ucNumberOfObjects;
UCHAR ucPadding[3];
- ATOM_OBJECT asObjects[1];
+ ATOM_OBJECT asObjects[0];
}ATOM_OBJECT_TABLE;
typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT
//usSrcDstTableOffset pointing to this structure
{
UCHAR ucNumberOfSrc;
- USHORT usSrcObjectID[1];
+ USHORT usSrcObjectID[0];
UCHAR ucNumberOfDst;
- USHORT usDstObjectID[1];
+ USHORT usDstObjectID[0];
}ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;
@@ -4208,7 +4208,7 @@ typedef struct _ATOM_CONNECTOR_DEVICE_TAG_RECORD
ATOM_COMMON_RECORD_HEADER sheader;
UCHAR ucNumberOfDevice;
UCHAR ucReserved;
- ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[1]; //This Id is same as
"ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
+ ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[0]; //This Id is same as
"ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
}ATOM_CONNECTOR_DEVICE_TAG_RECORD;
@@ -4268,7 +4268,7 @@ typedef struct _ATOM_OBJECT_GPIO_CNTL_RECORD
ATOM_COMMON_RECORD_HEADER sheader;
UCHAR ucFlags;// Future expnadibility
UCHAR ucNumberOfPins; // Number of GPIO pins
used to control the object
- ATOM_GPIO_PIN_CONTROL_PAIR asGpio[1]; // the real gpio pin
pair determined by number of pins ucNumberOfPins
+ ATOM_GPIO_PIN_CONTROL_PAIR asGpio[0]; // the real gpio pin
pair determined by number of pins ucNumberOfPins
}ATOM_OBJECT_GPIO_CNTL_RECORD;
//Definitions for GPIO pin state
@@ -4549,7 +4549,7 @@ typedef struct _ATOM_I2C_VOLTAGE_OBJECT_V3
UCHARucVoltageControlAddress;
UCHARucVoltageControlOffset;
ULONGulReserved;
- VOLTAGE_LUT_ENTRY asVolI2cLut[1];// end with 0xff
+ VOLTAGE_LUT_ENTRY asVolI2cLut[0];// end with 0xff
[PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote: > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > index 5a90a72..90e923e 100644 > --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > @@ -89,8 +89,6 @@ clocks and IDs. > gpu3d_shader74 > ipu1_podf 75 > ipu2_podf 76 > - ldb_di0_podf77 > - ldb_di1_podf78 > ipu1_di0_pre79 > ipu1_di1_pre80 > ipu2_di0_pre81 This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc
Re: [PATCH 1/2] [RFC PATCH v6] dmabuf-sync: Add a buffer synchronization framework
On Tue, Aug 13, 2013 at 06:19:35PM +0900, Inki Dae wrote: > This patch adds a buffer synchronization framework based on DMA BUF[1] > and and based on ww-mutexes[2] for lock mechanism. > > The purpose of this framework is to provide not only buffer access control > to CPU and DMA but also easy-to-use interfaces for device drivers and > user application. This framework can be used for all dma devices using > system memory as dma buffer, especially for most ARM based SoCs. > > Changelog v6: > - Fix sync lock to multiple reads. > - Add select system call support. > . Wake up poll_wait when a dmabuf is unlocked. > - Remove unnecessary the use of mutex lock. > - Add private backend ops callbacks. > . This ops has one callback for device drivers to clean up their > sync object resource when the sync object is freed. For this, > device drivers should implement the free callback properly. > - Update document file. > > Changelog v5: > - Rmove a dependence on reservation_object: the reservation_object is used > to hook up to ttm and dma-buf for easy sharing of reservations across > devices. However, the dmabuf sync can be used for all dma devices; v4l2 > and drm based drivers, so doesn't need the reservation_object anymore. > With regared to this, it adds 'void *sync' to dma_buf structure. > - All patches are rebased on mainline, Linux v3.10. > > Changelog v4: > - Add user side interface for buffer synchronization mechanism and update > descriptions related to the user side interface. > > Changelog v3: > - remove cache operation relevant codes and update document file. > > Changelog v2: > - use atomic_add_unless to avoid potential bug. > - add a macro for checking valid access type. > - code clean. > > The mechanism of this framework has the following steps, > 1. Register dmabufs to a sync object - A task gets a new sync object and > can add one or more dmabufs that the task wants to access. > This registering should be performed when a device context or an event > context such as a page flip event is created or before CPU accesses a > shared > buffer. > > dma_buf_sync_get(a sync object, a dmabuf); > > 2. Lock a sync object - A task tries to lock all dmabufs added in its own > sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead > lock issue and for race condition between CPU and CPU, CPU and DMA, and > DMA > and DMA. Taking a lock means that others cannot access all locked dmabufs > until the task that locked the corresponding dmabufs, unlocks all the > locked > dmabufs. > This locking should be performed before DMA or CPU accesses these dmabufs. > > dma_buf_sync_lock(a sync object); > > 3. Unlock a sync object - The task unlocks all dmabufs added in its own > sync > object. The unlock means that the DMA or CPU accesses to the dmabufs have > been completed so that others may access them. > This unlocking should be performed after DMA or CPU has completed accesses > to the dmabufs. > > dma_buf_sync_unlock(a sync object); > > 4. Unregister one or all dmabufs from a sync object - A task unregisters > the given dmabufs from the sync object. This means that the task dosen't > want to lock the dmabufs. > The unregistering should be performed after DMA or CPU has completed > accesses to the dmabufs or when dma_buf_sync_lock() is failed. > > dma_buf_sync_put(a sync object, a dmabuf); > dma_buf_sync_put_all(a sync object); > > The described steps may be summarized as: > get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put > > This framework includes the following two features. > 1. read (shared) and write (exclusive) locks - A task is required to > declare > the access type when the task tries to register a dmabuf; > READ, WRITE, READ DMA, or WRITE DMA. > > The below is example codes, > struct dmabuf_sync *sync; > > sync = dmabuf_sync_init(...); > ... > > dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R); > ... > > And the below can be used as access types: > DMA_BUF_ACCESS_R - CPU will access a buffer for read. > DMA_BUF_ACCESS_W - CPU will access a buffer for read or write. > DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read > DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or > write. > > 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. > A task may never try to unlock a buffer after taking a lock to the buffer. > In this case, a timer handler to the corresponding sync object is called > in five (default) seconds and then the timed-out buffer is unlocked by > work > queue handler to avoid lockups and to enforce resources of the buffer. > > The below is how to use interfaces for device driver: > 1. Allocate an
[PATCH] drm/radeon: fix LCD record parsing
If the LCD table contains an EDID record, properly account for the edid size when walking through the records. This should fix error messages about unknown LCD records. Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org --- drivers/gpu/drm/radeon/radeon_atombios.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c index 4ac5f40..112c963 100644 --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c @@ -1681,7 +1681,9 @@ struct radeon_encoder_atom_dig *radeon_atombios_get_lvds_info(struct kfree(edid); } } - record += sizeof(ATOM_FAKE_EDID_PATCH_RECORD); + record += fake_edid_record->ucFakeEDIDLength ? + fake_edid_record->ucFakeEDIDLength + 2 : + sizeof(ATOM_FAKE_EDID_PATCH_RECORD); break; case LCD_PANEL_RESOLUTION_RECORD_TYPE: panel_res_record = (ATOM_PANEL_RESOLUTION_PATCH_RECORD *)record; -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm/radeon: rework to new fence interface
Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
[SNIP]
> [SNIP]
> +/**
> + * radeon_fence_enable_signaling - enable signalling on fence
> + * @fence: fence
> + *
> + * This function is called with fence_queue lock held, and adds a
> callback
> + * to fence_queue that checks if this fence is signaled, and if so it
> + * signals the fence and removes itself.
> + */
> +static bool radeon_fence_enable_signaling(struct fence *f)
> +{
> +struct radeon_fence *fence = to_radeon_fence(f);
> +
> +if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
> fence->seq ||
> +!fence->rdev->ddev->irq_enabled)
> +return false;
> +
Do I get that right that you rely on IRQs to be enabled and working here?
Cause that would be a quite bad idea from the conceptual side.
>>> For cross-device synchronization it would be nice to have working irqs, it
>>> allows signalling fences faster,
>>> and it allows for callbacks on completion to be called. For internal usage
>>> it's no more required than it was before.
>> That's a big NAK.
>>
>> The fence processing is actually very fine tuned to avoid IRQs and as far as
>> I can see you just leave them enabled by decrementing the atomic from IRQ
>> context. Additional to that we need allot of special handling in case of a
>> hardware lockup here, which isn't done if you abuse the fence interface like
>> this.
> I think it's not needed to leave the irq enabled, it's a leftover from when I
> was debugging the mac and no interrupt occurred at all.
>
>> Also your approach of leaking the IRQ context outside of the driver is a
>> very bad idea from the conceptual side. Please don't modify the fence
>> interface at all and instead use the wait functions already exposed by
>> radeon_fence.c. If you need some kind of signaling mechanism then wait
>> inside a workqueue instead.
> The fence takes up the role of a single shot workqueue here. Manually
> resetting the counter and calling wake_up_all would end up waking all active
> fences, there's no special handling needed inside radeon for this.
Yeah that's actually the point here, you NEED to activate ALL fences,
otherwise the fence handling inside the driver won't work.
> The fence api does provide a synchronous wait function, but this causes a
> stall of whomever waits on it.
Which is perfectly fine. What actually is the use case of not stalling a
process who wants to wait for something?
> When I was testing this with intel I used the fence callback to poke a
> register in i915, this allowed it to not block until it hits the wait op in
> the command stream, and even then only if the callback was not called first.
>
> It's documented that the callbacks can be called from any context and will be
> called with irqs disabled, so nothing scary should be done. The kernel
> provides enough debug mechanisms to find any violators.
> PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
No thanks, we even abandoned that concept internal in the driver. Please
use the blocking wait functions instead.
Christian.
[PATCH 0/3] refactor some ldb related clocks
Am Dienstag, den 20.08.2013, 16:38 +0800 schrieb Liu Ying: > The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register > of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5 > drivider or a 1/7 divider. The common clock framework cannot > deal with the two dividers directly even with the divider table > which only supports integral dividers. So, the idea is to take > the 1/3.5 and 1/7 dividers as separate fixed factor dividers and > introduce a new multiplexer clock to be derived from the them. > Then, the ldb display clock trees can be setup correctly. > This series contains the necessary clock driver changes, dts code > changes and imx-drm/ldb driver changes to fullfill the task. I don't see how this improves the situation. Does this solve any real problem? While I admit to having introduced the combination of 1/3.5 fixed divider and configurable 1/1,1/2 divder clocks to describe this fractional divider for the reasons you state, I think the correct solution would be to improve the table divider to support fractional values and get rid of the virtual ldb_di_div_3_5 clocks, not introduce more virtual clocks. regards Philipp
[RFC PATCH] drm/radeon: rework to new fence interface
Op 20-08-13 10:37, Christian K?nig schreef:
> Am 19.08.2013 21:37, schrieb Maarten Lankhorst:
>> Op 19-08-13 14:35, Christian K?nig schreef:
>>> Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
[SNIP]
@@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device
*rdev, int ring)
}
} while (atomic64_xchg(&rdev->fence_drv[ring].last_seq, seq) > seq);
-if (wake) {
+if (wake)
rdev->fence_drv[ring].last_activity = jiffies;
-wake_up_all(&rdev->fence_queue);
-}
+return wake;
}
>>> Very bad idea, when sequence numbers change, you always want to wake up the
>>> whole fence queue here.
>> Yes, and the callers of this function call wake_up_all or wake_up_all_locked
>> themselves, based on the return value..
>
> And as I said that's a very bad idea. The fence processing shouldn't be
> called with any locks held and should be self responsible for activating any
> waiters.
The call point (enable_signaling) only needs to know whether its own counter
has passed or not. This prevents the race where the counter
has elapsed, but the irq was not yet enabled.
I don't really care if enable_signaling updates last_seq or not, it only needs
to check if it's own fence has been signaled after enabling sw_irqs.
>>
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a callback
+ * to fence_queue that checks if this fence is signaled, and if so it
+ * signals the fence and removes itself.
+ */
+static bool radeon_fence_enable_signaling(struct fence *f)
+{
+struct radeon_fence *fence = to_radeon_fence(f);
+
+if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
fence->seq ||
+!fence->rdev->ddev->irq_enabled)
+return false;
+
>>> Do I get that right that you rely on IRQs to be enabled and working here?
>>> Cause that would be a quite bad idea from the conceptual side.
>> For cross-device synchronization it would be nice to have working irqs, it
>> allows signalling fences faster,
>> and it allows for callbacks on completion to be called. For internal usage
>> it's no more required than it was before.
>
> That's a big NAK.
>
> The fence processing is actually very fine tuned to avoid IRQs and as far as
> I can see you just leave them enabled by decrementing the atomic from IRQ
> context. Additional to that we need allot of special handling in case of a
> hardware lockup here, which isn't done if you abuse the fence interface like
> this.
I think it's not needed to leave the irq enabled, it's a leftover from when I
was debugging the mac and no interrupt occurred at all.
> Also your approach of leaking the IRQ context outside of the driver is a very
> bad idea from the conceptual side. Please don't modify the fence interface at
> all and instead use the wait functions already exposed by radeon_fence.c. If
> you need some kind of signaling mechanism then wait inside a workqueue
> instead.
The fence takes up the role of a single shot workqueue here. Manually resetting
the counter and calling wake_up_all would end up waking all active fences,
there's no special handling needed inside radeon for this.
The fence api does provide a synchronous wait function, but this causes a stall
of whomever waits on it. When I was testing this with intel I used the fence
callback to poke a register in i915, this allowed it to not block until it hits
the wait op in the command stream, and even then only if the callback was not
called first.
It's documented that the callbacks can be called from any context and will be
called with irqs disabled, so nothing scary should be done. The kernel provides
enough debug mechanisms to find any violators.
PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
~Maarten
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 Timothée Ravier changed: What|Removed |Added Attachment #84347|0 |1 is obsolete|| --- Comment #10 from Timothée Ravier --- Created attachment 84354 --> https://bugs.freedesktop.org/attachment.cgi?id=84354&action=edit New dmesg log with patched kernel This is the new dmesg log. I tried the patch but the bug is still here in my case. However the "Bad LCD record" error is different now and some lines in the end are not in the new log. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm/radeon: rework to new fence interface
Am 19.08.2013 21:37, schrieb Maarten Lankhorst:
> Op 19-08-13 14:35, Christian K?nig schreef:
>> Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
>>> [SNIP]
>>> @@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device *rdev,
>>> int ring)
>>>}
>>>} while (atomic64_xchg(&rdev->fence_drv[ring].last_seq, seq) > seq);
>>>-if (wake) {
>>> +if (wake)
>>>rdev->fence_drv[ring].last_activity = jiffies;
>>> -wake_up_all(&rdev->fence_queue);
>>> -}
>>> +return wake;
>>>}
>> Very bad idea, when sequence numbers change, you always want to wake up the
>> whole fence queue here.
> Yes, and the callers of this function call wake_up_all or wake_up_all_locked
> themselves, based on the return value..
And as I said that's a very bad idea. The fence processing shouldn't be
called with any locks held and should be self responsible for activating
any waiters.
>
>>> [SNIP]
>>> +/**
>>> + * radeon_fence_enable_signaling - enable signalling on fence
>>> + * @fence: fence
>>> + *
>>> + * This function is called with fence_queue lock held, and adds a callback
>>> + * to fence_queue that checks if this fence is signaled, and if so it
>>> + * signals the fence and removes itself.
>>> + */
>>> +static bool radeon_fence_enable_signaling(struct fence *f)
>>> +{
>>> +struct radeon_fence *fence = to_radeon_fence(f);
>>> +
>>> +if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
>>> fence->seq ||
>>> +!fence->rdev->ddev->irq_enabled)
>>> +return false;
>>> +
>> Do I get that right that you rely on IRQs to be enabled and working here?
>> Cause that would be a quite bad idea from the conceptual side.
> For cross-device synchronization it would be nice to have working irqs, it
> allows signalling fences faster,
> and it allows for callbacks on completion to be called. For internal usage
> it's no more required than it was before.
That's a big NAK.
The fence processing is actually very fine tuned to avoid IRQs and as
far as I can see you just leave them enabled by decrementing the atomic
from IRQ context. Additional to that we need allot of special handling
in case of a hardware lockup here, which isn't done if you abuse the
fence interface like this.
Also your approach of leaking the IRQ context outside of the driver is a
very bad idea from the conceptual side. Please don't modify the fence
interface at all and instead use the wait functions already exposed by
radeon_fence.c. If you need some kind of signaling mechanism then wait
inside a workqueue instead.
Christian.
[PATCH] drm/radeon/atombios: fix variable sized arrays for newer gccs (v2)
Newer versions of gcc seem to wander off into no-man's land
when using variably sized arrays. Atombios tends to do things
like:
struct object {
u8 version;
u8 num_elements;
u32 elements[1]; /* num_elements entries */
};
We then do things like the following in the driver code:
for (i = 0; i < atom_object->num_elements; i++) {
driver_object[i] = atom_object->elements[i];
}
With previous versions of gcc this used to work fine, but with
4.7 and 4.8, it seems to generate code that wanders off into the
weeds.
According to:
http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
The traditional way of handling variably sized arrays (ISO C90)
is to use an array length of 1. Gcc allows you to use an array
length of 0 and newer versions of gcc only seem to do the
right thing when 0 is used.
This is tricky in this case because atombios.h is shared between
multiple components and is used for allocation in the vbios.
v2: update commit message
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/atombios.h | 100 +++---
1 file changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios.h
b/drivers/gpu/drm/radeon/atombios.h
index 16b120c..3f1f011 100644
--- a/drivers/gpu/drm/radeon/atombios.h
+++ b/drivers/gpu/drm/radeon/atombios.h
@@ -3592,7 +3592,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD
{
UCHAR ucRecordType;
UCHAR ucFakeEDIDLength;
- UCHAR ucFakeEDIDString[1];// This actually has ucFakeEdidLength elements.
+ UCHAR ucFakeEDIDString[0];// This actually has ucFakeEdidLength elements.
} ATOM_FAKE_EDID_PATCH_RECORD;
typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD
@@ -3868,7 +3868,7 @@ typedef struct _ATOM_GPIO_PIN_ASSIGNMENT
typedef struct _ATOM_GPIO_PIN_LUT
{
ATOM_COMMON_TABLE_HEADER sHeader;
- ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[1];
+ ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[0];
}ATOM_GPIO_PIN_LUT;
//
@@ -3995,7 +3995,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH
USHORTusSize;//the size of
ATOM_DISPLAY_OBJECT_PATH
USHORTusConnObjectId;//Connector Object
ID
USHORTusGPUObjectId; //GPU ID
- USHORTusGraphicObjIds[1]; //1st Encoder Obj
source from GPU to last Graphic Obj destinate to connector.
+ USHORTusGraphicObjIds[0]; //1st Encoder Obj
source from GPU to last Graphic Obj destinate to connector.
}ATOM_DISPLAY_OBJECT_PATH;
typedef struct _ATOM_DISPLAY_EXTERNAL_OBJECT_PATH
@@ -4012,7 +4012,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH_TABLE
UCHAR ucNumOfDispPath;
UCHAR ucVersion;
UCHAR ucPadding[2];
- ATOM_DISPLAY_OBJECT_PATHasDispPath[1];
+ ATOM_DISPLAY_OBJECT_PATHasDispPath[0];
}ATOM_DISPLAY_OBJECT_PATH_TABLE;
@@ -4028,15 +4028,15 @@ typedef struct _ATOM_OBJECT_TABLE
//Above 4 object table
{
UCHAR ucNumberOfObjects;
UCHAR ucPadding[3];
- ATOM_OBJECT asObjects[1];
+ ATOM_OBJECT asObjects[0];
}ATOM_OBJECT_TABLE;
typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT
//usSrcDstTableOffset pointing to this structure
{
UCHAR ucNumberOfSrc;
- USHORT usSrcObjectID[1];
+ USHORT usSrcObjectID[0];
UCHAR ucNumberOfDst;
- USHORT usDstObjectID[1];
+ USHORT usDstObjectID[0];
}ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;
@@ -4208,7 +4208,7 @@ typedef struct _ATOM_CONNECTOR_DEVICE_TAG_RECORD
ATOM_COMMON_RECORD_HEADER sheader;
UCHAR ucNumberOfDevice;
UCHAR ucReserved;
- ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[1]; //This Id is same as
"ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
+ ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[0]; //This Id is same as
"ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
}ATOM_CONNECTOR_DEVICE_TAG_RECORD;
@@ -4268,7 +4268,7 @@ typedef struct _ATOM_OBJECT_GPIO_CNTL_RECORD
ATOM_COMMON_RECORD_HEADER sheader;
UCHAR ucFlags;// Future expnadibility
UCHAR ucNumberOfPins; // Number of GPIO pins
used to control the object
- ATOM_GPIO_PIN_CONTROL_PAIR asGpio[1]; // the real gpio pin
pair determined by number of pins ucNumberOfPins
+ ATOM_GPIO_PIN_CONTROL_PAIR asGpio[0]; // the real gpio pin
pair determined by number of pins ucNumberOfPins
}ATOM_OBJECT_GPIO_CNTL_RECORD;
//Definitions for GPIO pin state
@@ -4549,7 +4549,7 @@ typedef struct _ATOM_I2C_VOLTAGE_OBJECT_V3
UCHARucVoltageControlAddress;
UCHAR
A gentle scrub
On Mon, Aug 19, 2013 at 7:53 PM, Damien Lespiau wrote: > A small pass on drm headers to remove some stale prototypes/functions/defines > and to make static a few functions. For the series: Reviewed-by: Alex Deucher > > drivers/gpu/drm/drm_crtc.c | 38 > +++-- > drivers/gpu/drm/drm_fb_cma_helper.c | 5 ++--- > drivers/gpu/drm/drm_modes.c | 21 > drivers/gpu/drm/drm_platform.c | 7 +++ > include/drm/drmP.h | 8 > include/drm/drm_crtc.h | 17 - > include/drm/drm_fb_cma_helper.h | 1 - > include/drm/drm_pciids.h| 30 - > 8 files changed, 8 insertions(+), 119 deletions(-) > > -- > Damien > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/atombios: fix variable sized arrays for
Newer versions of gcc seem to wander off into no-man's land
when using variably sized arrays. Atombios tends to do things
like:
struct object {
u8 version;
u8 num_elements;
u32 elements[1]; /* num_elements entries */
};
We then do things like the following in the driver code:
for (i = 0; i < atom_object->num_elements; i++) {
driver_object[i] = atom_object->elements[i];
}
With previous versions of gcc this used to work fine, but with
4.8, it seems to generate code that wanders off into the weeds.
I'm not sure if array[1] is valid or not for variably sized
arrays in the C standard. switching to array[0] seems to avoid
the problem.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
This patch is against 3.11. I have a different version in my drm-next-3.12-wip
tree for 3.12 due to changes in atombios.h
drivers/gpu/drm/radeon/atombios.h | 100 +++---
1 file changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios.h
b/drivers/gpu/drm/radeon/atombios.h
index 16b120c..3f1f011 100644
--- a/drivers/gpu/drm/radeon/atombios.h
+++ b/drivers/gpu/drm/radeon/atombios.h
@@ -3592,7 +3592,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD
{
UCHAR ucRecordType;
UCHAR ucFakeEDIDLength;
- UCHAR ucFakeEDIDString[1];// This actually has ucFakeEdidLength elements.
+ UCHAR ucFakeEDIDString[0];// This actually has ucFakeEdidLength elements.
} ATOM_FAKE_EDID_PATCH_RECORD;
typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD
@@ -3868,7 +3868,7 @@ typedef struct _ATOM_GPIO_PIN_ASSIGNMENT
typedef struct _ATOM_GPIO_PIN_LUT
{
ATOM_COMMON_TABLE_HEADER sHeader;
- ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[1];
+ ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[0];
}ATOM_GPIO_PIN_LUT;
//
@@ -3995,7 +3995,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH
USHORTusSize;//the size of
ATOM_DISPLAY_OBJECT_PATH
USHORTusConnObjectId;//Connector Object
ID
USHORTusGPUObjectId; //GPU ID
- USHORTusGraphicObjIds[1]; //1st Encoder Obj
source from GPU to last Graphic Obj destinate to connector.
+ USHORTusGraphicObjIds[0]; //1st Encoder Obj
source from GPU to last Graphic Obj destinate to connector.
}ATOM_DISPLAY_OBJECT_PATH;
typedef struct _ATOM_DISPLAY_EXTERNAL_OBJECT_PATH
@@ -4012,7 +4012,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH_TABLE
UCHAR ucNumOfDispPath;
UCHAR ucVersion;
UCHAR ucPadding[2];
- ATOM_DISPLAY_OBJECT_PATHasDispPath[1];
+ ATOM_DISPLAY_OBJECT_PATHasDispPath[0];
}ATOM_DISPLAY_OBJECT_PATH_TABLE;
@@ -4028,15 +4028,15 @@ typedef struct _ATOM_OBJECT_TABLE
//Above 4 object table
{
UCHAR ucNumberOfObjects;
UCHAR ucPadding[3];
- ATOM_OBJECT asObjects[1];
+ ATOM_OBJECT asObjects[0];
}ATOM_OBJECT_TABLE;
typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT
//usSrcDstTableOffset pointing to this structure
{
UCHAR ucNumberOfSrc;
- USHORT usSrcObjectID[1];
+ USHORT usSrcObjectID[0];
UCHAR ucNumberOfDst;
- USHORT usDstObjectID[1];
+ USHORT usDstObjectID[0];
}ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;
@@ -4208,7 +4208,7 @@ typedef struct _ATOM_CONNECTOR_DEVICE_TAG_RECORD
ATOM_COMMON_RECORD_HEADER sheader;
UCHAR ucNumberOfDevice;
UCHAR ucReserved;
- ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[1]; //This Id is same as
"ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
+ ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[0]; //This Id is same as
"ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
}ATOM_CONNECTOR_DEVICE_TAG_RECORD;
@@ -4268,7 +4268,7 @@ typedef struct _ATOM_OBJECT_GPIO_CNTL_RECORD
ATOM_COMMON_RECORD_HEADER sheader;
UCHAR ucFlags;// Future expnadibility
UCHAR ucNumberOfPins; // Number of GPIO pins
used to control the object
- ATOM_GPIO_PIN_CONTROL_PAIR asGpio[1]; // the real gpio pin
pair determined by number of pins ucNumberOfPins
+ ATOM_GPIO_PIN_CONTROL_PAIR asGpio[0]; // the real gpio pin
pair determined by number of pins ucNumberOfPins
}ATOM_OBJECT_GPIO_CNTL_RECORD;
//Definitions for GPIO pin state
@@ -4549,7 +4549,7 @@ typedef struct _ATOM_I2C_VOLTAGE_OBJECT_V3
UCHARucVoltageControlAddress;
UCHARucVoltageControlOffset;
ULONGulReserved;
- VOLTAGE_LUT_ENTRY asVolI2cLut[1];// end with 0xff
+ VOLTAGE_LUT_ENTRY asVolI2cLut[0];// end wi
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #9 from Alex Deucher --- You might try this patch: http://people.freedesktop.org/~agd5f/0001-drm-radeon-atombios-fix-variable-sized-arrays-for.patch -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #39 from Alex Deucher --- Created attachment 107254 --> https://bugzilla.kernel.org/attachment.cgi?id=107254&action=edit fix for 3.11 The attached patch seems to fix it for me. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #8 from Timothée Ravier --- Look alike bug here: screen goes black and freeze for a while when playing the second video using VDPAU with mplayer. Upon "screen return", the whole display is corrupted and unusable, requiring reboot. Arch Linux testing packages except for the kernel which is custom build. Card: Radeon Mobility 4650 HD Linux kernel: 3.11rc6 (commit: b36f4be, it's called -dirty in the dmesg log but I don't know why, will try to figure that out) Mesa: 9.2.0rc1 OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0-rc1 OpenGL core profile shading language version string: 1.40 OpenGL core profile context flags: (none) OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 9.2.0-rc1 OpenGL shading language version string: 1.30 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #7 from Timothée Ravier --- Created attachment 84347 --> https://bugs.freedesktop.org/attachment.cgi?id=84347&action=edit dmesg log -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] drm: Make drm_get_platform_dev() static
On Tue, Aug 20, 2013 at 07:56:42AM -0700, Ian Romanick wrote:
> On 08/19/2013 04:53 PM, Damien Lespiau wrote:
> >It's only used in drm_platform.c.
> >
> >Signed-off-by: Damien Lespiau
> >---
> > drivers/gpu/drm/drm_platform.c | 7 +++
> > include/drm/drmP.h | 3 ---
> > 2 files changed, 3 insertions(+), 7 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
> >index b8a282e..400024b 100644
> >--- a/drivers/gpu/drm/drm_platform.c
> >+++ b/drivers/gpu/drm/drm_platform.c
> >@@ -28,7 +28,7 @@
> > #include
> > #include
> >
> >-/**
> >+/*
> > * Register.
> > *
> > * \param platdev - Platform device struture
>
> Was this change intentional? The rest of the comment is doxygen still.
It was indeed, just to stop documentation tools from picking up that
symbol that is not exported anymore. The documentation blob still
contains markup to tag the parameters though, might as well leave it
there.
--
Damien
>
> >@@ -39,8 +39,8 @@
> > * Try and register, if we fail to register, backout previous work.
> > */
> >
> >-int drm_get_platform_dev(struct platform_device *platdev,
> >- struct drm_driver *driver)
> >+static int drm_get_platform_dev(struct platform_device *platdev,
> >+struct drm_driver *driver)
> > {
> > struct drm_device *dev;
> > int ret;
> >@@ -107,7 +107,6 @@ err_g1:
> > mutex_unlock(&drm_global_mutex);
> > return ret;
> > }
> >-EXPORT_SYMBOL(drm_get_platform_dev);
> >
> > static int drm_platform_get_irq(struct drm_device *dev)
> > {
> >diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> >index 046a7db..1a7a78f 100644
> >--- a/include/drm/drmP.h
> >+++ b/include/drm/drmP.h
> >@@ -1657,9 +1657,6 @@ extern int drm_pcie_get_speed_cap_mask(struct
> >drm_device *dev, u32 *speed_mask);
> > extern int drm_platform_init(struct drm_driver *driver, struct
> > platform_device *platform_device);
> > extern void drm_platform_exit(struct drm_driver *driver, struct
> > platform_device *platform_device);
> >
> >-extern int drm_get_platform_dev(struct platform_device *pdev,
> >-struct drm_driver *driver);
> >-
> > /* returns true if currently okay to sleep */
> > static __inline__ bool drm_can_sleep(void)
> > {
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #38 from Tobias Droste --- I don't want to say that it's not a gcc bug, but I'm using gcc 4.7: gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote: > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > index 5a90a72..90e923e 100644 > --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > @@ -89,8 +89,6 @@ clocks and IDs. > gpu3d_shader74 > ipu1_podf 75 > ipu2_podf 76 > - ldb_di0_podf77 > - ldb_di1_podf78 > ipu1_di0_pre79 > ipu1_di1_pre80 > ipu2_di0_pre81 This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] drm: Make drm_get_platform_dev() static
On 08/19/2013 04:53 PM, Damien Lespiau wrote:
It's only used in drm_platform.c.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_platform.c | 7 +++
include/drm/drmP.h | 3 ---
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index b8a282e..400024b 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -28,7 +28,7 @@
#include
#include
-/**
+/*
* Register.
*
* \param platdev - Platform device struture
Was this change intentional? The rest of the comment is doxygen still.
@@ -39,8 +39,8 @@
* Try and register, if we fail to register, backout previous work.
*/
-int drm_get_platform_dev(struct platform_device *platdev,
-struct drm_driver *driver)
+static int drm_get_platform_dev(struct platform_device *platdev,
+ struct drm_driver *driver)
{
struct drm_device *dev;
int ret;
@@ -107,7 +107,6 @@ err_g1:
mutex_unlock(&drm_global_mutex);
return ret;
}
-EXPORT_SYMBOL(drm_get_platform_dev);
static int drm_platform_get_irq(struct drm_device *dev)
{
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 046a7db..1a7a78f 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1657,9 +1657,6 @@ extern int drm_pcie_get_speed_cap_mask(struct drm_device
*dev, u32 *speed_mask);
extern int drm_platform_init(struct drm_driver *driver, struct
platform_device *platform_device);
extern void drm_platform_exit(struct drm_driver *driver, struct
platform_device *platform_device);
-extern int drm_get_platform_dev(struct platform_device *pdev,
- struct drm_driver *driver);
-
/* returns true if currently okay to sleep */
static __inline__ bool drm_can_sleep(void)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm: Make drm_get_platform_dev() static
On 08/19/2013 04:53 PM, Damien Lespiau wrote:
> It's only used in drm_platform.c.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_platform.c | 7 +++
> include/drm/drmP.h | 3 ---
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
> index b8a282e..400024b 100644
> --- a/drivers/gpu/drm/drm_platform.c
> +++ b/drivers/gpu/drm/drm_platform.c
> @@ -28,7 +28,7 @@
> #include
> #include
>
> -/**
> +/*
>* Register.
>*
>* \param platdev - Platform device struture
Was this change intentional? The rest of the comment is doxygen still.
> @@ -39,8 +39,8 @@
>* Try and register, if we fail to register, backout previous work.
>*/
>
> -int drm_get_platform_dev(struct platform_device *platdev,
> - struct drm_driver *driver)
> +static int drm_get_platform_dev(struct platform_device *platdev,
> + struct drm_driver *driver)
> {
> struct drm_device *dev;
> int ret;
> @@ -107,7 +107,6 @@ err_g1:
> mutex_unlock(&drm_global_mutex);
> return ret;
> }
> -EXPORT_SYMBOL(drm_get_platform_dev);
>
> static int drm_platform_get_irq(struct drm_device *dev)
> {
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 046a7db..1a7a78f 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1657,9 +1657,6 @@ extern int drm_pcie_get_speed_cap_mask(struct
> drm_device *dev, u32 *speed_mask);
> extern int drm_platform_init(struct drm_driver *driver, struct
> platform_device *platform_device);
> extern void drm_platform_exit(struct drm_driver *driver, struct
> platform_device *platform_device);
>
> -extern int drm_get_platform_dev(struct platform_device *pdev,
> - struct drm_driver *driver);
> -
> /* returns true if currently okay to sleep */
> static __inline__ bool drm_can_sleep(void)
> {
>
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #37 from Alex Deucher --- I was finally able to reproduce this, but only with gcc 4.8. Older versions of gcc work fine. Looks like the gcc bug has struck again. See: https://bugs.freedesktop.org/show_bug.cgi?id=66932 Now to find what other part gcc doesn't like... -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/radeon: rework to new fence interface
Am 20.08.2013 15:21, schrieb Maarten Lankhorst:
Op 20-08-13 11:51, Christian König schreef:
Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
[SNIP]
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a callback
+ * to fence_queue that checks if this fence is signaled, and if so it
+ * signals the fence and removes itself.
+ */
+static bool radeon_fence_enable_signaling(struct fence *f)
+{
+struct radeon_fence *fence = to_radeon_fence(f);
+
+if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
fence->seq ||
+!fence->rdev->ddev->irq_enabled)
+return false;
+
Do I get that right that you rely on IRQs to be enabled and working here? Cause
that would be a quite bad idea from the conceptual side.
For cross-device synchronization it would be nice to have working irqs, it
allows signalling fences faster,
and it allows for callbacks on completion to be called. For internal usage it's
no more required than it was before.
That's a big NAK.
The fence processing is actually very fine tuned to avoid IRQs and as far as I
can see you just leave them enabled by decrementing the atomic from IRQ
context. Additional to that we need allot of special handling in case of a
hardware lockup here, which isn't done if you abuse the fence interface like
this.
I think it's not needed to leave the irq enabled, it's a leftover from when I
was debugging the mac and no interrupt occurred at all.
Also your approach of leaking the IRQ context outside of the driver is a very
bad idea from the conceptual side. Please don't modify the fence interface at
all and instead use the wait functions already exposed by radeon_fence.c. If
you need some kind of signaling mechanism then wait inside a workqueue instead.
The fence takes up the role of a single shot workqueue here. Manually resetting
the counter and calling wake_up_all would end up waking all active fences,
there's no special handling needed inside radeon for this.
Yeah that's actually the point here, you NEED to activate ALL fences, otherwise
the fence handling inside the driver won't work.
It's done in a lazy fashion. If there's no need for an activated fence the
interrupt will not be enabled.
The fence api does provide a synchronous wait function, but this causes a stall
of whomever waits on it.
Which is perfectly fine. What actually is the use case of not stalling a
process who wants to wait for something?
Does radeon call ttm_bo_wait on all bo's before doing a command submission? No?
Why should other drivers do that..
Sure it does if hardware synchronization isn't supported.
When I was testing this with intel I used the fence callback to poke a register
in i915, this allowed it to not block until it hits the wait op in the command
stream, and even then only if the callback was not called first.
It's documented that the callbacks can be called from any context and will be
called with irqs disabled, so nothing scary should be done. The kernel provides
enough debug mechanisms to find any violators.
PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
No thanks, we even abandoned that concept internal in the driver. Please use
the blocking wait functions instead.
No, this just stalls all gpu's that share a bo.
The idea is to provide a standardized api so bo's can be synchronized without
stalling. The first step to this is ww_mutex.
If this lock is shared between multiple gpu's the same object can be reserved
between multiple devices without causing
a deadlock with circular dependencies. With some small patches it's possible to
do this already between multiple drivers
that use ttm. ttm_bo_reserve, ttm_bo_unreserve and all the other code dealing
with ttm reservations have been converted
to use ww_mutex locking.
Fencing is the next step. When all buffers are locked a callback should be
added to any previous fence, and a single new fence
signaling completion of the command submission should be placed on all locked
objects. Because the common path is that no
objects are shared, the callback and FIFO stalling will only be needed for
dma-bufs. When all callbacks have fired the FIFO can be
unblocked. This prevents having to sync the gpu to the cpu. If a bo is
submitted to 1 gpu, and then immediately to another it will not
stall unless needed. For example in a optimus configuration an application
could copy a rendered frame from VRAM to a shared
dma-buf (xorg's buffer), then have Xorg copying it again (on intel's gpu) from
the dma-buf to a framebuffer .
Yeah, that's the same concept we used to have for multiple rings, to
avoid stalling if a buffer is currently used in a different part of the
GPU than the current command submission wants it to. After allot of
internal discussion we came to the conclusion that it just doesn't worth
the effort.
Have you thought over all the consequences that
[PULL] drm-intel-next
Hi Dave, New pile of stuff for -next: - Cleanup of the old crtc helper callbacks, all encoders are now converted to the i915 modeset infrastructure. - Massive amount of wm patches from Ville for ilk, snb, ivb, hsw, this is prep work to eventually get things going for nuclear pageflips where we need to adjust watermarks on the fly. - More vm/vma patches from Ben. This refactoring isn't yet fully rolled out, we miss the execbuf conversion and some of the low-level bind/unbind support code. - Convert our hdmi infoframe code to use the new common helper functions (Damien). This contains some bugfixes for the common infoframe helpers. - Some cruft removal from Damien. - Various smaller bits&pieces all over, as usual. Cheers, Daniel The following changes since commit cd234b0bfd5ab012e42274b24aae420fa1823d58: drm/i915: Do not dereference NULL crtc or fb until after checking (2013-08-04 21:13:43 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-08-09 for you to fetch changes up to 5c536613d8ebda3da0448550d0a997651a6048e2: drm/i915: Fix FB WM for HSW (2013-08-09 20:27:43 +0200) Ben Widawsky (22): drm/i915/hsw: Change default LLC age to 3 drm/i915: Create an init vm drm/i915: Rework drop caches for checkpatch drm/i915: Make proper functions for VMs drm/i915: Use bound list for inactive shrink drm/i915: Add VM to pin drm/i915: Use ggtt_vm to save some typing drm/i915: Update describe_obj drm/i915: thread address space through execbuf drm/i915: make caching operate on all address spaces drm/i915: BUG_ON put_pages later drm/i915: make reset&hangcheck code VM aware drm/i915: eliminate dead domain clearing on reset drm/i915: Improve VMA comments drm/i915: Rework __i915_gem_shrink drm/i915: plumb VM into bind/unbind code drm/i915: Use new bind/unbind in eviction code drm/i915: turn bound_ggtt checks to bound_any drm/i915: Fix up map and fenceable for VMA drm/i915: mm_list is per VMA drm/i915: Update error capture for VMs drm/i915: Add vma to list at creation Chris Wilson (7): drm/i915: Squelch repeated reasoning for why FBC cannot be activated drm/i915: Use the same pte_encoding for ppgtt as for gtt drm/i915: Tidy the macro casting by using an inline function drm/i915: Acquire dpio_lock for VLV sideband programming in DP/HDMI drm/i915: Rename I915_CACHE_MLC_LLC to L3_LLC for Ivybridge drm/i915: Export intel_framebuffer_fini drm/i915: List objects allocated from stolen memory in debugfs Damien Lespiau (19): video/hdmi: Replace the payload length by their defines video/hdmi: Introduce a generic hdmi_infoframe union video/hdmi: Add a macro to return the size of a full infoframe video/hmdi: Clear the whole incoming buffer, not just the infoframe size drm: Don't generate invalid AVI infoframes for CEA modes drm/i915/hdmi: Change the write_infoframe vfunc to take a buffer and a type drm/i915/hdmi: Port the infoframe code to the common hdmi helpers drm/i915/sdvo: Port the infoframe code to the shared infrastructure drm/i915: Remove the now obsolete infoframe definitions drm: Handle the DBLCLK flag in the common infoframe helper drm: Set aspect ratio fields in the AVI infoframe even for non CEA modes drm/i915/hmdi: Rename set_infoframe() to write_infoframe() drm/i915: Remove stale prototypes drm/i915: Remove i915_gem_object_check_coherency() drm/i915: Fix #endif comment drm/i915: Make i915_hangcheck_elapsed() static drm/i915: Make intel_encoder_dpms() static drm/i915: Remove intel_modeset_disable() drm/i915: Make intel_set_mode() static Dan Carpenter (2): drm/i915: unbreak i915_gem_object_ggtt_unbind() drm/i915: fix a limit check in hsw_compute_wm_results() Daniel Vetter (13): drm/i915/dvo: use intel_encoder to the upcast macro drm/i915/dvo: switch ->mode_fixup to ->compute_config drm/i915: rip out legacy encoder->mode_fixup logic drm/i915/dvo: use native encoder ->mode_set callback drm/i915/sdvo: use intel_encoder for upcast helper drm/i915/tv: Use native encoder->mode_set callback drm/i915/crt: use native encoder->mode_set callback drm/i915/hdmi: use native encoder mode_set callback drm/i915/dp: use native encoder ->mode_set callback drm/i915/lvds: use the native encoder ->mode_set callback drm/i915/ddi: use the native encoder ->mode_set callback drm/i915: rip out legacy encoder->mode_set callback drm/i915: clean up crtc timings computation Imre Deak (1): drm/i915: make user mode sync polarity setting explicit Jani Nikula (3): drm/i915: rearrange vlv dp enable and pre_enable cal
Re: A gentle scrub
On Mon, Aug 19, 2013 at 7:53 PM, Damien Lespiau wrote: > A small pass on drm headers to remove some stale prototypes/functions/defines > and to make static a few functions. For the series: Reviewed-by: Alex Deucher > > drivers/gpu/drm/drm_crtc.c | 38 > +++-- > drivers/gpu/drm/drm_fb_cma_helper.c | 5 ++--- > drivers/gpu/drm/drm_modes.c | 21 > drivers/gpu/drm/drm_platform.c | 7 +++ > include/drm/drmP.h | 8 > include/drm/drm_crtc.h | 17 - > include/drm/drm_fb_cma_helper.h | 1 - > include/drm/drm_pciids.h| 30 - > 8 files changed, 8 insertions(+), 119 deletions(-) > > -- > Damien > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem
https://bugzilla.kernel.org/show_bug.cgi?id=60674 --- Comment #15 from Alex Deucher --- (In reply to Dave from comment #14) > (In reply to Michel Dänzer from comment #13) > > Michel you could well be 100% right. While the symptoms may be similar, your issue is completely different, and not kernel related. Please open a new bug on https://bugs.freedesktop.org (for the ddx: product xorg, component Driver/Radeon). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/radeon: rework to new fence interface
Op 20-08-13 11:51, Christian König schreef:
> Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
> [SNIP]
>
>> [SNIP]
>> +/**
>> + * radeon_fence_enable_signaling - enable signalling on fence
>> + * @fence: fence
>> + *
>> + * This function is called with fence_queue lock held, and adds a
>> callback
>> + * to fence_queue that checks if this fence is signaled, and if so it
>> + * signals the fence and removes itself.
>> + */
>> +static bool radeon_fence_enable_signaling(struct fence *f)
>> +{
>> +struct radeon_fence *fence = to_radeon_fence(f);
>> +
>> +if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
>> fence->seq ||
>> +!fence->rdev->ddev->irq_enabled)
>> +return false;
>> +
> Do I get that right that you rely on IRQs to be enabled and working here?
> Cause that would be a quite bad idea from the conceptual side.
For cross-device synchronization it would be nice to have working irqs, it
allows signalling fences faster,
and it allows for callbacks on completion to be called. For internal usage
it's no more required than it was before.
>>> That's a big NAK.
>>>
>>> The fence processing is actually very fine tuned to avoid IRQs and as far
>>> as I can see you just leave them enabled by decrementing the atomic from
>>> IRQ context. Additional to that we need allot of special handling in case
>>> of a hardware lockup here, which isn't done if you abuse the fence
>>> interface like this.
>> I think it's not needed to leave the irq enabled, it's a leftover from when
>> I was debugging the mac and no interrupt occurred at all.
>>
>>> Also your approach of leaking the IRQ context outside of the driver is a
>>> very bad idea from the conceptual side. Please don't modify the fence
>>> interface at all and instead use the wait functions already exposed by
>>> radeon_fence.c. If you need some kind of signaling mechanism then wait
>>> inside a workqueue instead.
>> The fence takes up the role of a single shot workqueue here. Manually
>> resetting the counter and calling wake_up_all would end up waking all active
>> fences, there's no special handling needed inside radeon for this.
>
> Yeah that's actually the point here, you NEED to activate ALL fences,
> otherwise the fence handling inside the driver won't work.
It's done in a lazy fashion. If there's no need for an activated fence the
interrupt will not be enabled.
>> The fence api does provide a synchronous wait function, but this causes a
>> stall of whomever waits on it.
>
> Which is perfectly fine. What actually is the use case of not stalling a
> process who wants to wait for something?
Does radeon call ttm_bo_wait on all bo's before doing a command submission? No?
Why should other drivers do that..
>> When I was testing this with intel I used the fence callback to poke a
>> register in i915, this allowed it to not block until it hits the wait op in
>> the command stream, and even then only if the callback was not called first.
>>
>> It's documented that the callbacks can be called from any context and will
>> be called with irqs disabled, so nothing scary should be done. The kernel
>> provides enough debug mechanisms to find any violators.
>> PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
>
> No thanks, we even abandoned that concept internal in the driver. Please use
> the blocking wait functions instead.
No, this just stalls all gpu's that share a bo.
The idea is to provide a standardized api so bo's can be synchronized without
stalling. The first step to this is ww_mutex.
If this lock is shared between multiple gpu's the same object can be reserved
between multiple devices without causing
a deadlock with circular dependencies. With some small patches it's possible to
do this already between multiple drivers
that use ttm. ttm_bo_reserve, ttm_bo_unreserve and all the other code dealing
with ttm reservations have been converted
to use ww_mutex locking.
Fencing is the next step. When all buffers are locked a callback should be
added to any previous fence, and a single new fence
signaling completion of the command submission should be placed on all locked
objects. Because the common path is that no
objects are shared, the callback and FIFO stalling will only be needed for
dma-bufs. When all callbacks have fired the FIFO can be
unblocked. This prevents having to sync the gpu to the cpu. If a bo is
submitted to 1 gpu, and then immediately to another it will not
stall unless needed. For example in a optimus configuration an application
could copy a rendered frame from VRAM to a shared
dma-buf (xorg's buffer), then have Xorg copying it again (on intel's gpu) from
the dma-buf to a framebuffer .
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher --- Possibly related to bug 60639. Can you try the patch on that bug? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/i915: add fast boot support for Haswell
On Tue, Aug 20, 2013 at 3:33 AM, Furquan Shaikh wrote:
> Enables getting correct mode clock when reading pipe config
> This patch has been tested successfully on top of drm-intel-nightly tree
>
> Signed-off-by: Furquan Shaikh
This is missing a hunk to enable the pipe_config consistency checks:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7a40427..e8b73ac 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8416,13 +8416,11 @@ intel_pipe_config_compare(struct drm_device *dev,
#undef PIPE_CONF_CHECK_FLAGS
#undef PIPE_CONF_QUIRK
- if (!IS_HASWELL(dev)) {
- if (!intel_fuzzy_clock_check(current_config, pipe_config)) {
- DRM_ERROR("mismatch in clock (expected %d, found %d)\n",
- current_config->adjusted_mode.clock,
- pipe_config->adjusted_mode.clock);
- return false;
- }
+ if (!intel_fuzzy_clock_check(current_config, pipe_config)) {
+ DRM_ERROR("mismatch in clock (expected %d, found %d)\n",
+ current_config->adjusted_mode.clock,
+ pipe_config->adjusted_mode.clock);
+ return false;
}
return true;
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6
> drivers/gpu/drm/i915/intel_ddi.c | 70
>
> drivers/gpu/drm/i915/intel_display.c | 1 +
> 3 files changed, 77 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2b96d6b..9511129 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4970,6 +4970,7 @@
> #define SPLL_PLL_NON_SSC (2<<28)
> #define SPLL_PLL_FREQ_810MHz (0<<26)
> #define SPLL_PLL_FREQ_1350MHz (1<<26)
> +#define SPLL_PLL_FREQ_MASK (3<<26)
>
> /* WRPLL */
> #define WRPLL_CTL1 0x46040
> @@ -4983,6 +4984,10 @@
> #define WRPLL_DIVIDER_POST(x) ((x)<<8)
> #define WRPLL_DIVIDER_FEEDBACK(x) ((x)<<16)
>
> +#define WRPLL_DIVIDER_REFERENCE_BITS(reg)(reg & 0xff)
> +#define WRPLL_DIVIDER_POST_BITS(reg) ((reg >> 8) & 0x3f)
> +#define WRPLL_DIVIDER_FEEDBACK_BITS(reg) ((reg >> 16) & 0xff)
> +
> /* Port clock selection */
> #define PORT_CLK_SEL_A 0x46100
> #define PORT_CLK_SEL_B 0x46104
> @@ -4994,6 +4999,7 @@
> #define PORT_CLK_SEL_WRPLL1 (4<<29)
> #define PORT_CLK_SEL_WRPLL2 (5<<29)
> #define PORT_CLK_SEL_NONE (7<<29)
> +#define PORT_CLK_SEL_MASK (7<<29)
>
> /* Transcoder clock selection */
> #define TRANS_CLK_SEL_A0x46140
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b8c096b..a24a375 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1246,6 +1246,74 @@ static void intel_ddi_hot_plug(struct intel_encoder
> *intel_encoder)
> intel_dp_check_link_status(intel_dp);
> }
>
> +static void intel_ddi_get_clock(struct intel_encoder *encoder,
> + struct intel_crtc_config *pipe_config)
> +{
> + struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> + int port = intel_ddi_get_encoder_port(encoder);
> + u32 temp = I915_READ(PORT_CLK_SEL(port)) & PORT_CLK_SEL_MASK;
> + u8 link_bw;
> +
> + if ((temp == PORT_CLK_SEL_LCPLL_810) ||
> + (temp == PORT_CLK_SEL_LCPLL_1350) ||
> + (temp == PORT_CLK_SEL_LCPLL_2700)) {
> +
> + switch (temp) {
> + case PORT_CLK_SEL_LCPLL_810:
> + link_bw = DP_LINK_BW_1_62;
> + break;
> + case PORT_CLK_SEL_LCPLL_1350:
> + link_bw = DP_LINK_BW_2_7;
> + break;
> + case PORT_CLK_SEL_LCPLL_2700:
> + link_bw = DP_LINK_BW_5_4;
> + break;
> + }
> + pipe_config->port_clock =
> drm_dp_bw_code_to_link_rate(link_bw);
> + } else if ((temp == PORT_CLK_SEL_WRPLL1) ||
> + (temp == PORT_CLK_SEL_WRPLL2)) {
> + uint64_t p, n2, r2;
> + u32 val, reg;
> + uint64_t freq2k;
> +
> + switch (temp) {
> + case PORT_CLK_SEL_WRPLL1:
> + reg = WRPLL_CTL1;
> + break;
> + case PORT_CLK_SEL_WRPLL2:
> + reg = WRPLL_CTL2;
> + break;
> + }
> + val = I915_READ(reg);
> + r2 = WRPLL_DIVIDER_REFERENCE_BITS(val);
> + p = WRPLL_DIVIDER_POST_BITS(val);
> + n2 = WRPLL_DIVIDER_FEEDBACK
[PATCH] drm: add MIPI DSI encoder and connector types
From: Shobhit Kumar
Signed-off-by: Shobhit Kumar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc.c |2 ++
include/uapi/drm/drm_mode.h |2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a691764..dc279f4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -209,6 +209,7 @@ static struct drm_conn_prop_enum_list
drm_connector_enum_list[] =
{ DRM_MODE_CONNECTOR_TV, "TV" },
{ DRM_MODE_CONNECTOR_eDP, "eDP" },
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
+ { DRM_MODE_CONNECTOR_DSI, "DSI" },
};
static const struct drm_prop_enum_list drm_encoder_enum_list[] =
@@ -218,6 +219,7 @@ static const struct drm_prop_enum_list
drm_encoder_enum_list[] =
{ DRM_MODE_ENCODER_LVDS, "LVDS" },
{ DRM_MODE_ENCODER_TVDAC, "TV" },
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
+ { DRM_MODE_ENCODER_DSI, "DSI" },
};
void drm_connector_ida_init(void)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 53db7ce..589114e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -165,6 +165,7 @@ struct drm_mode_get_plane_res {
#define DRM_MODE_ENCODER_LVDS 3
#define DRM_MODE_ENCODER_TVDAC 4
#define DRM_MODE_ENCODER_VIRTUAL 5
+#define DRM_MODE_ENCODER_DSI 6
struct drm_mode_get_encoder {
__u32 encoder_id;
@@ -203,6 +204,7 @@ struct drm_mode_get_encoder {
#define DRM_MODE_CONNECTOR_TV 13
#define DRM_MODE_CONNECTOR_eDP 14
#define DRM_MODE_CONNECTOR_VIRTUAL 15
+#define DRM_MODE_CONNECTOR_DSI 16
struct drm_mode_get_connector {
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] refactor some ldb related clocks
On 08/20/2013 05:43 PM, Philipp Zabel wrote: > Am Dienstag, den 20.08.2013, 16:38 +0800 schrieb Liu Ying: >> The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register >> of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5 >> drivider or a 1/7 divider. The common clock framework cannot >> deal with the two dividers directly even with the divider table >> which only supports integral dividers. So, the idea is to take >> the 1/3.5 and 1/7 dividers as separate fixed factor dividers and >> introduce a new multiplexer clock to be derived from the them. >> Then, the ldb display clock trees can be setup correctly. >> This series contains the necessary clock driver changes, dts code >> changes and imx-drm/ldb driver changes to fullfill the task. > > I don't see how this improves the situation. Does this solve any real > problem? > I don't see any functional problem without this series. But, it may correct ldb_di[n] clock frequency returned from clk_get_rate() when using 1/7 divider. Furthermore, since this series makes the ldb related clocks from pll to ldb_di[0/1] have the CLK_SET_RATE_PARENT flag set, the imx-drm/ldb driver may set the clocks' frequency more flexibly, i.e., only calling clk_set_rate() for ldb_di[n] clock would be an alternative. > While I admit to having introduced the combination of 1/3.5 fixed > divider and configurable 1/1,1/2 divder clocks to describe this > fractional divider for the reasons you state, I think the correct > solution would be to improve the table divider to support fractional > values and get rid of the virtual ldb_di_div_3_5 clocks, not > introduce more virtual clocks. Yes, it's good to support fractional values for the table divider(not sure if there is any plan for this). I see there is something similar in 'include/linux/sh_clk.h'. > > regards > Philipp > > Regards, Liu Ying ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/radeon: rework to new fence interface
Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
[SNIP]
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a callback
+ * to fence_queue that checks if this fence is signaled, and if so it
+ * signals the fence and removes itself.
+ */
+static bool radeon_fence_enable_signaling(struct fence *f)
+{
+struct radeon_fence *fence = to_radeon_fence(f);
+
+if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
fence->seq ||
+!fence->rdev->ddev->irq_enabled)
+return false;
+
Do I get that right that you rely on IRQs to be enabled and working here? Cause
that would be a quite bad idea from the conceptual side.
For cross-device synchronization it would be nice to have working irqs, it
allows signalling fences faster,
and it allows for callbacks on completion to be called. For internal usage it's
no more required than it was before.
That's a big NAK.
The fence processing is actually very fine tuned to avoid IRQs and as far as I
can see you just leave them enabled by decrementing the atomic from IRQ
context. Additional to that we need allot of special handling in case of a
hardware lockup here, which isn't done if you abuse the fence interface like
this.
I think it's not needed to leave the irq enabled, it's a leftover from when I
was debugging the mac and no interrupt occurred at all.
Also your approach of leaking the IRQ context outside of the driver is a very
bad idea from the conceptual side. Please don't modify the fence interface at
all and instead use the wait functions already exposed by radeon_fence.c. If
you need some kind of signaling mechanism then wait inside a workqueue instead.
The fence takes up the role of a single shot workqueue here. Manually resetting
the counter and calling wake_up_all would end up waking all active fences,
there's no special handling needed inside radeon for this.
Yeah that's actually the point here, you NEED to activate ALL fences,
otherwise the fence handling inside the driver won't work.
The fence api does provide a synchronous wait function, but this causes a stall
of whomever waits on it.
Which is perfectly fine. What actually is the use case of not stalling a
process who wants to wait for something?
When I was testing this with intel I used the fence callback to poke a register
in i915, this allowed it to not block until it hits the wait op in the command
stream, and even then only if the callback was not called first.
It's documented that the callbacks can be called from any context and will be
called with irqs disabled, so nothing scary should be done. The kernel provides
enough debug mechanisms to find any violators.
PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
No thanks, we even abandoned that concept internal in the driver. Please
use the blocking wait functions instead.
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
