Re: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On 08/23/2012 07:44 PM, Ricardo Neri wrote: > On 08/22/2012 02:55 AM, Takashi Iwai wrote: >> At Tue, 21 Aug 2012 19:58:02 -0500, >> Ricardo Neri wrote: ... >>> Maybe the lack of audio support in drm is because the audio users should >>> not talk to drm directly but to a lower level component (omapdrm, >>> omapdss?). However, today there exists video technology supports audio >>> as well, such as DisplayPort or HDMI. Could it make more sense now to >>> provide audio support? >> >> The reason is that the audio and video handling are already separated >> in the hardware level, at least, for desktop graphics. > > Separated in what sense? Do they have separate register banks in For NVIDIA desktop GPUs, this is certainly true, and I think so for any Intel Azalia/HDA controller. The separate register banks are in different PCI functions on the chip. The Intel Azalia/HDA spec also architects specific ways that the audio and video parts interact (i.e. ELD representation of EDID data, unsolicited response messages when the video state changes, etc.) Oh, I see Takashi mentioned this below. > independent power domains? Most likely yes. > Can audio an video work with complete > independence. What happens if someone decides to power off video. Is the > audio able to continue if required? I believe audio DMA isn't affect by the video state, but I'm not 100% sure of that. >> The audio infoframe is passed via ELD to the audio controller part >> upon plug/unplugging via HD-audio unsolicited event, and the audio >> driver sets up the stuff according to the given ELD. Thus no extra >> interface between drm and ALSA was required in the kernel API level, >> so far. > > I see that the unsolicited event is used only to parse the EDID, > correct? It also notifies about the jack status. Hence, if there the > cable is disconnected the application will know and act accordingly. Is > this understanding correct? The kernel will know, and then passes the information on to user-space. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
Hi Takashi, On 08/22/2012 02:55 AM, Takashi Iwai wrote: At Tue, 21 Aug 2012 19:58:02 -0500, Ricardo Neri wrote: On 08/21/2012 07:39 AM, Clark, Rob wrote: On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen wrote: On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: Hello! I have been working on prototypes for the ASoC OMAP HDMI audio driver to propagate events from the HDMI output (e.g., display getting enabled/disabled/suspended). This for the users of the driver to react to such events. For instance, if the display is disabled or disconected, audio could be stopped, rerouted or whatever other decision the user makes. This is needed because, if, for instance, the HDMI IP goes off, audio will stall and the audio users will only see a "playback write error (DMA or IRQ trouble?)" In my prototypes I have used snd_soc_jack for this purpose and I have some questions: *I see snd_soc_jack is used mostly for headsets and microphones with actual external mechanical connections. Strictly, in my case I propagate events originated by the OMAP display driver (changes in the power state), and not from external events. Some of these events are generated from an actual HDMI cable connection/disconnection, though. *Maybe the event should be propagated by omapdss/omapdrm/drm and the entity in charge of the audio policy should listen those events instead. *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it ie · · Il y a 12 minutes · s feasible for an audio driver to report events from an AV output. I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case? How does DRM handle audio? I made a quick grep, but I see the drm drivers only enabling the audio in the HW, nothing else. I confess to not knowing too much about audio/alsa, but what does audio driver need from hdmi? Just hotplug events? At least for the case of the ASoC HDMI audio driver (but hopefully for other audio drivers as well), it needs to detect whether an HDMI output is available, if the display's current configuration supports audio (e.g., a 1080p display configured as VGA should be reported as not supporting audio). It also needs interfaces to configure/prepare/start/stop audio. Also, of course, needs to know if the display is off/on/suspended and when transitions occur. For OMAP, omapdss provide an interface for this functionality for ALSA or any other interested user. From a quick look, it seems most of what the existing drm drivers are doing is detecting if the display supports audio, and then turning on/off the hw.. (and some infoframe stuff in some cases). Yes, it seems to me that every driver makes its own audio implementation, mainly focused on configuration. I could not find any audio common interface so that users like ALSA can take advantage of. Also, I could not see any ALSA driver using functionality provided by a drm driver. Maybe the lack of audio support in drm is because the audio users should not talk to drm directly but to a lower level component (omapdrm, omapdss?). However, today there exists video technology supports audio as well, such as DisplayPort or HDMI. Could it make more sense now to provide audio support? The reason is that the audio and video handling are already separated in the hardware level, at least, for desktop graphics. Separated in what sense? Do they have separate register banks in independent power domains? Can audio an video work with complete independence. What happens if someone decides to power off video. Is the audio able to continue if required? The audio infoframe is passed via ELD to the audio controller part upon plug/unplugging via HD-audio unsolicited event, and the audio driver sets up the stuff according to the given ELD. Thus no extra interface between drm and ALSA was required in the kernel API level, so far. I see that the unsolicited event is used only to parse the EDID, correct? It also notifies about the jack status. Hence, if there the cable is disconnected the application will know and act accordingly. Is this understanding correct? Also, I see that hda_pcm_ops does not have a trigger or start/stop functions, how does it know when to start/stop audio. Maybe with azx_pcm_trigger? Sorry, I am not expert in HD-audio :) Ricardo Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: mgag200 hang on boot
On Thu, Aug 23, 2012 at 4:22 PM, Dave Airlie wrote: > On Fri, Aug 24, 2012 at 7:51 AM, Andy Lutomirski wrote: >> mgag200 hangs like this on startup, on a Dell PowerEge 12g box. The >> serial console says: > > You can apply this > > https://patchwork.kernel.org/patch/1298651/ Works for me. Thanks. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
mgag200 hang on boot
mgag200 hangs like this on startup, on a Dell PowerEdge 12g box. The serial console says: [4.399184] [drm] Initialized drm 1.1.0 20060810 [4.444054] [TTM] Zone kernel: Available graphics memory: 16452270 kiB [4.459610] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [4.466893] [TTM] Initializing pool allocator [4.471768] [TTM] Initializing DMA pool allocator [4.543626] fbcon: mgadrmfb (fb0) is primary device udevadm settle - timeout of 120 seconds reached, the event queue contains: /sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0 (1431) /sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0/drm/controlD64 (2238) /sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0/drm/card0 (2239) /sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0/i2c-0 (2245) /sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0/graphics/fb0 (2249) This is 3.5.0, but the bug is not fixed in 3.5.2. When the hang happened, the actual vga output declared that it had no signal, according to the iDRAC remote management. The hang is: [ 579.919114] insmod R running task0 8873 8872 0x [ 579.919117] 8807af15b2b8 814ff9d7 0001 a01461a0 [ 579.919123] 880809665a80 8807af15bfd8 8807af15bfd8 8807af15bfd8 [ 579.919129] 8808028116a0 8808028116a0 1000 8807af15bfd8 [ 579.919135] Call Trace: [ 579.919136] [] ? __schedule+0x3b7/0x7c0 [ 579.919140] [] preempt_schedule_irq+0x45/0x60 [ 579.919144] [] retint_kernel+0x26/0x30 [ 579.919149] [] ? mga_crtc_mode_set+0x1e38/0x1ee0 [mgag200] [ 579.919158] [] ? mga_crtc_mode_set+0xacc/0x1ee0 [mgag200] [ 579.919165] [] ? idr_get_new_above+0x10/0x40 [ 579.919177] [] drm_crtc_helper_set_mode+0x36e/0x4f0 [drm_kms_helper] [ 579.919189] [] drm_crtc_helper_set_config+0x84f/0xb00 [drm_kms_helper] [ 579.919195] [] ? preempt_schedule_irq+0x45/0x60 [ 579.919200] [] drm_fb_helper_set_par+0x78/0xf0 [drm_kms_helper] [ 579.919206] [] fbcon_init+0x52c/0x5b0 [ 579.919211] [] visual_init+0xbc/0x120 [ 579.919215] [] bind_con_driver+0x19c/0x330 [ 579.919220] [] take_over_console+0x61/0x70 [ 579.919224] [] fbcon_takeover+0x5b/0xb0 [ 579.919227] [] fbcon_event_notify+0x76a/0x870 [ 579.919232] [] notifier_call_chain+0x4d/0x70 [ 579.919236] [] __blocking_notifier_call_chain+0x58/0x80 [ 579.919240] [] blocking_notifier_call_chain+0x16/0x20 [ 579.919244] [] fb_notifier_call_chain+0x1b/0x20 [ 579.919250] [] register_framebuffer+0x1ba/0x2f0 [ 579.919256] [] drm_fb_helper_single_fb_probe+0x1e3/0x300 [drm_kms_helper] [ 579.919262] [] drm_fb_helper_initial_config+0x1db/0x250 [drm_kms_helper] [ 579.919268] [] ? __kmalloc+0x16b/0x1b0 [ 579.919272] [] ? drm_fb_helper_init+0x118/0x1f0 [drm_kms_helper] [ 579.919278] [] ? kmem_cache_alloc_trace+0x143/0x170 [ 579.919282] [] mgag200_fbdev_init+0x84/0xb0 [mgag200] [ 579.919290] [] mgag200_modeset_init+0x1b7/0x230 [mgag200] [ 579.919297] [] mgag200_driver_load+0x3e1/0x4b0 [mgag200] [ 579.919305] [] drm_get_pci_dev+0x191/0x2b0 [drm] [ 579.919324] [] mga_pci_probe+0xac/0xb4 [mgag200] [ 579.919332] [] local_pci_probe+0x5c/0xd0 [ 579.919339] [] pci_device_probe+0x109/0x130 [ 579.919345] [] driver_probe_device+0x7e/0x220 [ 579.919353] [] __driver_attach+0xab/0xb0 [ 579.919358] [] ? driver_probe_device+0x220/0x220 [ 579.919363] [] bus_for_each_dev+0x56/0x90 [ 579.919369] [] driver_attach+0x1e/0x20 [ 579.919373] [] bus_add_driver+0x1a0/0x270 [ 579.919379] [] driver_register+0x76/0x130 [ 579.919382] [] __pci_register_driver+0x56/0xd0 [ 579.919387] [] ? notifier_call_chain+0x4d/0x70 [ 579.919393] [] drm_pci_init+0x11a/0x130 [drm] [ 579.919406] [] ? 0xa00d7fff [ 579.919413] [] mgag200_init+0x3c/0x1000 [mgag200] [ 579.919419] [] do_one_initcall+0x3f/0x170 [ 579.919424] [] sys_init_module+0xbe/0x230 [ 579.919430] [] system_call_fastpath+0x16/0x1b' insmod is taking 100% cpu. Is there anything I can do to debug this? I don't really need mgag200, since I do pretty much everything via serial console. --Andy -- Andy Lutomirski AMA Capital Management, LLC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
At Thu, 23 Aug 2012 20:44:32 -0500, Ricardo Neri wrote: > > Hi Takashi, > > On 08/22/2012 02:55 AM, Takashi Iwai wrote: > > At Tue, 21 Aug 2012 19:58:02 -0500, > > Ricardo Neri wrote: > >> > >> > >> > >> On 08/21/2012 07:39 AM, Clark, Rob wrote: > >>> On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen > >>> wrote: > On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: > > Hello! > > > > I have been working on prototypes for the ASoC OMAP HDMI audio driver to > > propagate events from the HDMI output (e.g., display getting > > enabled/disabled/suspended). This for the users of the driver to react > > to such events. For instance, if the display is disabled or disconected, > > audio could be stopped, rerouted or whatever other decision the user > > makes. This is needed because, if, for instance, the HDMI IP goes off, > > audio will stall and the audio users will only see a "playback write > > error (DMA or IRQ trouble?)" > > > > In my prototypes I have used snd_soc_jack for this purpose and I have > > some questions: > > > > *I see snd_soc_jack is used mostly for headsets and microphones with > > actual external mechanical connections. Strictly, in my case I propagate > > events originated by the OMAP display driver (changes in the power > > state), and not from external events. Some of these events are generated > > from an actual HDMI cable connection/disconnection, though. > > > > *Maybe the event should be propagated by omapdss/omapdrm/drm and the > > entity in charge of the audio policy should listen those events instead. > > > > *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it ie · · > > Il y a 12 minutes · > > s > > feasible for an audio driver to report events from an AV output. > > > > I was wondering about how much sense does it make to you guys use a > > snd_soc_jack in this case? > > How does DRM handle audio? I made a quick grep, but I see the drm > drivers only enabling the audio in the HW, nothing else. > >>> > >>> I confess to not knowing too much about audio/alsa, but what does > >>> audio driver need from hdmi? Just hotplug events? > >> > >> At least for the case of the ASoC HDMI audio driver (but hopefully for > >> other audio drivers as well), it needs to detect whether an HDMI output > >> is available, if the display's current configuration supports audio > >> (e.g., a 1080p display configured as VGA should be reported as not > >> supporting audio). It also needs interfaces to > >> configure/prepare/start/stop audio. Also, of course, needs to know if > >> the display is off/on/suspended and when transitions occur. For OMAP, > >> omapdss provide an interface for this functionality for ALSA or any > >> other interested user. > >>> > >>> From a quick look, it seems most of what the existing drm drivers are > >>> doing is detecting if the display supports audio, and then turning > >>> on/off the hw.. (and some infoframe stuff in some cases). > >> > >> Yes, it seems to me that every driver makes its own audio > >> implementation, mainly focused on configuration. I could not find any > >> audio common interface so that users like ALSA can take advantage of. > >> > >> Also, I could not see any ALSA driver using functionality provided by a > >> drm driver. > >> > >> Maybe the lack of audio support in drm is because the audio users should > >> not talk to drm directly but to a lower level component (omapdrm, > >> omapdss?). However, today there exists video technology supports audio > >> as well, such as DisplayPort or HDMI. Could it make more sense now to > >> provide audio support? > > > > The reason is that the audio and video handling are already separated > > in the hardware level, at least, for desktop graphics. > > Separated in what sense? Do they have separate register banks in > independent power domains? Can audio an video work with complete > independence. What happens if someone decides to power off video. Is the > audio able to continue if required? As Stephen already pointed, the functionality is independent in the PCI hardware level. The audio part even accepts and DMA is working without connection to the actual output. > > The audio infoframe is passed via ELD to the audio controller part > > upon plug/unplugging via HD-audio unsolicited event, and the audio > > driver sets up the stuff according to the given ELD. Thus no extra > > interface between drm and ALSA was required in the kernel API level, > > so far. > > I see that the unsolicited event is used only to parse the EDID, > correct? It also notifies about the jack status. Hence, if there the > cable is disconnected the application will know and act accordingly. Is > this understanding correct? Correct. > Also, I see that hda_pcm_ops does not have a trigger or start/stop > functions, how does it know when to start/stop audio. Maybe with > azx_pcm_tri
[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 --- Comment #18 from Bryan Quigley 2012-08-24 04:32:48 UTC --- Created attachment 66047 --> https://bugs.freedesktop.org/attachment.cgi?id=66047 3 outputs of syslog: before the patch, after, and after really bad -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 --- Comment #17 from Bryan Quigley 2012-08-24 04:31:57 UTC --- The patch doesn't seem to work. It may have made the crash more likely to bring the system down, but I'd have to do more testing to confirm that. Attaching 3 syslog results in 1 file containing: Before the patch After the patch After the patch - broke so much it needed a restart -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] drm/prime: fixup the dma buf export cache locking
On Mon, Jul 23, 2012 at 7:26 PM, Daniel Vetter wrote: > Well, actually add some, because currently there's exactly none: > - in handle_to_fd we only take the file_priv's prime lock, but the > underlying gem object we're exporting isn't per-file. > - in each driver's dma_buf->release callback we don't grab any locks > at all. Finally got to this patch and applied it to my test box and it explodes in the following start X, bind udl as an output slave, set a mode on the udl, then kill the X server, I get an oops on i915/radeon/nouveau, like [ 8046.363596] general protection fault: [#1] SMP [ 8046.364012] Modules linked in: fuse lockd rfcomm sunrpc bnep tpm_bios ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ ipv4 nf_defrag_ipv4 xt_state nf_conntrack snd_hda_codec_conexant arc4 iwldvm mac80211 coretemp kvm_intel snd_hda_intel snd_hda_codec kvm btusb snd_hwdep bluet ooth iwlwifi i915 snd_seq snd_seq_device microcode snd_pcm cfg80211 snd_page_alloc i2c_i801 lpc_ich e1000e mfd_core snd_timer wmi thinkpad_acpi snd soundcore rfkill video uinput sdhci_pci sdhci udl syscopyarea sysfillrect sysimgblt firewire_ohci mmc_core drm_usb firewire_core crc_itu_t yenta_socket radeon i2c_algo_ bit drm_kms_helper ttm drm i2c_core [ 8046.364012] CPU 0 [ 8046.364012] Pid: 6947, comm: Xorg Tainted: GW3.6.0-rc3+ #7 LENOVO 406334M/406334M [ 8046.364012] RIP: 0010:[] [] i915_gem_unmap_dma_buf+0x5c/0xb0 [i915] [ 8046.364012] RSP: 0018:88002c22dc28 EFLAGS: 00010296 [ 8046.364012] RAX: 0500 RBX: 880007d5d6d8 RCX: [ 8046.364012] RDX: 0500 RSI: 8800570ca000 RDI: 88005b2ea5a8 [ 8046.364012] RBP: 88002c22dc68 R08: R09: [ 8046.364012] R10: R11: 0001 R12: 88005b2ea5a8 [ 8046.364012] R13: R14: 6b6b6b6b6b6b6b6b R15: 8800570ca000 [ 8046.364012] FS: 7f79955759c0() GS:880078c0() knlGS: [ 8046.364012] CS: 0010 DS: ES: CR0: 80050033 [ 8046.364012] CR2: 0031808bab90 CR3: 01c0b000 CR4: 07f0 [ 8046.364012] DR0: DR1: DR2: [ 8046.364012] DR3: DR6: 0ff0 DR7: 0400 [ 8046.364012] Process Xorg (pid: 6947, threadinfo 88002c22c000, task 88005d68) [ 8046.364012] Stack: [ 8046.364012] 880058d167b0 88000500 88002c22dc48 88005f6f0f50 [ 8046.364012] 88005d9622f8 88005d962290 [ 8046.364012] 88002c22dc78 81409182 88002c22dc98 a002cfeb [ 8046.364012] Call Trace: [ 8046.364012] [] dma_buf_unmap_attachment+0x22/0x40 [ 8046.364012] [] drm_prime_gem_destroy+0x2b/0x50 [drm] [ 8046.364012] [] udl_gem_free_object+0x39/0x70 [udl] [ 8046.364012] [] drm_gem_object_free+0x2a/0x30 [drm] [ 8046.364012] [] drm_gem_object_release_handle+0xa8/0xd0 [drm] [ 8046.364012] [] idr_for_each+0xe5/0x180 [ 8046.364012] [] ? drm_gem_vm_open+0x70/0x70 [drm] [ 8046.364012] [] ? trace_hardirqs_on+0xd/0x10 [ 8046.364012] [] drm_gem_release+0x24/0x40 [drm] [ 8046.364012] [] drm_release+0x55a/0x5f0 [drm] [ 8046.364012] [] __fput+0xfa/0x2d0 [ 8046.364012] [] fput+0xe/0x10 [ 8046.364012] [] task_work_run+0x69/0xa0 [ 8046.364012] [] do_exit+0xa0e/0xb20 [ 8046.364012] [] ? retint_swapgs+0x13/0x1b [ 8046.364012] [] do_group_exit+0x4c/0xc0 which implies some reference count is off or some object is freed in the wrong order. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[XDC 2012] Conference Update #2
We are a little less than one month into XDC 2012 so here's some update: Registration: - So far we have 32 registered participants - which is pretty good. If you plan to come and haven't added yourself to the participants list at http://wiki.x.org/wiki/Events/XDC2012/Attendees, please do so! Presentations: -- Our program list is still quite empty, so if you have something to present, please add yourself to http://wiki.x.org/wiki/Events/XDC2012/Program! Weekend Event: -- As announced we are planning a hiking trip to the Frankonian countryside on Saturday for all those are still there for the weekend. On this trip we will have the opportunity to visit some local brewery beergardens. if you would like to join us for this trip please register yourself at http://wiki.x.org/wiki/Events/XDC2012/Weekend so that we get a rough estimate on how many people to expect. Hotel Reservation: -- The reservation period for which we allocated rooms and negotiated a special price at the Azimut Hotel is over - I've been informed by the hotel that it is completely booked out at this time. You may still try at one of the other hotels listed. All of them are still at walking distance to the venue. There are other hotels in the vicinity - however I have not stayed at any of them. if you have difficulties finding a hotel please contact the organizers. Limited Email Access: - Speaking of contacting the organizers, I will have limited email access for the next two weeks, thus if you have urgent inquiries, please contact Stefan Dirsch for assistance. I've also updated the event Wiki pages accordingly. See you in Nuernberg! Egbert.
[alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On 08/23/2012 07:44 PM, Ricardo Neri wrote: > On 08/22/2012 02:55 AM, Takashi Iwai wrote: >> At Tue, 21 Aug 2012 19:58:02 -0500, >> Ricardo Neri wrote: ... >>> Maybe the lack of audio support in drm is because the audio users should >>> not talk to drm directly but to a lower level component (omapdrm, >>> omapdss?). However, today there exists video technology supports audio >>> as well, such as DisplayPort or HDMI. Could it make more sense now to >>> provide audio support? >> >> The reason is that the audio and video handling are already separated >> in the hardware level, at least, for desktop graphics. > > Separated in what sense? Do they have separate register banks in For NVIDIA desktop GPUs, this is certainly true, and I think so for any Intel Azalia/HDA controller. The separate register banks are in different PCI functions on the chip. The Intel Azalia/HDA spec also architects specific ways that the audio and video parts interact (i.e. ELD representation of EDID data, unsolicited response messages when the video state changes, etc.) Oh, I see Takashi mentioned this below. > independent power domains? Most likely yes. > Can audio an video work with complete > independence. What happens if someone decides to power off video. Is the > audio able to continue if required? I believe audio DMA isn't affect by the video state, but I'm not 100% sure of that. >> The audio infoframe is passed via ELD to the audio controller part >> upon plug/unplugging via HD-audio unsolicited event, and the audio >> driver sets up the stuff according to the given ELD. Thus no extra >> interface between drm and ALSA was required in the kernel API level, >> so far. > > I see that the unsolicited event is used only to parse the EDID, > correct? It also notifies about the jack status. Hence, if there the > cable is disconnected the application will know and act accordingly. Is > this understanding correct? The kernel will know, and then passes the information on to user-space.
[alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
Hi Takashi, On 08/22/2012 02:55 AM, Takashi Iwai wrote: > At Tue, 21 Aug 2012 19:58:02 -0500, > Ricardo Neri wrote: >> >> >> >> On 08/21/2012 07:39 AM, Clark, Rob wrote: >>> On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen >>> wrote: On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: > Hello! > > I have been working on prototypes for the ASoC OMAP HDMI audio driver to > propagate events from the HDMI output (e.g., display getting > enabled/disabled/suspended). This for the users of the driver to react > to such events. For instance, if the display is disabled or disconected, > audio could be stopped, rerouted or whatever other decision the user > makes. This is needed because, if, for instance, the HDMI IP goes off, > audio will stall and the audio users will only see a "playback write > error (DMA or IRQ trouble?)" > > In my prototypes I have used snd_soc_jack for this purpose and I have > some questions: > > *I see snd_soc_jack is used mostly for headsets and microphones with > actual external mechanical connections. Strictly, in my case I propagate > events originated by the OMAP display driver (changes in the power > state), and not from external events. Some of these events are generated > from an actual HDMI cable connection/disconnection, though. > > *Maybe the event should be propagated by omapdss/omapdrm/drm and the > entity in charge of the audio policy should listen those events instead. > > *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it ie ? ? > Il y a 12 minutes ? s > feasible for an audio driver to report events from an AV output. > > I was wondering about how much sense does it make to you guys use a > snd_soc_jack in this case? How does DRM handle audio? I made a quick grep, but I see the drm drivers only enabling the audio in the HW, nothing else. >>> >>> I confess to not knowing too much about audio/alsa, but what does >>> audio driver need from hdmi? Just hotplug events? >> >> At least for the case of the ASoC HDMI audio driver (but hopefully for >> other audio drivers as well), it needs to detect whether an HDMI output >> is available, if the display's current configuration supports audio >> (e.g., a 1080p display configured as VGA should be reported as not >> supporting audio). It also needs interfaces to >> configure/prepare/start/stop audio. Also, of course, needs to know if >> the display is off/on/suspended and when transitions occur. For OMAP, >> omapdss provide an interface for this functionality for ALSA or any >> other interested user. >>> >>> From a quick look, it seems most of what the existing drm drivers are >>> doing is detecting if the display supports audio, and then turning >>> on/off the hw.. (and some infoframe stuff in some cases). >> >> Yes, it seems to me that every driver makes its own audio >> implementation, mainly focused on configuration. I could not find any >> audio common interface so that users like ALSA can take advantage of. >> >> Also, I could not see any ALSA driver using functionality provided by a >> drm driver. >> >> Maybe the lack of audio support in drm is because the audio users should >> not talk to drm directly but to a lower level component (omapdrm, >> omapdss?). However, today there exists video technology supports audio >> as well, such as DisplayPort or HDMI. Could it make more sense now to >> provide audio support? > > The reason is that the audio and video handling are already separated > in the hardware level, at least, for desktop graphics. Separated in what sense? Do they have separate register banks in independent power domains? Can audio an video work with complete independence. What happens if someone decides to power off video. Is the audio able to continue if required? > > The audio infoframe is passed via ELD to the audio controller part > upon plug/unplugging via HD-audio unsolicited event, and the audio > driver sets up the stuff according to the given ELD. Thus no extra > interface between drm and ALSA was required in the kernel API level, > so far. I see that the unsolicited event is used only to parse the EDID, correct? It also notifies about the jack status. Hence, if there the cable is disconnected the application will know and act accordingly. Is this understanding correct? Also, I see that hda_pcm_ops does not have a trigger or start/stop functions, how does it know when to start/stop audio. Maybe with azx_pcm_trigger? Sorry, I am not expert in HD-audio :) Ricardo > > > Takashi >
[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 --- Comment #16 from Marek Olšák 2012-08-24 01:14:51 UTC --- Created attachment 66040 --> https://bugs.freedesktop.org/attachment.cgi?id=66040 possible fix Could you please try this patch? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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
[PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
Florian Tobias Schandinat wrote: > > On 08/01/2012 02:28 AM, Kukjin Kim wrote: > > Leela Krishna Amudala wrote: > >> > >> This patchset moves the contents of regs-fb-v4.h and regs-fb.h from > arch > >> side > >> to include/video/samsung_fimd.h > >> > >> This patchset is created and rebased against master branch of torvalds > >> tree. > >> Tested on smdk5250 board, build tested for other boards. > >> > > (Cc'ed Florian Tobias Schandinat) > > > > Yeah, since it's merge window, this series could be created against on > > mainline. And IMO, would be helpful to us if this series could be sent > to > > upstream via samsung tree after reviewing, because this touches too many > > files in samsung tree and just adds include/video/samsung_fimd.h. But > I'm > > not sure the added inclusion will be used in other file of drivers/video. > If > > so, I can provide some topic branch can be merged into Florian's tree. > > Florian, how about? > > Using a topic branch to merge it in both trees sounds like a good plan > to me. > Florian, Please pull following topic branch we talked. I already merged it into my -next. git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.7-for-florian Note, I applied Leela's V4 patches not this V2 series. If any problems, please kindly let me know. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.7-for-florian Leela Krishna Amudala (2): include/video: move fimd register headers from platform to include/video include/video: Add register offsets for FIMD version 8 arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- .../plat/regs-fb.h => include/video/samsung_fimd.h | 152 +-- 26 files changed, 165 insertions(+), 194 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h => include/video/samsung_fimd.h (73%)
[PATCH] drm/exynos: Update the MAX_EDID value for E-DDC
Hi Daniel, On 2012? 08? 23? 17:50, Daniel Vetter wrote: > On Wed, Aug 22, 2012 at 06:53:33PM +0530, Shirish S wrote: >> From: Shirish Shankarappa >> >> The value of MAX_EDID is now valid only for 2 >> block EDID data which is 256, but to support >> 4 block EDID (E-DDC) this needs to be 512. >> >> Signed-off-by: Shirish Shankarappa >> --- >> drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c >> b/drivers/gpu/drm/exynos/exynos_drm_connector.c >> index d956819..69d02b5 100644 >> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c >> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c >> @@ -32,7 +32,7 @@ >> #include "exynos_drm_drv.h" >> #include "exynos_drm_encoder.h" >> >> -#define MAX_EDID 256 >> +#define MAX_EDID 512 >> #define to_exynos_connector(x) container_of(x, struct >> exynos_drm_connector,\ >> drm_connector) > > Shouldn't this be in a common drm/edid header to begin with? This value is not real maximum length of EDID and it is only used for memory allocation by exynos connector. Actually, this allocation is unnecessary because edid is already allocated by drm_get_edid(). So, I have plan to remove this allocation and the definition once Jani Nikula's patches for removing raw_edid related memory leaks are applied. > -Daniel > Thanks and Regards, - Seung-Woo Kim -- Seung-Woo Kim Samsung Software R&D Center --
Re: [PATCH] drm: edid: add support for E-DDC
Small clarification: On Thu, Aug 23, 2012 at 4:23 PM, Daniel Vetter wrote: > On Thu, Aug 23, 2012 at 07:06:53AM -0700, Shirish S wrote: > > Hello Daniel, > > > > On Thu, Aug 23, 2012 at 1:54 AM, Daniel Vetter wrote: > > > > > On Wed, Aug 22, 2012 at 10:52:26AM +0300, Ville Syrjälä wrote: > > > > On Tue, Aug 21, 2012 at 04:28:20PM -0700, Shirish S wrote: > > > > > On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrjälä < > > > > > ville.syrj...@linux.intel.com> wrote: > > > > > > > > > > > On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote: > > > > > Here are my earlier comments on Jean's patch: > > > > > > > > > > http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html > > > > > > > > > > > > > > > > > If i am not wrong am doing exactly what you have said in you > comments. > > > > > > > > > > This seems a bit wrong to me. The spec says that the ack for the > > > > > segment address is "don't care", but for the segment pointer the > ack is > > > > > required (when segment != 0). > > > > > The variable segFlags is "dont care for block 0 and 1 wheras". > > > > > > > > > > With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 > from a > > > > > non E-DDC display, if we try to read segment != 0 from it. Of > course > > > > > we shouldn't do that unless the display lied to us about what > extension > > > > > blocks it provides. > > > > > > > > > > So I'm not sure if it would be better to trust that the display > never > > > > > lies about the extension blocks, or if we should just assume all > E-DDC > > > > > displays ack both segment addr and pointer. The no-ack feature > seems > > > > > to there for backwards compatibility, for cases where the host > always > > > > > sends the segment addr/pointer even when reading segment 0 (which > your > > > > > code doesn't do). > > > > > > > > > > To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be > split > > > > > into two flags (one for addr, other for data). > > > > > > > > > > Hence i have split the i2c_msg into 3, segment pointer,offset(addr) > > > > > and data pointer. > > > > > > > > I was referring to the addr and data phases of the segment pointer. > > > > According to the spec the ack for the addr is always optional. But I > > > > suppose no sane device would nak the addr, while acking the data. > > > > > > We've seen those. Really. > > > > > > Which is why the current i915 gmbus driver has a hack to never return a > > > NaK on the first i2c transfer. I guess we should fix this by properly > > > supporting the INGNORE_NAK field in our gmbus driver, and setting that > on > > > the addr transfer field, too. > > > > > > Thanks for the comment, so are you ok with the current logic? > > > > > > > I concure with Ville that sending the segment i2c message only when we > > > actually need it, and not unconditionally. DDC is way to broken and > > > claiming that the spec says otherwise doesn't fix all the existing bad > hw. > > > > > > > Agreed, so do you want me to post another patch, in which i add a > function > > only > > if the number of blocks is more than 2? > > Also i had some mistake in the patch set 1, hence i updated it. > > I think adding the IGNORE_NAK on the addr i2c transaction would help > unconditionally - like I've said we've seen monitors that suggest that > this is required. And yeah, I think we should send the E-DDC segment > number only if the basic edid block indicates that more than 2 blocks are > availble (and again with IGNORE_NAK, just for paranoia's sake). > > > > Kindly have a look! > > Will do. > > The patch set 2 is based on the 2 comments i received I shall post patch set 3 today,incorporating your comments. Yours, Daniel > -- > Daniel Vetter > Mail: dan...@ffwll.ch > Mobile: +41 (0)79 365 57 48 > Thanks & Regards, Shirish S ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38280] [bisected] regression : etqw tree/water wrong rendering
https://bugs.freedesktop.org/show_bug.cgi?id=38280 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Andreas Boll 2012-08-23 17:55:30 UTC --- fixed with: commit 016621ee142682153cb292cd3774e6d9377871ae Author: Vadim Girlin Date: Tue Jun 14 21:11:04 2011 +0400 r600: fix SPI inputs setup on r600/r700 Signed-off-by: Vadim Girlin Signed-off-by: Dave Airlie -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
mgag200 hang on boot
On Thu, Aug 23, 2012 at 4:22 PM, Dave Airlie wrote: > On Fri, Aug 24, 2012 at 7:51 AM, Andy Lutomirski > wrote: >> mgag200 hangs like this on startup, on a Dell PowerEge 12g box. The >> serial console says: > > You can apply this > > https://patchwork.kernel.org/patch/1298651/ Works for me. Thanks. --Andy
-next queue and EDID stuff
Hi guys (but mainly ajax) I have a bunch of EDID and quirk stuff outstanding, I've made a bundle on patchwork for it https://patchwork.kernel.org/bundle/airlied/edid-review/ Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: edid: add support for E-DDC
Small clarification: On Thu, Aug 23, 2012 at 4:23 PM, Daniel Vetter wrote: > On Thu, Aug 23, 2012 at 07:06:53AM -0700, Shirish S wrote: > > Hello Daniel, > > > > On Thu, Aug 23, 2012 at 1:54 AM, Daniel Vetter wrote: > > > > > On Wed, Aug 22, 2012 at 10:52:26AM +0300, Ville Syrj?l? wrote: > > > > On Tue, Aug 21, 2012 at 04:28:20PM -0700, Shirish S wrote: > > > > > On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrj?l? < > > > > > ville.syrjala at linux.intel.com> wrote: > > > > > > > > > > > On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote: > > > > > Here are my earlier comments on Jean's patch: > > > > > > > > > > http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html > > > > > > > > > > > > > > > > > If i am not wrong am doing exactly what you have said in you > comments. > > > > > > > > > > This seems a bit wrong to me. The spec says that the ack for the > > > > > segment address is "don't care", but for the segment pointer the > ack is > > > > > required (when segment != 0). > > > > > The variable segFlags is "dont care for block 0 and 1 wheras". > > > > > > > > > > With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 > from a > > > > > non E-DDC display, if we try to read segment != 0 from it. Of > course > > > > > we shouldn't do that unless the display lied to us about what > extension > > > > > blocks it provides. > > > > > > > > > > So I'm not sure if it would be better to trust that the display > never > > > > > lies about the extension blocks, or if we should just assume all > E-DDC > > > > > displays ack both segment addr and pointer. The no-ack feature > seems > > > > > to there for backwards compatibility, for cases where the host > always > > > > > sends the segment addr/pointer even when reading segment 0 (which > your > > > > > code doesn't do). > > > > > > > > > > To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be > split > > > > > into two flags (one for addr, other for data). > > > > > > > > > > Hence i have split the i2c_msg into 3, segment pointer,offset(addr) > > > > > and data pointer. > > > > > > > > I was referring to the addr and data phases of the segment pointer. > > > > According to the spec the ack for the addr is always optional. But I > > > > suppose no sane device would nak the addr, while acking the data. > > > > > > We've seen those. Really. > > > > > > Which is why the current i915 gmbus driver has a hack to never return a > > > NaK on the first i2c transfer. I guess we should fix this by properly > > > supporting the INGNORE_NAK field in our gmbus driver, and setting that > on > > > the addr transfer field, too. > > > > > > Thanks for the comment, so are you ok with the current logic? > > > > > > > I concure with Ville that sending the segment i2c message only when we > > > actually need it, and not unconditionally. DDC is way to broken and > > > claiming that the spec says otherwise doesn't fix all the existing bad > hw. > > > > > > > Agreed, so do you want me to post another patch, in which i add a > function > > only > > if the number of blocks is more than 2? > > Also i had some mistake in the patch set 1, hence i updated it. > > I think adding the IGNORE_NAK on the addr i2c transaction would help > unconditionally - like I've said we've seen monitors that suggest that > this is required. And yeah, I think we should send the E-DDC segment > number only if the basic edid block indicates that more than 2 blocks are > availble (and again with IGNORE_NAK, just for paranoia's sake). > > > > Kindly have a look! > > Will do. > > The patch set 2 is based on the 2 comments i received I shall post patch set 3 today,incorporating your comments. Yours, Daniel > -- > Daniel Vetter > Mail: daniel at ffwll.ch > Mobile: +41 (0)79 365 57 48 > Thanks & Regards, Shirish S -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120823/7e2d5cb9/attachment-0001.html>
Re: [PATCH] drm: gma500: Kill the GEM glue layer
On Thu, Aug 23, 2012 at 8:52 PM, Alan Cox wrote: > On Thu, 23 Aug 2012 12:03:59 +0200 > Laurent Pinchart wrote: > >> Hi Alan, >> >> On Tuesday 17 July 2012 17:21:06 Alan Cox wrote: >> > On Tue, 17 Jul 2012 17:09:25 +0200 Laurent Pinchart wrote: >> > > On Wednesday 16 May 2012 16:10:37 Alan Cox wrote: >> > > > On Wed, 16 May 2012 16:59:44 +0200 Laurent Pinchart wrote: >> > > > > The private gem_create_mmap_offset() function is now >> > > > > implemented in the DRM core as drm_gem_create_mmap_offset(). >> > > > > Use it and kill the private copy. >> > > > >> > > > That was always then plan so yes - I'll fold this into my tree >> > > > and test it. >> > > >> > > Any update ? >> > >> > Sorry it fell off the bottom of the job list. I'll do it right now >> > so it doesn't escape >> >> I still can't find the patch in drm-next. Does it have a bad tendency >> to fell off ? :-) > > I sent to Dave along with the mode setting fixes and DP/eDP support. > None of them are yet in the tree but I've not re-sent again as Dave > seemed to be busy to trying to mend the -rc tree. > Okay just grabbed all the gma500 dp/edp and this and put them into -next. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: edid: add support for E-DDC
On Thu, Aug 23, 2012 at 07:06:53AM -0700, Shirish S wrote: > Hello Daniel, > > On Thu, Aug 23, 2012 at 1:54 AM, Daniel Vetter wrote: > > > On Wed, Aug 22, 2012 at 10:52:26AM +0300, Ville Syrjälä wrote: > > > On Tue, Aug 21, 2012 at 04:28:20PM -0700, Shirish S wrote: > > > > On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrjälä < > > > > ville.syrj...@linux.intel.com> wrote: > > > > > > > > > On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote: > > > > Here are my earlier comments on Jean's patch: > > > > > > > http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html > > > > > > > > > > > > > > If i am not wrong am doing exactly what you have said in you comments. > > > > > > > > This seems a bit wrong to me. The spec says that the ack for the > > > > segment address is "don't care", but for the segment pointer the ack is > > > > required (when segment != 0). > > > > The variable segFlags is "dont care for block 0 and 1 wheras". > > > > > > > > With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from a > > > > non E-DDC display, if we try to read segment != 0 from it. Of course > > > > we shouldn't do that unless the display lied to us about what extension > > > > blocks it provides. > > > > > > > > So I'm not sure if it would be better to trust that the display never > > > > lies about the extension blocks, or if we should just assume all E-DDC > > > > displays ack both segment addr and pointer. The no-ack feature seems > > > > to there for backwards compatibility, for cases where the host always > > > > sends the segment addr/pointer even when reading segment 0 (which your > > > > code doesn't do). > > > > > > > > To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split > > > > into two flags (one for addr, other for data). > > > > > > > > Hence i have split the i2c_msg into 3, segment pointer,offset(addr) > > > > and data pointer. > > > > > > I was referring to the addr and data phases of the segment pointer. > > > According to the spec the ack for the addr is always optional. But I > > > suppose no sane device would nak the addr, while acking the data. > > > > We've seen those. Really. > > > > Which is why the current i915 gmbus driver has a hack to never return a > > NaK on the first i2c transfer. I guess we should fix this by properly > > supporting the INGNORE_NAK field in our gmbus driver, and setting that on > > the addr transfer field, too. > > > > Thanks for the comment, so are you ok with the current logic? > > > > I concure with Ville that sending the segment i2c message only when we > > actually need it, and not unconditionally. DDC is way to broken and > > claiming that the spec says otherwise doesn't fix all the existing bad hw. > > > > Agreed, so do you want me to post another patch, in which i add a function > only > if the number of blocks is more than 2? > Also i had some mistake in the patch set 1, hence i updated it. I think adding the IGNORE_NAK on the addr i2c transaction would help unconditionally - like I've said we've seen monitors that suggest that this is required. And yeah, I think we should send the E-DDC segment number only if the basic edid block indicates that more than 2 blocks are availble (and again with IGNORE_NAK, just for paranoia's sake). > Kindly have a look! Will do. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: mgag200 hang on boot
On Fri, Aug 24, 2012 at 7:51 AM, Andy Lutomirski wrote: > mgag200 hangs like this on startup, on a Dell PowerEge 12g box. The > serial console says: You can apply this https://patchwork.kernel.org/patch/1298651/ it should be in stable at some point, I expect its the same bug, it not get back to me. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1
On Thu, Aug 23, 2012 at 12:22:27PM -0700, Tejun Heo wrote: > Hello, > > On Thu, Aug 23, 2012 at 10:43:25AM +0200, Daniel Vetter wrote: > > On Thu, Aug 23, 2012 at 08:56:37AM +0100, Chris Wilson wrote: > > > On Wed, 22 Aug 2012 16:40:57 -0700, Tejun Heo wrote: > > > > This is an equivalent conversion and will ease scheduled removal of > > > > WQ_NON_REENTRANT. > > > > > > > > Signed-off-by: Tejun Heo > > > Reviewed-by: Chris Wilson > > > > Acked-by: Daniel Vetter for merging through any > > tree that pleases you (if it makes merging easier for WQ_NON_REENTRANT > > removal). Or should I just merge this through drm-intel-next? > > I think it would be better to route this one through drm-intel-next. > WQ_NON_REENTRANT won't be deprecated until after the next -rc1 anyway. Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53971] New: [drm:radeon_get_legacy_connector_info_from_bios] *ERROR* Unknown connector type: 8
https://bugs.freedesktop.org/show_bug.cgi?id=53971 Bug #: 53971 Summary: [drm:radeon_get_legacy_connector_info_from_bios] *ERROR* Unknown connector type: 8 Classification: Unclassified Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: trivial Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: orion at cora.nwra.com [1.003495] [drm] Initialized drm 1.1.0 20060810 [1.032838] [drm] radeon defaulting to kernel modesetting. [1.032842] [drm] radeon kernel modesetting enabled. [1.036619] [drm] initializing kernel modesetting (RS480 0x1002:0x5954 0x103C:0x3009). [1.036645] [drm] register mmio base: 0xFDAF [1.036647] [drm] register mmio size: 65536 [1.036867] [drm] Generation 2 PCI interface, using max accessible memory [1.036883] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [1.036885] [drm] Driver supports precise vblank timestamp query. [1.036904] [drm] radeon: irq initialized. [1.037130] [drm] Detected VRAM RAM=64M, BAR=128M [1.037133] [drm] RAM width 128bits DDR [1.040862] [drm] radeon: 64M of VRAM memory ready [1.040864] [drm] radeon: 512M of GTT memory ready. [1.040884] [drm] GART: num cpu pages 131072, num gpu pages 131072 [1.044037] [drm] radeon: ib pool ready. [1.044111] [drm] radeon: 3 quad pipes, 1 z pipes initialized. [1.048814] [drm] PCIE GART of 512M enabled (table at 0x000134C8). [1.053590] [drm] fence driver on ring 0 use gpu addr 0x8000 and cpu addr 0x88013533f000 [1.053656] [drm] Loading R300 Microcode [1.059591] [drm] radeon: ring at 0x80001000 [1.059611] [drm] ring test succeeded in 1 usecs [1.059753] [drm] ib test succeeded in 0 usecs [1.059922] [drm:radeon_get_legacy_connector_info_from_bios] *ERROR* Unknown connector type: 8 [1.059966] [drm] Radeon Display Connectors [1.059967] [drm] Connector 0: [1.059968] [drm] VGA [1.059971] [drm] DDC: 0x68 0x68 0x68 0x68 0x68 0x68 0x68 0x68 [1.059972] [drm] Encoders: [1.059973] [drm] CRT1: INTERNAL_DAC2 [1.059975] [drm] Connector 1: [1.059976] [drm] DVI-D [1.059977] [drm] HPD1 [1.059979] [drm] DDC: 0x198 0x198 0x19c 0x19c 0x1a0 0x1a0 0x1a4 0x1a4 [1.059980] [drm] Encoders: [1.059982] [drm] DFP1: INTERNAL_DVO1 [1.105608] [drm] fb mappable at 0xD004 [1.105610] [drm] vram apper at 0xD000 [1.105612] [drm] size 768 [1.105613] [drm] fb depth is 24 [1.105615] [drm]pitch is 6400 [1.105739] fbcon: radeondrmfb (fb0) is primary device [1.186275] fb0: radeondrmfb frame buffer device [1.186277] drm: registered panic notifier [1.186313] [drm] Initialized radeon 2.16.0 20080528 for :01:05.0 on minor 0 Doesn't seem to cause any problems, is this worthy of "*ERROR*"? 01:05.0 VGA compatible controller: ATI Technologies Inc RS480 [Radeon Xpress 200G Series] HP dx5150 MT BIOS 1.09 11/22/2005 Kernel 3.4.9-1.fc16.x86_64 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
mgag200 hang on boot
mgag200 hangs like this on startup, on a Dell PowerEdge 12g box. The serial console says: [4.399184] [drm] Initialized drm 1.1.0 20060810 [4.444054] [TTM] Zone kernel: Available graphics memory: 16452270 kiB [4.459610] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [4.466893] [TTM] Initializing pool allocator [4.471768] [TTM] Initializing DMA pool allocator [4.543626] fbcon: mgadrmfb (fb0) is primary device udevadm settle - timeout of 120 seconds reached, the event queue contains: /sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0 (1431) /sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0/drm/controlD64 (2238) /sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0/drm/card0 (2239) /sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0/i2c-0 (2245) /sys/devices/pci:00/:00:1c.7/:08:00.0/:09:00.0/:0a:00.0/:0b:00.0/graphics/fb0 (2249) This is 3.5.0, but the bug is not fixed in 3.5.2. When the hang happened, the actual vga output declared that it had no signal, according to the iDRAC remote management. The hang is: [ 579.919114] insmod R running task0 8873 8872 0x [ 579.919117] 8807af15b2b8 814ff9d7 0001 a01461a0 [ 579.919123] 880809665a80 8807af15bfd8 8807af15bfd8 8807af15bfd8 [ 579.919129] 8808028116a0 8808028116a0 1000 8807af15bfd8 [ 579.919135] Call Trace: [ 579.919136] [] ? __schedule+0x3b7/0x7c0 [ 579.919140] [] preempt_schedule_irq+0x45/0x60 [ 579.919144] [] retint_kernel+0x26/0x30 [ 579.919149] [] ? mga_crtc_mode_set+0x1e38/0x1ee0 [mgag200] [ 579.919158] [] ? mga_crtc_mode_set+0xacc/0x1ee0 [mgag200] [ 579.919165] [] ? idr_get_new_above+0x10/0x40 [ 579.919177] [] drm_crtc_helper_set_mode+0x36e/0x4f0 [drm_kms_helper] [ 579.919189] [] drm_crtc_helper_set_config+0x84f/0xb00 [drm_kms_helper] [ 579.919195] [] ? preempt_schedule_irq+0x45/0x60 [ 579.919200] [] drm_fb_helper_set_par+0x78/0xf0 [drm_kms_helper] [ 579.919206] [] fbcon_init+0x52c/0x5b0 [ 579.919211] [] visual_init+0xbc/0x120 [ 579.919215] [] bind_con_driver+0x19c/0x330 [ 579.919220] [] take_over_console+0x61/0x70 [ 579.919224] [] fbcon_takeover+0x5b/0xb0 [ 579.919227] [] fbcon_event_notify+0x76a/0x870 [ 579.919232] [] notifier_call_chain+0x4d/0x70 [ 579.919236] [] __blocking_notifier_call_chain+0x58/0x80 [ 579.919240] [] blocking_notifier_call_chain+0x16/0x20 [ 579.919244] [] fb_notifier_call_chain+0x1b/0x20 [ 579.919250] [] register_framebuffer+0x1ba/0x2f0 [ 579.919256] [] drm_fb_helper_single_fb_probe+0x1e3/0x300 [drm_kms_helper] [ 579.919262] [] drm_fb_helper_initial_config+0x1db/0x250 [drm_kms_helper] [ 579.919268] [] ? __kmalloc+0x16b/0x1b0 [ 579.919272] [] ? drm_fb_helper_init+0x118/0x1f0 [drm_kms_helper] [ 579.919278] [] ? kmem_cache_alloc_trace+0x143/0x170 [ 579.919282] [] mgag200_fbdev_init+0x84/0xb0 [mgag200] [ 579.919290] [] mgag200_modeset_init+0x1b7/0x230 [mgag200] [ 579.919297] [] mgag200_driver_load+0x3e1/0x4b0 [mgag200] [ 579.919305] [] drm_get_pci_dev+0x191/0x2b0 [drm] [ 579.919324] [] mga_pci_probe+0xac/0xb4 [mgag200] [ 579.919332] [] local_pci_probe+0x5c/0xd0 [ 579.919339] [] pci_device_probe+0x109/0x130 [ 579.919345] [] driver_probe_device+0x7e/0x220 [ 579.919353] [] __driver_attach+0xab/0xb0 [ 579.919358] [] ? driver_probe_device+0x220/0x220 [ 579.919363] [] bus_for_each_dev+0x56/0x90 [ 579.919369] [] driver_attach+0x1e/0x20 [ 579.919373] [] bus_add_driver+0x1a0/0x270 [ 579.919379] [] driver_register+0x76/0x130 [ 579.919382] [] __pci_register_driver+0x56/0xd0 [ 579.919387] [] ? notifier_call_chain+0x4d/0x70 [ 579.919393] [] drm_pci_init+0x11a/0x130 [drm] [ 579.919406] [] ? 0xa00d7fff [ 579.919413] [] mgag200_init+0x3c/0x1000 [mgag200] [ 579.919419] [] do_one_initcall+0x3f/0x170 [ 579.919424] [] sys_init_module+0xbe/0x230 [ 579.919430] [] system_call_fastpath+0x16/0x1b' insmod is taking 100% cpu. Is there anything I can do to debug this? I don't really need mgag200, since I do pretty much everything via serial console. --Andy -- Andy Lutomirski AMA Capital Management, LLC
[RFC 0/5] Generic panel framework
Hi Laurent, Do you plan to add an API to get and parse EDID to mode list? video mode is tightly coupled with panel that is capable of hot-plug. Or you are busy on modifying EDID parsing code for sharing it amoung DRM/FB/etc? I see you mentioned this in Mar. It is great if you are considering add more info into video mode, such as pixel repeating, 3D timing related parameter. I have some code for CEA modes filtering and 3D parsing, but still tight coupled with FB and with a little hack style. My HDMI driver is implemented as lcd device as you mentioned here. But more complex than other lcd devices for a kthread is handling hot-plug/EDID/HDCP/ASoC etc. I also feel a little weird to add code parsing HDMI audio related info in fbmod.c in my current implementation, thought it is the only place to handle EDID in kernel. Your panel framework provide a better place to add panel related audio/HDCP code. panel notifier can also trigger hot-plug related feature, such as HDCP start. Looking forward to your hot-plug panel patch. Or I can help add it if you would like me to. Thanks! Jun
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||OBSOLETE -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 34212] radeon: 3650 AGP lockup on radeon.ko load
https://bugzilla.kernel.org/show_bug.cgi?id=34212 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||OBSOLETE --- Comment #2 from Alan 2012-08-23 13:47:59 --- If this bug is still seen with modern kernels please update/reopen -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[XDC 2012] Conference Update #2
We are a little less than one month into XDC 2012 so here's some update: Registration: - So far we have 32 registered participants - which is pretty good. If you plan to come and haven't added yourself to the participants list at http://wiki.x.org/wiki/Events/XDC2012/Attendees, please do so! Presentations: -- Our program list is still quite empty, so if you have something to present, please add yourself to http://wiki.x.org/wiki/Events/XDC2012/Program! Weekend Event: -- As announced we are planning a hiking trip to the Frankonian countryside on Saturday for all those are still there for the weekend. On this trip we will have the opportunity to visit some local brewery beergardens. if you would like to join us for this trip please register yourself at http://wiki.x.org/wiki/Events/XDC2012/Weekend so that we get a rough estimate on how many people to expect. Hotel Reservation: -- The reservation period for which we allocated rooms and negotiated a special price at the Azimut Hotel is over - I've been informed by the hotel that it is completely booked out at this time. You may still try at one of the other hotels listed. All of them are still at walking distance to the venue. There are other hotels in the vicinity - however I have not stayed at any of them. if you have difficulties finding a hotel please contact the organizers. Limited Email Access: - Speaking of contacting the organizers, I will have limited email access for the next two weeks, thus if you have urgent inquiries, please contact Stefan Dirsch for assistance. I've also updated the event Wiki pages accordingly. See you in Nuernberg! Egbert. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #21 from Alexandre Demers
2012-08-23 13:13:25 UTC ---
(In reply to comment #20)
> (In reply to comment #19)
> > So about this locking piglit test (depthstencil-render-miplevels 146
> > s=z24_s8_d=z32f_s8), I've been able to track it down to:
> > line 218: piglit_report_result(PIGLIT_SKIP);
>
> How did you determine that? It's weird, I wouldn't expect a skipped test to
> produce any actual GPU rendering.
I used gdb and step into the code until it locked. It gets out at level 0,
after going through:
/**
* Attach the proper miplevel of each texture to the framebuffer
*/
void
set_up_framebuffer_for_miplevel(int level)...
Before this call, there is a framebuffer initialization:
GLuint fbo;
glGenFramebuffers(1, &fbo);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fbo);
glBindFramebuffer(GL_READ_FRAMEBUFFER, fbo);
for (int level = 0; level <= max_miplevel; ++level) {
set_up_framebuffer_for_miplevel(level);
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[PATCH V2] drm: edid: add support for E-DDC
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.
Signed-off-by: Shirish S
---
drivers/gpu/drm/drm_edid.c | 19 +--
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a8743c3..33a3888 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -253,7 +253,9 @@ static int
drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf,
int block, int len)
{
- unsigned char start = block * EDID_LENGTH;
+ unsigned short start = block * EDID_LENGTH;
+ unsigned char segment = block >> 1;
+ unsigned short segFlags = segment ? 0 : I2C_M_IGNORE_NAK;
int ret, retries = 5;
/* The core i2c driver will automatically retry the transfer if the
@@ -264,27 +266,32 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
*/
do {
struct i2c_msg msgs[] = {
- {
+ { /*set segment pointer */
+ .addr = DDC_SEGMENT_ADDR,
+ .flags = segFlags,
+ .len= 1,
+ .buf= &segment,
+ }, { /*set offset */
.addr = DDC_ADDR,
.flags = 0,
.len= 1,
.buf= &start,
- }, {
+ }, { /*set data */
.addr = DDC_ADDR,
.flags = I2C_M_RD,
.len= len,
.buf= buf,
}
};
- ret = i2c_transfer(adapter, msgs, 2);
+ ret = i2c_transfer(adapter, msgs, 3);
if (ret == -ENXIO) {
DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
adapter->name);
break;
}
- } while (ret != 2 && --retries);
+ } while (ret != 3 && --retries);
- return ret == 2 ? 0 : -1;
+ return ret == 3 ? 0 : -1;
}
static bool drm_edid_is_zero(u8 *in_edid, int length)
--
1.7.0.4
[PATCH V2] drm: edid: add support for E-DDC
This patch adds support in probing 4 block edid data, for E-DDC. This is the first test case in CTS, for HDMI compliance. Changes from V1: 1. Data type of offset adress updated to unsigned short 2. Updated the buf feild of msg[0] Based on drm-next branch Shirish S (1): drm: edid: add support for E-DDC drivers/gpu/drm/drm_edid.c | 19 +-- 1 files changed, 13 insertions(+), 6 deletions(-)
[PATCH] drm/exynos: Update the MAX_EDID value for E-DDC
The value of MAX_EDID is now valid only for 2 block EDID data which is 256, but to support 4 block EDID (E-DDC) this needs to be 512. Signed-off-by: Shirish S --- drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c b/drivers/gpu/drm/exynos/exynos_drm_connector.c index d956819..69d02b5 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c @@ -32,7 +32,7 @@ #include "exynos_drm_drv.h" #include "exynos_drm_encoder.h" -#define MAX_EDID 256 +#define MAX_EDID 512 #define to_exynos_connector(x) container_of(x, struct exynos_drm_connector,\ drm_connector) -- 1.7.0.4
[PATCH] Update MAX_EDID value in exynos
The value of MAX_EDID is now valid only for 2 block EDID data which is 256, but to support 4 block EDID (E-DDC) this needs to be 512. Based on drm-next branch Shirish S (1): drm/exynos: Update the MAX_EDID value for E-DDC drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Re: [PATCH] i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1
Hello, On Thu, Aug 23, 2012 at 10:43:25AM +0200, Daniel Vetter wrote: > On Thu, Aug 23, 2012 at 08:56:37AM +0100, Chris Wilson wrote: > > On Wed, 22 Aug 2012 16:40:57 -0700, Tejun Heo wrote: > > > This is an equivalent conversion and will ease scheduled removal of > > > WQ_NON_REENTRANT. > > > > > > Signed-off-by: Tejun Heo > > Reviewed-by: Chris Wilson > > Acked-by: Daniel Vetter for merging through any > tree that pleases you (if it makes merging easier for WQ_NON_REENTRANT > removal). Or should I just merge this through drm-intel-next? I think it would be better to route this one through drm-intel-next. WQ_NON_REENTRANT won't be deprecated until after the next -rc1 anyway. Thanks! -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1
Hello, On Thu, Aug 23, 2012 at 10:43:25AM +0200, Daniel Vetter wrote: > On Thu, Aug 23, 2012 at 08:56:37AM +0100, Chris Wilson wrote: > > On Wed, 22 Aug 2012 16:40:57 -0700, Tejun Heo wrote: > > > This is an equivalent conversion and will ease scheduled removal of > > > WQ_NON_REENTRANT. > > > > > > Signed-off-by: Tejun Heo > > Reviewed-by: Chris Wilson > > Acked-by: Daniel Vetter for merging through any > tree that pleases you (if it makes merging easier for WQ_NON_REENTRANT > removal). Or should I just merge this through drm-intel-next? I think it would be better to route this one through drm-intel-next. WQ_NON_REENTRANT won't be deprecated until after the next -rc1 anyway. Thanks! -- tejun
[PULL] drm documentation
Hi Dave, The DRM documentation has been floating around for quite some time now. It's time to get it in mainline, otherwise it will start bit-rotting all alone (there's too little documentation written for the kernel, it would feel so lonely outside of Documentation/DocBook/). The following changes since commit 269b62db0e52bf2656aa762d61cfe67f3705fdff: Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel into drm-next (2012-08-23 15:12:44 +1000) are available in the git repository at: git://linuxtv.org/pinchartl/fbdev.git drm-doc Laurent Pinchart (1): Documentation: DocBook DRM framework documentation Documentation/DocBook/drm.tmpl | 2835 ++- -- Regards, Laurent Pinchart
[PATCH 0/2] Miscellaneous mode set and page flip fixes
On Thursday 19 July 2012 13:55:37 Laurent Pinchart wrote: > On Thursday 31 May 2012 18:26:14 Laurent Pinchart wrote: > > Hi everybody, > > > > Here are two small fixes that disallow format changes in page flip > > operations, and perform a full mode set instead of a mode set base in the > > CRTC helper set config handler if the pixel format changed. > > Ping ? Can those two patches be applied ? Ping again ? > > Laurent Pinchart (2): > > drm: Don't allow page flip to change pixel format > > drm: Perform a full mode set when the pixel format changed > > > > drivers/gpu/drm/drm_crtc.c|8 > > drivers/gpu/drm/drm_crtc_helper.c |3 +++ > > 2 files changed, 11 insertions(+), 0 deletions(-) -- Regards, Laurent Pinchart
[PATCH] drm: gma500: Kill the GEM glue layer
Hi Alan, On Tuesday 17 July 2012 17:21:06 Alan Cox wrote: > On Tue, 17 Jul 2012 17:09:25 +0200 Laurent Pinchart wrote: > > On Wednesday 16 May 2012 16:10:37 Alan Cox wrote: > > > On Wed, 16 May 2012 16:59:44 +0200 Laurent Pinchart wrote: > > > > The private gem_create_mmap_offset() function is now implemented > > > > in the DRM core as drm_gem_create_mmap_offset(). Use it and kill > > > > the private copy. > > > > > > That was always then plan so yes - I'll fold this into my tree and > > > test it. > > > > Any update ? > > Sorry it fell off the bottom of the job list. I'll do it right now so > it doesn't escape I still can't find the patch in drm-next. Does it have a bad tendency to fell off ? :-) -- Regards, Laurent Pinchart
[PATCH] drm: gma500: Kill the GEM glue layer
On Thu, 23 Aug 2012 12:03:59 +0200 Laurent Pinchart wrote: > Hi Alan, > > On Tuesday 17 July 2012 17:21:06 Alan Cox wrote: > > On Tue, 17 Jul 2012 17:09:25 +0200 Laurent Pinchart wrote: > > > On Wednesday 16 May 2012 16:10:37 Alan Cox wrote: > > > > On Wed, 16 May 2012 16:59:44 +0200 Laurent Pinchart wrote: > > > > > The private gem_create_mmap_offset() function is now > > > > > implemented in the DRM core as drm_gem_create_mmap_offset(). > > > > > Use it and kill the private copy. > > > > > > > > That was always then plan so yes - I'll fold this into my tree > > > > and test it. > > > > > > Any update ? > > > > Sorry it fell off the bottom of the job list. I'll do it right now > > so it doesn't escape > > I still can't find the patch in drm-next. Does it have a bad tendency > to fell off ? :-) I sent to Dave along with the mode setting fixes and DP/eDP support. None of them are yet in the tree but I've not re-sent again as Dave seemed to be busy to trying to mend the -rc tree. Alan
[Bug 41744] Unigine Heaven shows black textures (Radeon HD4250)
https://bugs.freedesktop.org/show_bug.cgi?id=41744 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from Andreas Boll 2012-08-23 11:26:44 UTC --- As mentioned above in Comment 5 and Comment 11 properly installing libtxc-dxtn library fixed the black textures. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38280] [bisected] regression : etqw tree/water wrong rendering
https://bugs.freedesktop.org/show_bug.cgi?id=38280 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Andreas Boll 2012-08-23 17:55:30 UTC --- fixed with: commit 016621ee142682153cb292cd3774e6d9377871ae Author: Vadim Girlin Date: Tue Jun 14 21:11:04 2011 +0400 r600: fix SPI inputs setup on r600/r700 Signed-off-by: Vadim Girlin Signed-off-by: Dave Airlie -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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
[PATCH] drm: edid: add support for E-DDC
On Wed, Aug 22, 2012 at 10:52:26AM +0300, Ville Syrj?l? wrote: > On Tue, Aug 21, 2012 at 04:28:20PM -0700, Shirish S wrote: > > On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrj?l? < > > ville.syrjala at linux.intel.com> wrote: > > > > > On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote: > > Here are my earlier comments on Jean's patch: > > > http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html > > > > > > > > If i am not wrong am doing exactly what you have said in you comments. > > > > This seems a bit wrong to me. The spec says that the ack for the > > segment address is "don't care", but for the segment pointer the ack is > > required (when segment != 0). > > The variable segFlags is "dont care for block 0 and 1 wheras". > > > > With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from a > > non E-DDC display, if we try to read segment != 0 from it. Of course > > we shouldn't do that unless the display lied to us about what extension > > blocks it provides. > > > > So I'm not sure if it would be better to trust that the display never > > lies about the extension blocks, or if we should just assume all E-DDC > > displays ack both segment addr and pointer. The no-ack feature seems > > to there for backwards compatibility, for cases where the host always > > sends the segment addr/pointer even when reading segment 0 (which your > > code doesn't do). > > > > To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split > > into two flags (one for addr, other for data). > > > > Hence i have split the i2c_msg into 3, segment pointer,offset(addr) > > and data pointer. > > I was referring to the addr and data phases of the segment pointer. > According to the spec the ack for the addr is always optional. But I > suppose no sane device would nak the addr, while acking the data. We've seen those. Really. Which is why the current i915 gmbus driver has a hack to never return a NaK on the first i2c transfer. I guess we should fix this by properly supporting the INGNORE_NAK field in our gmbus driver, and setting that on the addr transfer field, too. I concure with Ville that sending the segment i2c message only when we actually need it, and not unconditionally. DDC is way to broken and claiming that the spec says otherwise doesn't fix all the existing bad hw. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH] drm/exynos: Update the MAX_EDID value for E-DDC
On Wed, Aug 22, 2012 at 06:53:33PM +0530, Shirish S wrote: > From: Shirish Shankarappa > > The value of MAX_EDID is now valid only for 2 > block EDID data which is 256, but to support > 4 block EDID (E-DDC) this needs to be 512. > > Signed-off-by: Shirish Shankarappa > --- > drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c > b/drivers/gpu/drm/exynos/exynos_drm_connector.c > index d956819..69d02b5 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c > @@ -32,7 +32,7 @@ > #include "exynos_drm_drv.h" > #include "exynos_drm_encoder.h" > > -#define MAX_EDID 256 > +#define MAX_EDID 512 > #define to_exynos_connector(x) container_of(x, struct > exynos_drm_connector,\ > drm_connector) Shouldn't this be in a common drm/edid header to begin with? -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH] i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1
On Thu, Aug 23, 2012 at 08:56:37AM +0100, Chris Wilson wrote: > On Wed, 22 Aug 2012 16:40:57 -0700, Tejun Heo wrote: > > This is an equivalent conversion and will ease scheduled removal of > > WQ_NON_REENTRANT. > > > > Signed-off-by: Tejun Heo > Reviewed-by: Chris Wilson Acked-by: Daniel Vetter for merging through any tree that pleases you (if it makes merging easier for WQ_NON_REENTRANT removal). Or should I just merge this through drm-intel-next? -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH] i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1
On Wed, 22 Aug 2012 16:40:57 -0700, Tejun Heo wrote: > This is an equivalent conversion and will ease scheduled removal of > WQ_NON_REENTRANT. > > Signed-off-by: Tejun Heo Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCHv8 18/26] v4l: add buffer exporting via dmabuf
On Thu August 23 2012 01:39:34 Laurent Pinchart wrote:
> Hi Hans,
>
> On Wednesday 22 August 2012 13:41:05 Hans Verkuil wrote:
> > On Tue August 14 2012 17:34:48 Tomasz Stanislawski wrote:
> > > This patch adds extension to V4L2 api. It allow to export a mmap buffer as
> > > file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer
> > > offset used by mmap and return a file descriptor on success.
> > >
> > > Signed-off-by: Tomasz Stanislawski
> > > Signed-off-by: Kyungmin Park
>
> [snip]
>
> > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > > index 7f918dc..b5d058b 100644
> > > --- a/include/linux/videodev2.h
> > > +++ b/include/linux/videodev2.h
> > > @@ -688,6 +688,31 @@ struct v4l2_buffer {
> > >
> > > #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
> > > #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
> > >
> > > +/**
> > > + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> > > descriptor + *
> > > + * @fd: file descriptor associated with DMABUF (set by driver)
> > > + * @mem_offset: buffer memory offset as returned by VIDIOC_QUERYBUF in
> > > struct + *v4l2_buffer::m.offset (for single-plane
> > > formats) or
> > > + * v4l2_plane::m.offset (for multi-planar formats)
> > > + * @flags: flags for newly created file, currently only O_CLOEXEC
> > > is
> > > + * supported, refer to manual of open syscall for more
> > > details
> > > + *
> > > + * Contains data used for exporting a video buffer as DMABUF file
> > > descriptor. + * The buffer is identified by a 'cookie' returned by
> > > VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer to
> > > userspace). All + * reserved fields must be set to zero. The field
> > > reserved0 is expected to + * become a structure 'type' allowing an
> > > alternative layout of the structure + * content. Therefore this field
> > > should not be used for any other extensions. + */
> > > +struct v4l2_exportbuffer {
> > > + __u32 fd;
> > > + __u32 reserved0;
> > > + __u32 mem_offset;
> > > + __u32 flags;
> > > + __u32 reserved[12];
> > > +};
> >
> > OK, I realized that we also need a type field here: you need the type field
> > (same as in v4l2_buffer) to know which queue the mem_offset refers to. For
> > M2M devices you have two queues, so you need this information.
> >
> > Is there any reason not to use __u32 memory instead of __u32 reserved0?
> > I really dislike 'reserved0'. It's also very inconsistent with the other
> > buffer ioctls which all have type+memory fields.
>
> I'm concerned that we might need to export buffers in the future based on
> something else than the memory type. That's probably an irrational fear
> though.
We're exporting buffers from the V4L2 core. The only method of creating such
buffers is through REQBUFS/CREATE_BUFS, both of which use the memory field.
Even if we need something else in the future, then there is nothing preventing
us from extending the memory enum.
> > Regarding mem_offset: I would prefer a union (possibly anonymous):
> >
> > union {
> > __u32 mem_offset;
> > unsigned long reserved;
> > } m;
> >
> > Again, it's more consistent with the existing buffer ioctls, and it prepares
> > the API for future pointer values. 'reserved' in the union above could even
> > safely be renamed to userptr, even though userptr isn't supported at the
> > moment.
>
> Once again I would really want to see compeling use cases before we export a
> userptr buffer as a dmabuf object. As Mauro previously stated, userptr for
> buffer sharing was a hack in the first place (although a pretty successful
> one
> so far).
I don't want to export a userptr, I want to make sure we *can* export a
pointer-sized thing in the future. Which is why in my proposal above I'm
calling it reserved and not userptr.
Regards,
Hans
[Bug 53971] New: [drm:radeon_get_legacy_connector_info_from_bios] *ERROR* Unknown connector type: 8
https://bugs.freedesktop.org/show_bug.cgi?id=53971 Bug #: 53971 Summary: [drm:radeon_get_legacy_connector_info_from_bios] *ERROR* Unknown connector type: 8 Classification: Unclassified Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: trivial Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: or...@cora.nwra.com [1.003495] [drm] Initialized drm 1.1.0 20060810 [1.032838] [drm] radeon defaulting to kernel modesetting. [1.032842] [drm] radeon kernel modesetting enabled. [1.036619] [drm] initializing kernel modesetting (RS480 0x1002:0x5954 0x103C:0x3009). [1.036645] [drm] register mmio base: 0xFDAF [1.036647] [drm] register mmio size: 65536 [1.036867] [drm] Generation 2 PCI interface, using max accessible memory [1.036883] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [1.036885] [drm] Driver supports precise vblank timestamp query. [1.036904] [drm] radeon: irq initialized. [1.037130] [drm] Detected VRAM RAM=64M, BAR=128M [1.037133] [drm] RAM width 128bits DDR [1.040862] [drm] radeon: 64M of VRAM memory ready [1.040864] [drm] radeon: 512M of GTT memory ready. [1.040884] [drm] GART: num cpu pages 131072, num gpu pages 131072 [1.044037] [drm] radeon: ib pool ready. [1.044111] [drm] radeon: 3 quad pipes, 1 z pipes initialized. [1.048814] [drm] PCIE GART of 512M enabled (table at 0x000134C8). [1.053590] [drm] fence driver on ring 0 use gpu addr 0x8000 and cpu addr 0x88013533f000 [1.053656] [drm] Loading R300 Microcode [1.059591] [drm] radeon: ring at 0x80001000 [1.059611] [drm] ring test succeeded in 1 usecs [1.059753] [drm] ib test succeeded in 0 usecs [1.059922] [drm:radeon_get_legacy_connector_info_from_bios] *ERROR* Unknown connector type: 8 [1.059966] [drm] Radeon Display Connectors [1.059967] [drm] Connector 0: [1.059968] [drm] VGA [1.059971] [drm] DDC: 0x68 0x68 0x68 0x68 0x68 0x68 0x68 0x68 [1.059972] [drm] Encoders: [1.059973] [drm] CRT1: INTERNAL_DAC2 [1.059975] [drm] Connector 1: [1.059976] [drm] DVI-D [1.059977] [drm] HPD1 [1.059979] [drm] DDC: 0x198 0x198 0x19c 0x19c 0x1a0 0x1a0 0x1a4 0x1a4 [1.059980] [drm] Encoders: [1.059982] [drm] DFP1: INTERNAL_DVO1 [1.105608] [drm] fb mappable at 0xD004 [1.105610] [drm] vram apper at 0xD000 [1.105612] [drm] size 768 [1.105613] [drm] fb depth is 24 [1.105615] [drm]pitch is 6400 [1.105739] fbcon: radeondrmfb (fb0) is primary device [1.186275] fb0: radeondrmfb frame buffer device [1.186277] drm: registered panic notifier [1.186313] [drm] Initialized radeon 2.16.0 20080528 for :01:05.0 on minor 0 Doesn't seem to cause any problems, is this worthy of "*ERROR*"? 01:05.0 VGA compatible controller: ATI Technologies Inc RS480 [Radeon Xpress 200G Series] HP dx5150 MT BIOS 1.09 11/22/2005 Kernel 3.4.9-1.fc16.x86_64 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] drm: edid: add support for E-DDC
Hello Daniel, On Thu, Aug 23, 2012 at 1:54 AM, Daniel Vetter wrote: > On Wed, Aug 22, 2012 at 10:52:26AM +0300, Ville Syrjälä wrote: > > On Tue, Aug 21, 2012 at 04:28:20PM -0700, Shirish S wrote: > > > On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrjälä < > > > ville.syrj...@linux.intel.com> wrote: > > > > > > > On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote: > > > Here are my earlier comments on Jean's patch: > > > > > http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html > > > > > > > > > > > If i am not wrong am doing exactly what you have said in you comments. > > > > > > This seems a bit wrong to me. The spec says that the ack for the > > > segment address is "don't care", but for the segment pointer the ack is > > > required (when segment != 0). > > > The variable segFlags is "dont care for block 0 and 1 wheras". > > > > > > With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from a > > > non E-DDC display, if we try to read segment != 0 from it. Of course > > > we shouldn't do that unless the display lied to us about what extension > > > blocks it provides. > > > > > > So I'm not sure if it would be better to trust that the display never > > > lies about the extension blocks, or if we should just assume all E-DDC > > > displays ack both segment addr and pointer. The no-ack feature seems > > > to there for backwards compatibility, for cases where the host always > > > sends the segment addr/pointer even when reading segment 0 (which your > > > code doesn't do). > > > > > > To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split > > > into two flags (one for addr, other for data). > > > > > > Hence i have split the i2c_msg into 3, segment pointer,offset(addr) > > > and data pointer. > > > > I was referring to the addr and data phases of the segment pointer. > > According to the spec the ack for the addr is always optional. But I > > suppose no sane device would nak the addr, while acking the data. > > We've seen those. Really. > > Which is why the current i915 gmbus driver has a hack to never return a > NaK on the first i2c transfer. I guess we should fix this by properly > supporting the INGNORE_NAK field in our gmbus driver, and setting that on > the addr transfer field, too. > > Thanks for the comment, so are you ok with the current logic? > I concure with Ville that sending the segment i2c message only when we > actually need it, and not unconditionally. DDC is way to broken and > claiming that the spec says otherwise doesn't fix all the existing bad hw. > Agreed, so do you want me to post another patch, in which i add a function only if the number of blocks is more than 2? Also i had some mistake in the patch set 1, hence i updated it. Kindly have a look! > -Daniel > -- > Daniel Vetter > Mail: dan...@ffwll.ch > Mobile: +41 (0)79 365 57 48 > Thanks & Regards, Shirish S ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: edid: add support for E-DDC
Hello Daniel, On Thu, Aug 23, 2012 at 1:54 AM, Daniel Vetter wrote: > On Wed, Aug 22, 2012 at 10:52:26AM +0300, Ville Syrj?l? wrote: > > On Tue, Aug 21, 2012 at 04:28:20PM -0700, Shirish S wrote: > > > On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrj?l? < > > > ville.syrjala at linux.intel.com> wrote: > > > > > > > On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote: > > > Here are my earlier comments on Jean's patch: > > > > > http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html > > > > > > > > > > > If i am not wrong am doing exactly what you have said in you comments. > > > > > > This seems a bit wrong to me. The spec says that the ack for the > > > segment address is "don't care", but for the segment pointer the ack is > > > required (when segment != 0). > > > The variable segFlags is "dont care for block 0 and 1 wheras". > > > > > > With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from a > > > non E-DDC display, if we try to read segment != 0 from it. Of course > > > we shouldn't do that unless the display lied to us about what extension > > > blocks it provides. > > > > > > So I'm not sure if it would be better to trust that the display never > > > lies about the extension blocks, or if we should just assume all E-DDC > > > displays ack both segment addr and pointer. The no-ack feature seems > > > to there for backwards compatibility, for cases where the host always > > > sends the segment addr/pointer even when reading segment 0 (which your > > > code doesn't do). > > > > > > To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split > > > into two flags (one for addr, other for data). > > > > > > Hence i have split the i2c_msg into 3, segment pointer,offset(addr) > > > and data pointer. > > > > I was referring to the addr and data phases of the segment pointer. > > According to the spec the ack for the addr is always optional. But I > > suppose no sane device would nak the addr, while acking the data. > > We've seen those. Really. > > Which is why the current i915 gmbus driver has a hack to never return a > NaK on the first i2c transfer. I guess we should fix this by properly > supporting the INGNORE_NAK field in our gmbus driver, and setting that on > the addr transfer field, too. > > Thanks for the comment, so are you ok with the current logic? > I concure with Ville that sending the segment i2c message only when we > actually need it, and not unconditionally. DDC is way to broken and > claiming that the spec says otherwise doesn't fix all the existing bad hw. > Agreed, so do you want me to post another patch, in which i add a function only if the number of blocks is more than 2? Also i had some mistake in the patch set 1, hence i updated it. Kindly have a look! > -Daniel > -- > Daniel Vetter > Mail: daniel at ffwll.ch > Mobile: +41 (0)79 365 57 48 > Thanks & Regards, Shirish S -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120823/061d52fd/attachment.html>
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution||OBSOLETE -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: edid: add support for E-DDC
Hello Ville, On Wed, Aug 22, 2012 at 12:52 AM, Ville Syrjälä < ville.syrj...@linux.intel.com> wrote: > On Tue, Aug 21, 2012 at 04:28:20PM -0700, Shirish S wrote: > > On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrjälä < > > ville.syrj...@linux.intel.com> wrote: > > > > > On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote: > > Here are my earlier comments on Jean's patch: > > > > http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html > > > > > > > > If i am not wrong am doing exactly what you have said in you comments. > > > > This seems a bit wrong to me. The spec says that the ack for the > > segment address is "don't care", but for the segment pointer the ack is > > required (when segment != 0). > > The variable segFlags is "dont care for block 0 and 1 wheras". > > > > With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from a > > non E-DDC display, if we try to read segment != 0 from it. Of course > > we shouldn't do that unless the display lied to us about what extension > > blocks it provides. > > > > So I'm not sure if it would be better to trust that the display never > > lies about the extension blocks, or if we should just assume all E-DDC > > displays ack both segment addr and pointer. The no-ack feature seems > > to there for backwards compatibility, for cases where the host always > > sends the segment addr/pointer even when reading segment 0 (which your > > code doesn't do). > > > > To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split > > into two flags (one for addr, other for data). > > > > Hence i have split the i2c_msg into 3, segment pointer,offset(addr) > > and data pointer. > > I was referring to the addr and data phases of the segment pointer. > According to the spec the ack for the addr is always optional. But I > suppose no sane device would nak the addr, while acking the data. > > Thanks for your comment, actually there was a mistake in my code, i have posted the second set. Kindly have a look. > -- > Ville Syrjälä > Intel OTC > Regards, Shirish S ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: edid: add support for E-DDC
Hello Ville, On Wed, Aug 22, 2012 at 12:52 AM, Ville Syrj?l? < ville.syrjala at linux.intel.com> wrote: > On Tue, Aug 21, 2012 at 04:28:20PM -0700, Shirish S wrote: > > On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrj?l? < > > ville.syrjala at linux.intel.com> wrote: > > > > > On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote: > > Here are my earlier comments on Jean's patch: > > > > http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html > > > > > > > > If i am not wrong am doing exactly what you have said in you comments. > > > > This seems a bit wrong to me. The spec says that the ack for the > > segment address is "don't care", but for the segment pointer the ack is > > required (when segment != 0). > > The variable segFlags is "dont care for block 0 and 1 wheras". > > > > With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from a > > non E-DDC display, if we try to read segment != 0 from it. Of course > > we shouldn't do that unless the display lied to us about what extension > > blocks it provides. > > > > So I'm not sure if it would be better to trust that the display never > > lies about the extension blocks, or if we should just assume all E-DDC > > displays ack both segment addr and pointer. The no-ack feature seems > > to there for backwards compatibility, for cases where the host always > > sends the segment addr/pointer even when reading segment 0 (which your > > code doesn't do). > > > > To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split > > into two flags (one for addr, other for data). > > > > Hence i have split the i2c_msg into 3, segment pointer,offset(addr) > > and data pointer. > > I was referring to the addr and data phases of the segment pointer. > According to the spec the ack for the addr is always optional. But I > suppose no sane device would nak the addr, while acking the data. > > Thanks for your comment, actually there was a mistake in my code, i have posted the second set. Kindly have a look. > -- > Ville Syrj?l? > Intel OTC > Regards, Shirish S -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120823/dc546ce5/attachment-0001.html>
Re: [PATCH] drm/exynos: Update the MAX_EDID value for E-DDC
Hello, On Thu, Aug 23, 2012 at 2:52 AM, 김승우 wrote: > Hi Daniel, > > On 2012년 08월 23일 17:50, Daniel Vetter wrote: > > On Wed, Aug 22, 2012 at 06:53:33PM +0530, Shirish S wrote: > >> From: Shirish Shankarappa > >> > >> The value of MAX_EDID is now valid only for 2 > >> block EDID data which is 256, but to support > >> 4 block EDID (E-DDC) this needs to be 512. > >> > >> Signed-off-by: Shirish Shankarappa > >> --- > >> drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- > >> 1 files changed, 1 insertions(+), 1 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c > b/drivers/gpu/drm/exynos/exynos_drm_connector.c > >> index d956819..69d02b5 100644 > >> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c > >> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c > >> @@ -32,7 +32,7 @@ > >> #include "exynos_drm_drv.h" > >> #include "exynos_drm_encoder.h" > >> > >> -#define MAX_EDID 256 > >> +#define MAX_EDID 512 > >> #define to_exynos_connector(x) container_of(x, struct > exynos_drm_connector,\ > >> drm_connector) > > > > Shouldn't this be in a common drm/edid header to begin with? > > This value is not real maximum length of EDID and it is only used for > memory allocation by exynos connector. Actually, this allocation is > unnecessary because edid is already allocated by drm_get_edid(). > > So, I have plan to remove this allocation and the definition once Jani > Nikula's patches for removing raw_edid related memory leaks are applied. > > I was not aware of your plans to remove it, anyways for verifying the patch for 4 block EDID data, this modification is required,hence i thought of posting this patch. > > -Daniel > > > > Thanks and Regards, > - Seung-Woo Kim > > > -- > Seung-Woo Kim > Samsung Software R&D Center > -- > > Thanks& Regards, Shirish S > ___ > 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] drm/exynos: Update the MAX_EDID value for E-DDC
Hello, On Thu, Aug 23, 2012 at 2:52 AM, ??? wrote: > Hi Daniel, > > On 2012? 08? 23? 17:50, Daniel Vetter wrote: > > On Wed, Aug 22, 2012 at 06:53:33PM +0530, Shirish S wrote: > >> From: Shirish Shankarappa > >> > >> The value of MAX_EDID is now valid only for 2 > >> block EDID data which is 256, but to support > >> 4 block EDID (E-DDC) this needs to be 512. > >> > >> Signed-off-by: Shirish Shankarappa > >> --- > >> drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- > >> 1 files changed, 1 insertions(+), 1 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c > b/drivers/gpu/drm/exynos/exynos_drm_connector.c > >> index d956819..69d02b5 100644 > >> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c > >> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c > >> @@ -32,7 +32,7 @@ > >> #include "exynos_drm_drv.h" > >> #include "exynos_drm_encoder.h" > >> > >> -#define MAX_EDID 256 > >> +#define MAX_EDID 512 > >> #define to_exynos_connector(x) container_of(x, struct > exynos_drm_connector,\ > >> drm_connector) > > > > Shouldn't this be in a common drm/edid header to begin with? > > This value is not real maximum length of EDID and it is only used for > memory allocation by exynos connector. Actually, this allocation is > unnecessary because edid is already allocated by drm_get_edid(). > > So, I have plan to remove this allocation and the definition once Jani > Nikula's patches for removing raw_edid related memory leaks are applied. > > I was not aware of your plans to remove it, anyways for verifying the patch for 4 block EDID data, this modification is required,hence i thought of posting this patch. > > -Daniel > > > > Thanks and Regards, > - Seung-Woo Kim > > > -- > Seung-Woo Kim > Samsung Software R&D Center > -- > > Thanks& Regards, Shirish S > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120823/33190edc/attachment.html>
[Bug 34212] radeon: 3650 AGP lockup on radeon.ko load
https://bugzilla.kernel.org/show_bug.cgi?id=34212 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution||OBSOLETE --- Comment #2 from Alan 2012-08-23 13:47:59 --- If this bug is still seen with modern kernels please update/reopen -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #20 from Michel D?nzer 2012-08-23 06:45:54 UTC --- (In reply to comment #19) > So about this locking piglit test (depthstencil-render-miplevels 146 > s=z24_s8_d=z32f_s8), I've been able to track it down to: > line 218: piglit_report_result(PIGLIT_SKIP); How did you determine that? It's weird, I wouldn't expect a skipped test to produce any actual GPU rendering. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 --- Comment #9 from Michel D?nzer 2012-08-23 06:28:27 --- (In reply to comment #8) > Updated the kernel to the latest revision which contains the patch and have > run > piglit test three time and no oops this time. So I'm closing as unreproducible > with latest code. The correct resolution would be FIXED, as it's a reproducible bug fixed by the patch. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #21 from Alexandre Demers 2012-08-23
13:13:25 UTC ---
(In reply to comment #20)
> (In reply to comment #19)
> > So about this locking piglit test (depthstencil-render-miplevels 146
> > s=z24_s8_d=z32f_s8), I've been able to track it down to:
> > line 218: piglit_report_result(PIGLIT_SKIP);
>
> How did you determine that? It's weird, I wouldn't expect a skipped test to
> produce any actual GPU rendering.
I used gdb and step into the code until it locked. It gets out at level 0,
after going through:
/**
* Attach the proper miplevel of each texture to the framebuffer
*/
void
set_up_framebuffer_for_miplevel(int level)...
Before this call, there is a framebuffer initialization:
GLuint fbo;
glGenFramebuffers(1, &fbo);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fbo);
glBindFramebuffer(GL_READ_FRAMEBUFFER, fbo);
for (int level = 0; level <= max_miplevel; ++level) {
set_up_framebuffer_for_miplevel(level);
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot
https://bugs.freedesktop.org/show_bug.cgi?id=42373 --- Comment #33 from Kunal 2012-08-23 04:58:33 UTC --- (In reply to comment #28) > (In reply to comment #27) > > (In reply to comment #26) > > > (In reply to comment #25) > > > > You might try the 5 patches starting with this one: > > > > http://lists.freedesktop.org/archives/dri-devel/2012-August/026498.html > > > > > > On top of previous patche(s) (by Jerome)? or as separate set? > > > > They apply on top of his patches. > > No luck :( > It's still the same after applying those patches and rebuilding the kernel. > > Attaching the xorg log and dmesg log after this. Anything more that I can try? Or something wrong that I did? Do these patches need any additional bits from 3.6 kernels? Asking since the Ubuntu Quantal series is based on 3.5 while these patches are all fairly new. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
RE: [PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
Florian Tobias Schandinat wrote: > > On 08/01/2012 02:28 AM, Kukjin Kim wrote: > > Leela Krishna Amudala wrote: > >> > >> This patchset moves the contents of regs-fb-v4.h and regs-fb.h from > arch > >> side > >> to include/video/samsung_fimd.h > >> > >> This patchset is created and rebased against master branch of torvalds > >> tree. > >> Tested on smdk5250 board, build tested for other boards. > >> > > (Cc'ed Florian Tobias Schandinat) > > > > Yeah, since it's merge window, this series could be created against on > > mainline. And IMO, would be helpful to us if this series could be sent > to > > upstream via samsung tree after reviewing, because this touches too many > > files in samsung tree and just adds include/video/samsung_fimd.h. But > I'm > > not sure the added inclusion will be used in other file of drivers/video. > If > > so, I can provide some topic branch can be merged into Florian's tree. > > Florian, how about? > > Using a topic branch to merge it in both trees sounds like a good plan > to me. > Florian, Please pull following topic branch we talked. I already merged it into my -next. git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.7-for-florian Note, I applied Leela's V4 patches not this V2 series. If any problems, please kindly let me know. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.7-for-florian Leela Krishna Amudala (2): include/video: move fimd register headers from platform to include/video include/video: Add register offsets for FIMD version 8 arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- .../plat/regs-fb.h => include/video/samsung_fimd.h | 152 +-- 26 files changed, 165 insertions(+), 194 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h => include/video/samsung_fimd.h (73%) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/5] Generic panel framework
Hi Laurent, Do you plan to add an API to get and parse EDID to mode list? video mode is tightly coupled with panel that is capable of hot-plug. Or you are busy on modifying EDID parsing code for sharing it amoung DRM/FB/etc? I see you mentioned this in Mar. It is great if you are considering add more info into video mode, such as pixel repeating, 3D timing related parameter. I have some code for CEA modes filtering and 3D parsing, but still tight coupled with FB and with a little hack style. My HDMI driver is implemented as lcd device as you mentioned here. But more complex than other lcd devices for a kthread is handling hot-plug/EDID/HDCP/ASoC etc. I also feel a little weird to add code parsing HDMI audio related info in fbmod.c in my current implementation, thought it is the only place to handle EDID in kernel. Your panel framework provide a better place to add panel related audio/HDCP code. panel notifier can also trigger hot-plug related feature, such as HDCP start. Looking forward to your hot-plug panel patch. Or I can help add it if you would like me to. Thanks! Jun ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41744] Unigine Heaven shows black textures (Radeon HD4250)
https://bugs.freedesktop.org/show_bug.cgi?id=41744 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from Andreas Boll 2012-08-23 11:26:44 UTC --- As mentioned above in Comment 5 and Comment 11 properly installing libtxc-dxtn library fixed the black textures. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #19 from Alexandre Demers 2012-08-23 04:12:52 UTC --- So about this locking piglit test (depthstencil-render-miplevels 146 s=z24_s8_d=z32f_s8), I've been able to track it down to: line 218: piglit_report_result(PIGLIT_SKIP); I don't know if we are supposed to be hitting this path, but either way, it seems piglit_report_result(PIGLIT_SKIP) locks. I suppose this function must be releasing resources before exiting, but something wrong is happening in there. By the way, I'm now running kernel 3.6.0-rc3 with latest drm and mesa. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH] drm: gma500: Kill the GEM glue layer
On Thu, 23 Aug 2012 12:03:59 +0200 Laurent Pinchart wrote: > Hi Alan, > > On Tuesday 17 July 2012 17:21:06 Alan Cox wrote: > > On Tue, 17 Jul 2012 17:09:25 +0200 Laurent Pinchart wrote: > > > On Wednesday 16 May 2012 16:10:37 Alan Cox wrote: > > > > On Wed, 16 May 2012 16:59:44 +0200 Laurent Pinchart wrote: > > > > > The private gem_create_mmap_offset() function is now > > > > > implemented in the DRM core as drm_gem_create_mmap_offset(). > > > > > Use it and kill the private copy. > > > > > > > > That was always then plan so yes - I'll fold this into my tree > > > > and test it. > > > > > > Any update ? > > > > Sorry it fell off the bottom of the job list. I'll do it right now > > so it doesn't escape > > I still can't find the patch in drm-next. Does it have a bad tendency > to fell off ? :-) I sent to Dave along with the mode setting fixes and DP/eDP support. None of them are yet in the tree but I've not re-sent again as Dave seemed to be busy to trying to mend the -rc tree. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm documentation
Hi Dave, The DRM documentation has been floating around for quite some time now. It's time to get it in mainline, otherwise it will start bit-rotting all alone (there's too little documentation written for the kernel, it would feel so lonely outside of Documentation/DocBook/). The following changes since commit 269b62db0e52bf2656aa762d61cfe67f3705fdff: Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel into drm-next (2012-08-23 15:12:44 +1000) are available in the git repository at: git://linuxtv.org/pinchartl/fbdev.git drm-doc Laurent Pinchart (1): Documentation: DocBook DRM framework documentation Documentation/DocBook/drm.tmpl | 2835 ++- -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] Miscellaneous mode set and page flip fixes
On Thursday 19 July 2012 13:55:37 Laurent Pinchart wrote: > On Thursday 31 May 2012 18:26:14 Laurent Pinchart wrote: > > Hi everybody, > > > > Here are two small fixes that disallow format changes in page flip > > operations, and perform a full mode set instead of a mode set base in the > > CRTC helper set config handler if the pixel format changed. > > Ping ? Can those two patches be applied ? Ping again ? > > Laurent Pinchart (2): > > drm: Don't allow page flip to change pixel format > > drm: Perform a full mode set when the pixel format changed > > > > drivers/gpu/drm/drm_crtc.c|8 > > drivers/gpu/drm/drm_crtc_helper.c |3 +++ > > 2 files changed, 11 insertions(+), 0 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: gma500: Kill the GEM glue layer
Hi Alan, On Tuesday 17 July 2012 17:21:06 Alan Cox wrote: > On Tue, 17 Jul 2012 17:09:25 +0200 Laurent Pinchart wrote: > > On Wednesday 16 May 2012 16:10:37 Alan Cox wrote: > > > On Wed, 16 May 2012 16:59:44 +0200 Laurent Pinchart wrote: > > > > The private gem_create_mmap_offset() function is now implemented > > > > in the DRM core as drm_gem_create_mmap_offset(). Use it and kill > > > > the private copy. > > > > > > That was always then plan so yes - I'll fold this into my tree and > > > test it. > > > > Any update ? > > Sorry it fell off the bottom of the job list. I'll do it right now so > it doesn't escape I still can't find the patch in drm-next. Does it have a bad tendency to fell off ? :-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: Update the MAX_EDID value for E-DDC
Hi Daniel, On 2012년 08월 23일 17:50, Daniel Vetter wrote: > On Wed, Aug 22, 2012 at 06:53:33PM +0530, Shirish S wrote: >> From: Shirish Shankarappa >> >> The value of MAX_EDID is now valid only for 2 >> block EDID data which is 256, but to support >> 4 block EDID (E-DDC) this needs to be 512. >> >> Signed-off-by: Shirish Shankarappa >> --- >> drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c >> b/drivers/gpu/drm/exynos/exynos_drm_connector.c >> index d956819..69d02b5 100644 >> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c >> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c >> @@ -32,7 +32,7 @@ >> #include "exynos_drm_drv.h" >> #include "exynos_drm_encoder.h" >> >> -#define MAX_EDID 256 >> +#define MAX_EDID 512 >> #define to_exynos_connector(x) container_of(x, struct >> exynos_drm_connector,\ >> drm_connector) > > Shouldn't this be in a common drm/edid header to begin with? This value is not real maximum length of EDID and it is only used for memory allocation by exynos connector. Actually, this allocation is unnecessary because edid is already allocated by drm_get_edid(). So, I have plan to remove this allocation and the definition once Jani Nikula's patches for removing raw_edid related memory leaks are applied. > -Daniel > Thanks and Regards, - Seung-Woo Kim -- Seung-Woo Kim Samsung Software R&D Center -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: Update the MAX_EDID value for E-DDC
On Wed, Aug 22, 2012 at 06:53:33PM +0530, Shirish S wrote: > From: Shirish Shankarappa > > The value of MAX_EDID is now valid only for 2 > block EDID data which is 256, but to support > 4 block EDID (E-DDC) this needs to be 512. > > Signed-off-by: Shirish Shankarappa > --- > drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c > b/drivers/gpu/drm/exynos/exynos_drm_connector.c > index d956819..69d02b5 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c > @@ -32,7 +32,7 @@ > #include "exynos_drm_drv.h" > #include "exynos_drm_encoder.h" > > -#define MAX_EDID 256 > +#define MAX_EDID 512 > #define to_exynos_connector(x) container_of(x, struct > exynos_drm_connector,\ > drm_connector) Shouldn't this be in a common drm/edid header to begin with? -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: edid: add support for E-DDC
On Wed, Aug 22, 2012 at 10:52:26AM +0300, Ville Syrjälä wrote: > On Tue, Aug 21, 2012 at 04:28:20PM -0700, Shirish S wrote: > > On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrjälä < > > ville.syrj...@linux.intel.com> wrote: > > > > > On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote: > > Here are my earlier comments on Jean's patch: > > > http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html > > > > > > > > If i am not wrong am doing exactly what you have said in you comments. > > > > This seems a bit wrong to me. The spec says that the ack for the > > segment address is "don't care", but for the segment pointer the ack is > > required (when segment != 0). > > The variable segFlags is "dont care for block 0 and 1 wheras". > > > > With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from a > > non E-DDC display, if we try to read segment != 0 from it. Of course > > we shouldn't do that unless the display lied to us about what extension > > blocks it provides. > > > > So I'm not sure if it would be better to trust that the display never > > lies about the extension blocks, or if we should just assume all E-DDC > > displays ack both segment addr and pointer. The no-ack feature seems > > to there for backwards compatibility, for cases where the host always > > sends the segment addr/pointer even when reading segment 0 (which your > > code doesn't do). > > > > To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split > > into two flags (one for addr, other for data). > > > > Hence i have split the i2c_msg into 3, segment pointer,offset(addr) > > and data pointer. > > I was referring to the addr and data phases of the segment pointer. > According to the spec the ack for the addr is always optional. But I > suppose no sane device would nak the addr, while acking the data. We've seen those. Really. Which is why the current i915 gmbus driver has a hack to never return a NaK on the first i2c transfer. I guess we should fix this by properly supporting the INGNORE_NAK field in our gmbus driver, and setting that on the addr transfer field, too. I concure with Ville that sending the segment i2c message only when we actually need it, and not unconditionally. DDC is way to broken and claiming that the spec says otherwise doesn't fix all the existing bad hw. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1
On Thu, Aug 23, 2012 at 08:56:37AM +0100, Chris Wilson wrote: > On Wed, 22 Aug 2012 16:40:57 -0700, Tejun Heo wrote: > > This is an equivalent conversion and will ease scheduled removal of > > WQ_NON_REENTRANT. > > > > Signed-off-by: Tejun Heo > Reviewed-by: Chris Wilson Acked-by: Daniel Vetter for merging through any tree that pleases you (if it makes merging easier for WQ_NON_REENTRANT removal). Or should I just merge this through drm-intel-next? -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 18/26] v4l: add buffer exporting via dmabuf
Hi Hans,
On Wednesday 22 August 2012 13:41:05 Hans Verkuil wrote:
> On Tue August 14 2012 17:34:48 Tomasz Stanislawski wrote:
> > This patch adds extension to V4L2 api. It allow to export a mmap buffer as
> > file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer
> > offset used by mmap and return a file descriptor on success.
> >
> > Signed-off-by: Tomasz Stanislawski
> > Signed-off-by: Kyungmin Park
[snip]
> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > index 7f918dc..b5d058b 100644
> > --- a/include/linux/videodev2.h
> > +++ b/include/linux/videodev2.h
> > @@ -688,6 +688,31 @@ struct v4l2_buffer {
> >
> > #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
> > #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
> >
> > +/**
> > + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> > descriptor + *
> > + * @fd:file descriptor associated with DMABUF (set by driver)
> > + * @mem_offset:buffer memory offset as returned by VIDIOC_QUERYBUF in
> > struct + * v4l2_buffer::m.offset (for single-plane formats) or
> > + * v4l2_plane::m.offset (for multi-planar formats)
> > + * @flags: flags for newly created file, currently only O_CLOEXEC is
> > + * supported, refer to manual of open syscall for more details
> > + *
> > + * Contains data used for exporting a video buffer as DMABUF file
> > descriptor. + * The buffer is identified by a 'cookie' returned by
> > VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer to
> > userspace). All + * reserved fields must be set to zero. The field
> > reserved0 is expected to + * become a structure 'type' allowing an
> > alternative layout of the structure + * content. Therefore this field
> > should not be used for any other extensions. + */
> > +struct v4l2_exportbuffer {
> > + __u32 fd;
> > + __u32 reserved0;
> > + __u32 mem_offset;
> > + __u32 flags;
> > + __u32 reserved[12];
> > +};
>
> OK, I realized that we also need a type field here: you need the type field
> (same as in v4l2_buffer) to know which queue the mem_offset refers to. For
> M2M devices you have two queues, so you need this information.
>
> Is there any reason not to use __u32 memory instead of __u32 reserved0?
> I really dislike 'reserved0'. It's also very inconsistent with the other
> buffer ioctls which all have type+memory fields.
I'm concerned that we might need to export buffers in the future based on
something else than the memory type. That's probably an irrational fear
though.
> Regarding mem_offset: I would prefer a union (possibly anonymous):
>
> union {
> __u32 mem_offset;
> unsigned long reserved;
> } m;
>
> Again, it's more consistent with the existing buffer ioctls, and it prepares
> the API for future pointer values. 'reserved' in the union above could even
> safely be renamed to userptr, even though userptr isn't supported at the
> moment.
Once again I would really want to see compeling use cases before we export a
userptr buffer as a dmabuf object. As Mauro previously stated, userptr for
buffer sharing was a hack in the first place (although a pretty successful one
so far).
--
Regards,
Laurent Pinchart
Re: [PATCH] i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1
On Wed, 22 Aug 2012 16:40:57 -0700, Tejun Heo wrote: > This is an equivalent conversion and will ease scheduled removal of > WQ_NON_REENTRANT. > > Signed-off-by: Tejun Heo Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
