On 30 July 2014 07:32, Daniel Vetter wrote:
> Somehow we've forgotten about this little bit of OCD.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_crtc.c | 8 ++--
> drivers/gpu/drm/drm_modeset_lock.c | 84
> ++
> include/drm/drm_crtc.h | 6 +++
> include/drm/drm_modeset_lock.h | 5 +++
> 4 files changed, 99 insertions(+), 4 deletions(-)
>
> diff --gi
On 30 July 2014 07:32, Daniel Vetter wrote:
> Atomic implemenations for legacy ioctls must be able to drop locks.
> Which doesn't cause havoc since we only do that while constructing
> the new state, so no driver or hardware state change has happened.
>
> The only troubling bit is the fb refcounti
On 28 July 2014 18:37, Benjamin Gaignard
wrote:
> Hello Dave,
>
> You can found the patcheset with Rob's reviewed-by tag here:
> git://git.linaro.org/people/benjamin.gaignard/kernel.git
> on drm_kms_for_next-v7 branch
>
> It is the same code (drm_kms_for_next-v6) than what Rob has reviewed,
> reb
On 30.07.2014 06:32, Daniel Vetter wrote:
> As usual in both a crtc index and a struct drm_crtc * version.
>
> The function assumes that no one drivers their display below 10Hz, and
> it will complain if the vblank wait takes longer than that.
>
> v2: Also check dev->max_vblank_counter since some
On 30.07.2014 02:10, Jerome Glisse wrote:
> On Tue, Jul 29, 2014 at 01:05:15PM -0400, Alex Deucher wrote:
>> On Tue, Jul 29, 2014 at 11:39 AM, Jerome Glisse
>> wrote:
>>> On Tue, Jul 29, 2014 at 10:33:18AM -0400, Alex Deucher wrote:
Return 2 so we can be sure the kernel has the necessary
>>>
ke "FAILED (get_hash[0](0))".
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/f94701c9/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/4d84b937/attachment.html>
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/bcab3506/attachment-0001.html>
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/bc87bfa1/attachment.html>
Hi Andreas,
On Tue, Jul 29, 2014 at 4:51 PM, Andreas F?rber wrote:
> Hi Ajay,
>
> Am 28.07.2014 08:13, schrieb Ajay kumar:
>> On 7/27/14, Andreas F?rber wrote:
>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.k
Hi Thierry,
On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding
wrote:
> On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas F?rber wrote:
>> Am 29.07.2014 13:36, schrieb Thierry Reding:
>> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas F?rber wrote:
>> >> Hi Ajay,
>> >>
>> >> Am 28.07.2014 08:13,
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/b4b25cb2/attachment.html>
Hi Andreas,
On Tue, Jul 29, 2014 at 4:59 PM, Andreas F?rber wrote:
> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>> From: Vincent Palatin
>>
>> This patch adds drm_bridge driver for parade DisplayPort
>> to LVDS bridge chip.
>>
>> Signed-off-by: Vincent Palatin
>> Signed-off-by: Andrew Bresticker
up
Linaro.org <http://www.linaro.org/> *? *Open source software for ARM SoCs
Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter
<http://twitter.com/#!/linaroorg> | Blog
<http://www.linaro.org/linaro-blog/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/d0179dd2/attachment-0001.html>
On Tue, Jul 29, 2014 at 04:46:11PM -0700, Matt Roper wrote:
> On Tue, Jul 29, 2014 at 11:32:19PM +0200, Daniel Vetter wrote:
> > Atomic implemenations for legacy ioctls must be able to drop locks.
> > Which doesn't cause havoc since we only do that while constructing
> > the new state, so no driver
On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel D?nzer wrote:
> On 30.07.2014 06:32, Daniel Vetter wrote:
> > As usual in both a crtc index and a struct drm_crtc * version.
> >
> > The function assumes that no one drivers their display below 10Hz, and
> > it will complain if the vblank wait takes
In the atomic state we'll have an array of states for crtcs, planes
and connectors and need to be able to at them by their index. We
already have a drm_crtc_index function so add the missing ones for
planes and connectors.
If it later on turns out that the list walking is too expensive we can
add
On 30.07.2014 17:22, Daniel Vetter wrote:
> On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel D?nzer wrote:
>> On 30.07.2014 06:32, Daniel Vetter wrote:
>>> + * due to lack of driver support or because the crtc is off.
>>> + */
>>> +void drm_crtc_vblank_wait(struct drm_crtc *crtc)
>>> +{
>>> + drm
So drivers using the atomic interfaces expect that they can acquire
additional locks internal to the driver as-needed. Examples would be
locks to protect shared state like shared display PLLs.
Unfortunately the legacy ioctls assume that all locking is fully done
by the drm core. Now for those path
Atomic implemenations for legacy ioctls must be able to drop locks.
Which doesn't cause havoc since we only do that while constructing
the new state, so no driver or hardware state change has happened.
The only troubling bit is the fb refcounting the core does - if
someone else has snuck in then i
code_size = 4160, config = 0x7fffb9e33840 "(\260", config_size = 24,
rodata = 0x0, rodata_size = 0, disassembled = 0}
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.
Version|git |unspecified
Component|Drivers/Gallium/radeonsi|DRM/Radeon
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attach
ou are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/416432eb/attachment.html>
As usual in both a crtc index and a struct drm_crtc * version.
The function assumes that no one drivers their display below 10Hz, and
it will complain if the vblank wait takes longer than that.
v2: Also check dev->max_vblank_counter since some drivers register a
fake get_vblank_counter function.
This has the upside that it will no longer steal interrupts from the
interrutp handler on pre-g4x. Furthermore this will now scream properly
on all platforms if we don't have hw counters enabled.
v2: Adjust to the new names.
Cc: Ville Syrj?l?
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i9
Using -export-symbols-regex all private symbols are hidden, resulting in the
following changes:
libkms: removes all driver specific exports
radeon: removes the bof_* exports
nouveau: removes the abi16_* exports
freedreno: remove the *kgsl_* and msm_* exports
intel: removes the drm_mm* exports
oma
es sense.
> On snow, the bridge chip provides the display mode instead of the panel.
> That is why display was working for me.
Okay, I suppose under some circumstances that might make sense. Although
it's still always the panel that dictates the display timings, so the
panel node needs to have a panel model specific compatible value with a
matching entry in the panel-simple driver so that it can even be used in
setups without a bridge.
One other thing: how does the bridge know which mode to drive? I suspect
that it can drive more than one mode? Can it freely be configured or
does it have a predefined set of modes? If the latter, then according to
what you said above there needs to be a way to configure the bridge (via
DT?) so that it reports the mode matching the panel. I wonder if that
should be handled completely in code, so that for example a bridge has a
panel attached it can use the panel's .get_modes() and select a matching
mode among the set that it supports.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/174b58b8/attachment-0001.sig>
On 30.07.2014 18:25, Daniel Vetter wrote:
> As usual in both a crtc index and a struct drm_crtc * version.
>
> The function assumes that no one drivers their display below 10Hz, and
> it will complain if the vblank wait takes longer than that.
>
> v2: Also check dev->max_vblank_counter since some
not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/0f3425a6/attachment.sig>
Do you have any objections to that?
Thierry
-- next part ------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/f4efc330/attachment.sig>
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/7955fe36/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/e854a19e/attachment.html>
[CCing Emil as well]
Am 30.07.2014 um 11:38 schrieb Maarten Lankhorst:
> Using -export-symbols-regex all private symbols are hidden, resulting in the
> following changes:
Wasn't "-export-symbols-regex" exactly that stuff we are trying to avoid
in mesa?
Christian.
>
> libkms: removes all drive
On Wed, Jul 30, 2014 at 3:10 PM, Thierry Reding
wrote:
> On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
>> Hi Thierry,
>>
>> On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding
>> wrote:
>> > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas F?rber wrote:
>> >> Am 29.07.2014 13:36, schri
On Wed, Jul 30, 2014 at 3:30 PM, Thierry Reding
wrote:
> On Sat, Jul 26, 2014 at 12:52:03AM +0530, Ajay Kumar wrote:
>> Most of the panels need an init sequence as mentioned below:
>> -- poweron LCD unit/LCD_EN
>> -- start video data
>> -- poweron LED unit/BACKLIGHT_EN
>> And, a
drm_panel_prepare(panel);
tegra_output_enable(output);
drm_panel_enable(panel);
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/dde02898/attachment.sig>
I have push two additional patches on drm_kms_for_next-v7 branch to
make the driver build as a module:
- "gpu: drm: export drm_sysfs_connector_{add,remove} function"
- "drm: sti: Allow driver to be built as module"
I have tested the both configuration (built-in and module), it is ok
on my hardware
tage_delay = 105,
> + .enable_stage_delay = 20,
> + .prepare_stage_delay = 50,
I take it that this last one was supposed to be .enable_stage_delay
since you've already set up .prepare_stage_delay.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/165fe510/attachment-0001.sig>
rroting what the
code does.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/38b847c8/attachment.sig>
of the remainder of the file, but it
looks good to me otherwise.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/648d43b6/attachment.sig>
On Wed, Jul 30, 2014 at 4:02 PM, Thierry Reding
wrote:
> On Sat, Jul 26, 2014 at 12:52:04AM +0530, Ajay Kumar wrote:
>> Now that we have 2 new callbacks(prepare and unprepare) for drm_panel,
>> make changes in all the drm drivers which use the drm_panel framework
>> to support the new callbacks.
>
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/a564f317/attachment.html>
* @funcs: control functions
> * @driver_private: pointer to the bridge driver's internal context
> + * @connector_polled: polled flag needed for registering connector
Can you explain why this new field is needed? It seems like a completely
unrelated change.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/fa81f6d7/attachment-0001.sig>
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/5be8ad72/attachment.html>
On Wed, Jul 30, 2014 at 4:21 PM, Thierry Reding
wrote:
> On Sat, Jul 26, 2014 at 12:52:05AM +0530, Ajay Kumar wrote:
>> Add panel_desc structure for auo_b133htn01 eDP panel.
>>
>> Also, modify the panel_simple routines to support timing_parameter
>> delays if mentioned in the panel_desc structure.
So when reviewing Michel's patch I've noticed a few things and cleaned
them up:
- The early checks in ppgtt_release are now redundant: The inactive
list should always be empty now, so we can ditch these checks. Even
for the aliasing ppgtt (though that's a different confusion) since
we tear th
; + {"nxp,ptn3460", 0},
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, ptn3460_i2c_table);
> +
> +static const struct of_device_id ptn3460_match[] = {
> + { .compatible = "nxp,ptn3460" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ptn3460_match);
> +
> +struct i2c_driver ptn3460_driver = {
Is there a reason why this can't be static?
> + .id_table = ptn3460_i2c_table,
> + .probe = ptn3460_probe,
> + .remove = ptn3460_remove,
> + .driver = {
> + .name = "nxp,ptn3460",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(ptn3460_match),
You don't need of_match_ptr() here since you already depend on OF in
Kconfig, therefore of_match_ptr(x) will always evaluate to x.
> + },
> +};
> +module_i2c_driver(ptn3460_driver);
> +
> +MODULE_AUTHOR("Sean Paul ");
> +MODULE_DESCRIPTION("NXP ptn3460 eDP-LVDS converter driver");
> +MODULE_LICENSE("GPL");
This should be "GPL v2".
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/1344217a/attachment-0001.sig>
On Wed, Jul 30, 2014 at 4:22 PM, Thierry Reding
wrote:
> On Sat, Jul 26, 2014 at 12:52:06AM +0530, Ajay Kumar wrote:
>> This patch moves the DP training and video enable from the hotplug
>> handler into commit().
>
> I don't think I can comment on this one, but perhaps the commit message
> should
On 27/07/14 14:15, Oded Gabbay wrote:
> On 21/07/14 01:37, Jerome Glisse wrote:
>> On Thu, Jul 17, 2014 at 04:29:17PM +0300, Oded Gabbay wrote:
>>> From: Evgeny Pinchuk
>>>
>>> This patch adds the topology module to the driver. The topology is exposed
>>> to
>>> userspace through the sysfs.
>>>
>
https://bugzilla.kernel.org/show_bug.cgi?id=81021
--- Comment #4 from LiNuxXer ---
(In reply to Alex Deucher from comment #2)
> You can enable it by setting pi->enable_bapm = true; in trinity_dpm_init()
> in trinity_dpm.c. Unforunately, it's not stable yet on all systems.
Thank you for this hin
https://bugzilla.kernel.org/show_bug.cgi?id=81021
--- Comment #5 from LiNuxXer ---
(In reply to Kertesz Laszlo from comment #3)
> This issue isnt new, i filed a bug about it ages ago ( #62861 ). As Alex
> said, turbo core can be enabled by setting bapm to true.
I cannot see any relation between
On 30/07/14 11:16, Christian K?nig wrote:
> [CCing Emil as well]
>
> Am 30.07.2014 um 11:38 schrieb Maarten Lankhorst:
>> Using -export-symbols-regex all private symbols are hidden, resulting in the
>> following changes:
>
> Wasn't "-export-symbols-regex" exactly that stuff we are trying to avoid
On Wed, Jun 18, 2014 at 10:51:28AM +0200, Benjamin Gaignard wrote:
> Make the link between all the hardware drivers and DRM/KMS interface.
> Create the driver itself and make it register all the sub-components.
> Use GEM CMA helpers for buffer allocation.
>
> Signed-off-by: Benjamin Gaignard
> --
On Wed, Jul 30, 2014 at 12:43:33PM +0200, Benjamin Gaignard wrote:
> I have push two additional patches on drm_kms_for_next-v7 branch to
> make the driver build as a module:
> - "gpu: drm: export drm_sysfs_connector_{add,remove} function"
Nope, you're using the wrong functions. Instead you should
o set the
initial state. It looks like you're not doing that here, but it might be
better to still set this to reflect what the initial state should be.
I'm assuming you want it disabled to avoid visual glitches when you turn
on the display. Of course if the bootloader already turned it on and
initialized the display, then you'll get flickering... but I guess
that's a problem to solve another day.
> + }
> +
> + i2c_set_clientdata(client, ps_bridge);
> +
> + drm_bridge_add_for_lookup(bridge);
> +
> + return 0;
> +
> +err_client:
> + DRM_ERROR("device probe failed : %d\n", ret);
No need for this. The driver core typically tells you already.
> +static int ps8622_remove(struct i2c_client *client)
> +{
> + struct ps8622_bridge *ps_bridge = i2c_get_clientdata(client);
> +
> + if (ps_bridge->bl)
> + backlight_device_unregister(ps_bridge->bl);
> +
> + return 0;
> +}
You'll also want to call drm_bridge_remove() here.
> +static const struct i2c_device_id ps8622_i2c_table[] = {
> + {"parade", 0},
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, ps8622_i2c_table);
This table doesn't look right. Shouldn't that be:
{ "ps8622", 0 },
{ "ps8625", 0 },
? And perhaps use the .driver_data field to refer to the device data
like for the of_device_id table?
> +struct i2c_driver ps8622_driver = {
> + .id_table = ps8622_i2c_table,
> + .probe = ps8622_probe,
> + .remove = ps8622_remove,
> + .driver = {
> + .name = "parade",
That's an awfully generic name. I'd suggest "ps8622".
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(ps8622_devices),
As for ptn3460, this has a hard dependency on OF, so of_match_ptr()
isn't useful.
> + },
> +};
> +module_i2c_driver(ps8622_driver);
> +
> +MODULE_AUTHOR("Vincent Palatin ");
> +MODULE_DESCRIPTION("Parade ps8622 eDP-LVDS converter driver");
> +MODULE_LICENSE("GPL");
"GPL v2"
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/e29f16b4/attachment-0001.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=81391
Bug ID: 81391
Summary: nouveau E[ PFIFO][:01:00.0] read fault at
0x20f000 [PTE] from BAR1/HOST_CPU on channel
0x00ffbdf000 [unknown]
Product: Drivers
Ver
https://bugzilla.kernel.org/show_bug.cgi?id=81391
--- Comment #1 from Srihari Vijayaraghavan
---
Created attachment 144741
--> https://bugzilla.kernel.org/attachment.cgi?id=144741&action=edit
lspci & .config
--
You are receiving this mail because:
You are watching the assignee of the bug.
e the panel's .get_modes() and select a matching
> > mode among the set that it supports.
> ptn3460 supports a standard list of "edid-emulation" ids.
> As of now, we receive that as a DT entry.
> And, these are the list of emulation ids supported:
>
> | Value | Resolution | Description
> | 0 | 1024x768 | NXP Generic
> | 1 | 1920x1080 | NXP Generic
> | 2 | 1920x1080 | NXP Generic
> | 3 | 1600x900 | Samsung LTM200KT
> | 4 | 1920x1080 | Samsung LTM230HT
> | 5 | 1366x768 | NXP Generic
> | 6 | 1600x900 | ChiMei M215HGE
>
> As you can see, the same resolutions have different emulator ids.
> May be, it depends on panel vendor also. I am really not sure if we can do
> this.
> For snow(which has 1366x768 panel), we set edid-emulation as 5.
Well, modes 1, 2 and 4 as well as modes 3 and 6 must differ in some
ways, otherwise there wouldn't be much point in using different IDs for
them. You could try to match on more than just the active horizontal and
vertical resolution.
The reason behind this is that it would allow us to keep the device tree
content to a minimum and determine the proper emulation ID at runtime.
But if it's too difficult to implement I won't object to keeping the
edid-emulation property in DT. It just means that the device tree will
contain some duplicate information that needs to be kept in sync.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/f41cba76/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=81391
--- Comment #2 from Srihari Vijayaraghavan
---
Actually, seeing how the flooding hasn't stopped, I've rebooted it to Intel
4600 video chip, disabling GTX 860m in the BIOS/firmware. However, I'm happy to
re-enable it and test any patch, if you wan
https://bugzilla.kernel.org/show_bug.cgi?id=81021
--- Comment #6 from Alex Deucher ---
(In reply to LiNuxXer from comment #5)
>
> This bug report here is about Linux not supporting Turbo Core on APUs when
> no specific graphics driver is used.
>
> In other words, I'm raising the question whethe
repare_stage_delay = 50.
> This is needed because panels need some delay before powering
> them on again.
> As in, assume you are doing a test to turn on/off display continuously,
> Then, the delay between
> (N - 1)th cycle poweroff to Nth cycle poweron should be at least 500ms.
> Tha
Bunch of small leftovers spotted by looking at the make htmldocs output.
I've left out dp mst, there's too much amiss there.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 5 +++--
drivers/gpu/drm/drm_edid.c | 2 +-
drivers/gpu/drm/drm_modeset_lock.c | 2 +-
3 fil
https://bugzilla.kernel.org/show_bug.cgi?id=80331
--- Comment #13 from Alex Deucher ---
You need to compile the firmware into your kernel when you build the driver
into the kernel. In both of your static builds, the firmware fails to load:
static-with-patch:
[0.263616] r600_cp: Failed to lo
On Wed, Jul 30, 2014 at 7:00 PM, Thierry Reding
wrote:
> On Wed, Jul 30, 2014 at 05:02:11PM +0530, Ajay kumar wrote:
>> On Wed, Jul 30, 2014 at 4:21 PM, Thierry Reding
>> wrote:
>> > On Sat, Jul 26, 2014 at 12:52:05AM +0530, Ajay Kumar wrote:
>> >> Add panel_desc structure for auo_b133htn01 eDP p
so they
stay at their low levels.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/bfe09d2c/attachment.html>
From: Thierry Reding
Checks whether or not the compiler supports the -fvisibility option. If
so it sets the VISIBILITY_CFLAGS variable which can be added to the per
directory AM_CFLAGS where appropriate.
By default all symbols will be hidden via the VISIBILITY_CFLAGS. The
drm_public macro can be
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/57660235/attachment-0001.html>
mes yesterday)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/e8d75ffa/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=80331
--- Comment #14 from Colin ---
(In reply to Alex Deucher from comment #13)
> You need to compile the firmware into your kernel when you build the driver
> into the kernel. In both of your static builds, the firmware fails to load:
>
> static-wit
the
loop...
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/a146f023/attachment.sig>
pe: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/6bf4cba1/attachment.sig>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/fce86a58/attachment.html>
ow why this occurs,
otherwise I'll have to swap this card for production out
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachment
On Wed, Jul 30, 2014 at 9:48 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Checks whether or not the compiler supports the -fvisibility option. If
> so it sets the VISIBILITY_CFLAGS variable which can be added to the per
> directory AM_CFLAGS where appropriate.
>
> By default all symbols w
On Wed, Jul 30, 2014 at 4:49 PM, Thierry Reding
wrote:
> On Sat, Jul 26, 2014 at 12:52:08AM +0530, Ajay Kumar wrote:
>> This patch tries to seperate drm_bridge implementation
>> into 2 parts, a drm part and a non_drm part.
>>
>> A set of helper functions are defined in this patch to make
>> bridge
On 30/07/14 14:48, Thierry Reding wrote:
> From: Thierry Reding
>
> Checks whether or not the compiler supports the -fvisibility option. If
> so it sets the VISIBILITY_CFLAGS variable which can be added to the per
> directory AM_CFLAGS where appropriate.
>
> By default all symbols will be hidden
dize on common APIs rather than per-driver
implementations, I'm good.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/2d8b56ec/attachment.sig>
On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
> On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel D?nzer wrote:
> > On 30.07.2014 17:22, Daniel Vetter wrote:
> > > On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel D?nzer wrote:
> > >> On 30.07.2014 06:32, Daniel Vetter wrote:
> > >>
On 30/07/14 15:31, Rob Clark wrote:
> On Wed, Jul 30, 2014 at 9:48 AM, Thierry Reding
> wrote:
>> From: Thierry Reding
>>
>> Checks whether or not the compiler supports the -fvisibility option. If
>> so it sets the VISIBILITY_CFLAGS variable which can be added to the per
>> directory AM_CFLAGS wh
On Wed, Jul 30, 2014 at 10:37 AM, Emil Velikov
wrote:
> On 30/07/14 15:31, Rob Clark wrote:
>> On Wed, Jul 30, 2014 at 9:48 AM, Thierry Reding
>> wrote:
>>> From: Thierry Reding
>>>
>>> Checks whether or not the compiler supports the -fvisibility option. If
>>> so it sets the VISIBILITY_CFLAGS
https://bugzilla.kernel.org/show_bug.cgi?id=80331
--- Comment #15 from Alex Deucher ---
(In reply to Colin from comment #14)
>
> Thanks I'll give it a go when I home from work tonight. I am sure that will
> be the solution. Strange thing is that even with the firmware not loaded the
> card works
ng this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/56a72d5b/attachment.html>
ri-devel/attachments/20140730/2ee5766a/attachment.html>
On Wed, Jul 30, 2014 at 04:24:06PM +0200, Thierry Reding wrote:
> On Tue, Jul 29, 2014 at 11:32:22PM +0200, Daniel Vetter wrote:
> [...]
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> [...]
> > + ret = wait_event_timeout(dev->vblank[crtc].queue,
> > +
On Wed, Jul 30, 2014 at 05:36:21PM +0300, Ville Syrj?l? wrote:
> On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
> > On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel D?nzer wrote:
> > > On 30.07.2014 17:22, Daniel Vetter wrote:
> > > > On Wed, Jul 30, 2014 at 11:59:33AM +0900, Miche
d field, can't it?
It seems like the only reason you have it in drm_bridge is so that the
encoder driver can set it. But I don't see why it should be doing that.
The polled state is a property of the connector, and the encoder driver
doesn't know anything about it. So if the bridge has a way to detect HPD
then it should be setting up the connector to properly report it. For
example if the bridge has an input pin to detect it, then it could use a
GPIO to receive interrupts and call drm_helper_hpd_irq_event() in the
interrupt handler.
Perhaps you can explain the exact setup where you need this (or point me
at the code since I can't seem to find the relevant location) so that I
can gain a better understanding.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/7cb87ee5/attachment.sig>
erry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/ca7a2aa6/attachment.sig>
On Wed, Jul 30, 2014 at 5:35 PM, Thierry Reding
wrote:
> On Sat, Jul 26, 2014 at 12:52:09AM +0530, Ajay Kumar wrote:
> [...]
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index 1e2f96c..0b12d16 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu
From: Christian K?nig
Seems to make VM flushes more stable on SI and CIK.
v2: only use the PFP on the GFX ring on CIK
Signed-off-by: Christian K?nig
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c | 5 +++--
drivers/gpu/drm/radeon/si.c | 2 +-
2 files changed, 4 insertions(+),
ret = wait_event_timeout(...,
drm_vblank_count(dev, crtc) == target,
...);
That should properly take into account wrap-around given that both sites
use drm_vblank_count().
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/80a0d01c/attachment.sig>
it would become impossible to choose the
correct one. So only the final bridge in the chain should instantiate
the connector.
.get_modes() still needs to be done from the bridge because that is the
most closely connected to the display controller and therefore dictates
the timing that the display controller needs to generate.
Querying the panel's .get_modes() might be useful to figure out which
emulation mode to use in the bridge.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/09654a11/attachment.sig>
On Wed, Jul 30, 2014 at 11:18 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Seems to make VM flushes more stable on SI and CIK.
>
> v2: only use the PFP on the GFX ring on CIK
>
> Signed-off-by: Christian K?nig
> Cc: stable at vger.kernel.org
Applied to my 3.17 tree. We should use PFP
On Tue, Jul 29, 2014 at 11:32:20PM +0200, Daniel Vetter wrote:
> In the fbdev code we want to do trylocks only to avoid deadlocks and
> other ugly issues. Thus far we've only grabbed the overall modeset
> lock, but that already failed to exclude a pile of potential
> concurrent operations. With pro
On Wed, Jul 30, 2014 at 8:38 PM, Thierry Reding
wrote:
> On Wed, Jul 30, 2014 at 08:01:44PM +0530, Ajay kumar wrote:
>> On Wed, Jul 30, 2014 at 4:49 PM, Thierry Reding
>> wrote:
>> > On Sat, Jul 26, 2014 at 12:52:08AM +0530, Ajay Kumar wrote:
>> >> This patch tries to seperate drm_bridge implemen
On Wed, Jul 30, 2014 at 08:56:07AM -0700, Matt Roper wrote:
> On Tue, Jul 29, 2014 at 11:32:20PM +0200, Daniel Vetter wrote:
> > In the fbdev code we want to do trylocks only to avoid deadlocks and
> > other ugly issues. Thus far we've only grabbed the overall modeset
> > lock, but that already fai
On Wed, Jul 30, 2014 at 9:10 PM, Thierry Reding
wrote:
> On Wed, Jul 30, 2014 at 08:46:44PM +0530, Ajay kumar wrote:
>> On Wed, Jul 30, 2014 at 5:35 PM, Thierry Reding > gmail.com> wrote:
>> > On Sat, Jul 26, 2014 at 12:52:09AM +0530, Ajay Kumar wrote:
> [...]
>> >> +int ptn3460_post_encoder_init(
..
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/70642711/attachment-0001.html>
lications).
The latest ddx patch is on the mailing list:
http://lists.x.org/archives/xorg-driver-ati/2014-July/026517.html
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/7ab05044/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140730/00f37a74/attachment.html>
1 - 100 of 149 matches
Mail list logo
