next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160720/074ad49d/attachment.html>
Allow user add display timing on device tree with simple-panel-dsi
or simple-panel.
Cc: Thierry Reding
Cc: Rob Herring
Cc: Mark Rutland
Signed-off-by: Mark Yao
---
.../bindings/display/panel/simple-panel.txt| 48 ++
1 file changed, 48 insertions(+)
diff --git a/D
We want add display support on loader, share the same timing
with kernel side, but the timing is hide into kernel code,
can't be share, avoid config twice display timing, add device-tree
display timing support would be good idea.
With this patch, loader and kernel can share same timing from
device
op.org/archives/dri-devel/attachments/20160720/82c5a10b/attachment.html>
__
You are receiving this mail because:
* You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160720/04819113/attachment-0001.html>
This is MT8173 HDMI 4K support PATCH, based on 4.7-rc1.
In order to support HDMI 4K on MT8173,
we have to make some modifications.
1) Make sure that mtk_hdmi_send_infoframe is sent successfully.
2) Enhance the HDMI driving current to improve performance.
3) Make sure that pixel clock is 297MHz whe
From: Junzhi Zhao
Pixel clock should be 297MHz when resolution is 4K.
Signed-off-by: Junzhi Zhao
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 184 +---
1 file changed, 131 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/medi
From: Junzhi Zhao
In order to improve 4K resolution performance,
we have to enhance the HDMI driving currend
when clock rate is greater than 165MHz.
Signed-off-by: Junzhi Zhao
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 89 +---
1 file
From: Junzhi Zhao
The mtk_hdmi_send_infoframe have to
be run after PLL and PIXEL clock of HDMI enable.
Make sure that HDMI inforframes can be sent
successfully.
Signed-off-by: Junzhi Zhao
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 19 ---
1 file cha
if MT8173 display module can support 4K HDMI output,
we have to adjust VENCPLL clock from default 660MHz
to 800MHz.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c |9 +
drivers/gpu/drm/mediatek/mtk_drm_drv.h |1 +
2 files changed, 10 insertions(+)
diff --g
Hi, YT:
Some comments inline.
On Fri, 2016-07-15 at 18:07 +0800, YT Shen wrote:
> From: shaoming chen
>
> add dsi read/write commands for transfer function
>
> Signed-off-by: shaoming chen
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 322
>
> 1 file cha
Hi, YT:
Some comments inline.
On Fri, 2016-07-15 at 18:07 +0800, YT Shen wrote:
> From: shaoming chen
>
> add dsi and mipi tx driver for mipi panel support
>
> Signed-off-by: shaoming chen
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 169
> ++--
> drivers/gp
Hi, YT:
Some comments inline.
On Fri, 2016-07-15 at 18:07 +0800, YT Shen wrote:
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701.
>
> Signed-off-by: YT Shen
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c |6
> drivers/gpu/d
Hi, Bibby:
One comment inline.
On Wed, 2016-07-20 at 12:03 +0800, Bibby Hsieh wrote:
> From: Junzhi Zhao
>
> In order to improve 4K resolution performance,
> we have to enhance the HDMI driving currend
> when clock rate is greater than 165MHz.
>
> Signed-off-by: Junzhi Zhao
> Signed-off-by: B
Hi, Bibby:
Some comments inline.
On Wed, 2016-07-20 at 12:03 +0800, Bibby Hsieh wrote:
> From: Junzhi Zhao
>
> Pixel clock should be 297MHz when resolution is 4K.
>
> Signed-off-by: Junzhi Zhao
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 184
> +++
ts.freedesktop.org/archives/dri-devel/attachments/20160720/efa020b7/attachment.html>
.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160720/f4223116/attachment.html>
Replace clk_disable and clk_unprepare with clk_disable_unprepare.
The Coccinelle semantic patch used to make this change is as follows:
@@
expression e;
@@
- clk_disable(e);
- clk_unprepare(e);
+ clk_disable_unprepare(e);
Signed-off-by: Amitoj Kaur Chawla
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_dr
Am Mittwoch, den 20.07.2016, 12:03 +0800 schrieb Bibby Hsieh:
> From: Junzhi Zhao
>
> Pixel clock should be 297MHz when resolution is 4K.
>
> Signed-off-by: Junzhi Zhao
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 184
> +---
> 1
Hi Bibby,
Am Mittwoch, den 20.07.2016, 12:03 +0800 schrieb Bibby Hsieh:
> if MT8173 display module can support 4K HDMI output,
> we have to adjust VENCPLL clock from default 660MHz
> to 800MHz.
Is vencpll(_d2) the active source for the mm_sel mux? If so, it seems to
me that mm_sel or rather one o
Hi,
This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.
Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any initialisation. The only thing
needed is to get the timings from the scree
Our RGB bus can be either connected to a bridge or a panel. While the panel
support was already there, the bridge was not.
Fix that.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 4 +--
drivers/gpu/drm/sun4i/sun4i_rgb.c | 58 +-
driv
Now that we have support for the VGA bridges using our DRM driver, enable
the display engine for the Olimex A13-Olinuxino.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 60 +++
1 file changed, 60 insertions(+)
diff --git a/arch/arm/boot
We will need to access TCON's struct device from outside of TCON's driver
bind function. Store it in our private structure.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 1 +
drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/
In order to properly support bridges and use drm_encoder's bridge pointer,
move the panel (and bridge eventually) retrieval code in the RGB output
init function.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 10 ++
drivers/gpu/drm/sun4i/sun4i_tcon.c | 8 +---
Some boards have an entirely passive RGB to VGA bridge, based on either
DACs or resistor ladders.
Those might or might not have an i2c bus routed to the VGA connector in
order to access the screen EDIDs.
Add a bridge that doesn't do anything but expose the modes available on the
screen, either ba
Enable the RGB to VGA bridge driver in the defconfig
Signed-off-by: Maxime Ripard
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 26c35f8b1dd6..edfbd27c9971 100644
--- a/a
Enable the VGA bridge used on the A13-Olinuxino in the sunxi defconfig
Signed-off-by: Maxime Ripard
---
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 6a1447cf8feb..3676cc2db2eb 100644
---
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160720/6760ef07/attachment.html>
On Thu, Jul 07, 2016 at 03:01:21PM +0200, Benjamin Gaignard wrote:
> From: Marek Szyprowski
>
> version 5:
> - remove zpos range check and comeback to 0 to N-1
> normalization algorithm
>
> version 4:
> - make sure that normalized zpos value is stay
> in the defined property range and warn u
I will merge your changes for the next version, thanks
zpos property is not a new property sti, exynos and r-car already used it.
I know some not upstreamed code use it to manage zordering.
For example I have wrote an Android hwcomposer using this property:
https://git.linaro.org/people/benjamin.g
On Wed, Jul 20, 2016 at 12:55 PM, Markus Heiser
wrote:
> Hi Daniel, hi Mauro,
>
> Am 19.07.2016 um 17:32 schrieb Daniel Vetter :
>
>> On Tue, Jul 19, 2016 at 5:25 PM, Daniel Vetter
>> wrote:
>>> On Tue, Jul 19, 2016 at 4:59 PM, Markus Heiser
>>> wrote:
Am 19.07.2016 um 13:42 schrieb D
On Tue, Jul 19, 2016 at 06:25:01PM +0200, Daniel Vetter wrote:
> connector_id in the uapi actually means drm_connector->base.id, which
> is something entirely different. And ->index is also consistent with
> plane/encoder/CRTCS and the various drm_*_index() functions.
>
> While at it also improve/
RL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160720/1f24be1e/attachment.html>
Hi Russell,
On Tue, Jun 28, 2016 at 3:10 PM, Russell King - ARM Linux
wrote:
> I believe the iMX6 uses the Synopsis HDMI 3D Phy. Would it be possible
> if someone can check whether this is relevant to any of the iMX6 targets
> too please?
I asked NXP engineer and I was told:
"In MX6DQ HDMI dr
From: Ville Syrjälä
Found some patches lying about that implement the per-plane rotation
property I've been going on about occasionally. There's also a fix
for atomic to reject invalid rotation angles. I also tossed in support
for horizontal mirroring on CHV, because I could.
Series available
From: Ville Syrjälä
We have intel_rotation_90_or_270() in i915 to check if the rotation is
90 or 270 degrees. Similar checks are elsewhere in drm, so let's move
the helper into a central place and use it everwhere.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_pl
From: Ville Syrjälä
The rotation property should only accept exactly one rotation angle
at once. Let's reject attempts to set none or multiple angles.
Testcase: igt/kms_rotation_crc/bad-rotation
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c | 2 ++
1 file changed, 2 inserti
From: Ville Syrjälä
Not all planes on the ssytem may support the same rotations/reflections,
so make it possible to create a separate property for each plane.
This way userspace gets told exactly which rotations/reflections are
possible for each plane.
Signed-off-by: Ville Syrjälä
---
driv
From: Ville Syrjälä
On certain platforms not all planes support the same set of
rotations/reflections, so let's use the per-plane property
for this.
This is already a problem on SKL when we use the legay cursor plane
as it only supports 0|180 whereas the universal planes support
0|90|180|270,
From: Ville Syrjälä
Using == to check for 180 degree rotation only works as long as the
reflection bits aren't set. That will change soon enough for CHV, so
let's stop doing things the wrong way.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 9 +
drivers/g
From: Ville Syrjälä
Move the plane control register rotation setup away from the
coordinate munging code. This will result in neater looking
code once we add reflection support for CHV.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 28 ++--
From: Ville Syrjälä
The primary and sprite planes on CHV pipe B support horizontal
mirroring. Expose it to the world.
Sadly the hardware ignores the mirror bit when the rotate bit is
set, so we'll have to reject the 180+X case.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_a
From: Ville Syrjälä
Add "bad-rotation" subtest to make sure the kernel rejects some
invalid rotation values (0 and specifying multiple angles at one).
Signed-off-by: Ville Syrjälä
---
tests/kms_rotation_crc.c | 33 +
1 file changed, 33 insertions(+)
diff --
On ke, 2016-07-20 at 16:18 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> We have intel_rotation_90_or_270() in i915 to check if the rotation is
> 90 or 270 degrees. Similar checks are elsewhere in drm, so let's move
> the helper into a central place and use it everwhe
On ke, 2016-07-20 at 16:18 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> The rotation property should only accept exactly one rotation angle
> at once. Let's reject attempts to set none or multiple angles.
>
> Testcase: igt/kms_rotation_crc/bad-rotation
> Signed-off-
On Wed, Jul 20, 2016 at 04:18:07PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> The rotation property should only accept exactly one rotation angle
> at once. Let's reject attempts to set none or multiple angles.
>
> Testcase: igt/kms_rotation_crc/bad-rotation
> Si
On Wed, Jul 20, 2016 at 04:18:08PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Not all planes on the ssytem may support the same rotations/reflections,
> so make it possible to create a separate property for each plane.
> This way userspace gets told exactly which
On Wed, Jul 20, 2016 at 04:18:09PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> On certain platforms not all planes support the same set of
> rotations/reflections, so let's use the per-plane property
> for this.
>
> This is already a problem on SKL when we use the
On Wed, Jul 20, 2016 at 04:18:10PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Using == to check for 180 degree rotation only works as long as the
> reflection bits aren't set. That will change soon enough for CHV, so
> let's stop doing things the wrong way.
>
> S
On Wed, Jul 20, 2016 at 04:18:11PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Move the plane control register rotation setup away from the
> coordinate munging code. This will result in neater looking
> code once we add reflection support for CHV.
>
> Signed-off-
On Wed, Jul 20, 2016 at 04:18:06PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> We have intel_rotation_90_or_270() in i915 to check if the rotation is
> 90 or 270 degrees. Similar checks are elsewhere in drm, so let's move
> the helper into a central place and use i
On ke, 2016-07-20 at 16:18 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> Not all planes on the ssytem may support the same rotations/reflections,
s/ssytem/system/
> so make it possible to create a separate property for each plane.
> This way userspace gets told exac
On ke, 2016-07-20 at 16:18 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> On certain platforms not all planes support the same set of
> rotations/reflections, so let's use the per-plane property
> for this.
>
> This is already a problem on SKL when we use the legay cu
On ke, 2016-07-20 at 16:18 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> Using == to check for 180 degree rotation only works as long as the
> reflection bits aren't set. That will change soon enough for CHV, so
> let's stop doing things the wrong way.
>
> Signed-off
On ke, 2016-07-20 at 16:18 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> Move the plane control register rotation setup away from the
> coordinate munging code. This will result in neater looking
> code once we add reflection support for CHV.
>
> Signed-off-by: Ville
On Wed, Jul 20, 2016 at 04:51:57PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-07-20 at 16:18 +0300, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Not all planes on the ssytem may support the same rotations/reflections,
>
> s/ssytem/system/
>
> > so make it possible
On ke, 2016-07-20 at 17:08 +0300, Ville Syrjälä wrote:
> On Wed, Jul 20, 2016 at 04:51:57PM +0300, Joonas Lahtinen wrote:
> >
> > On ke, 2016-07-20 at 16:18 +0300, ville.syrjala at linux.intel.com wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > Not all planes on the ssytem may support th
On Wed, Jul 20, 2016 at 04:57:32PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-07-20 at 16:18 +0300, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > On certain platforms not all planes support the same set of
> > rotations/reflections, so let's use the per-plane property
On Wed, Jul 20, 2016 at 05:01:00PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-07-20 at 16:18 +0300, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Using == to check for 180 degree rotation only works as long as the
> > reflection bits aren't set. That will change soon
From: Markus Elfring
Date: Wed, 20 Jul 2016 17:54:32 +0200
The drm_property_unreference_blob() function tests whether its argument
is NULL and then returns immediately.
Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus E
From: Markus Elfring
Date: Wed, 20 Jul 2016 18:32:34 +0200
The drm_fbdev_cma_hotplug_event() function tests whether its argument
is NULL and then returns immediately.
Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elf
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160720/a3c813df/attachment.html>
r the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160720/bd37c4bf/attachment.html>
On Wed, Jul 20, 2016 at 12:02 PM, SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Wed, 20 Jul 2016 17:54:32 +0200
>
> The drm_property_unreference_blob() function tests whether its argument
> is NULL and then returns immediately.
> Thus the test around the call is not needed.
>
> This iss
On Wed, Jul 20, 2016 at 06:40:49PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Wed, 20 Jul 2016 18:32:34 +0200
>
> The drm_fbdev_cma_hotplug_event() function tests whether its argument
> is NULL and then returns immediately.
> Thus the test around the call is not needed.
>
> T
From: Markus Elfring
Date: Wed, 20 Jul 2016 19:43:27 +0200
The pci_dev_put() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drive
e
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160720/70296d16/attachment.sig>
Since release.sh creates and pushes a libdrm-$VERSION tag for us,
there's no need to also have the user manually generating a $VERSION
tag as well.
I also dropped the "optional" part of distcheck. You shouldn't have
pushed master with a version bump that hasn't passed distcheck.
---
RELEASING |
On Wed, Jul 20, 2016 at 11:58:54AM +0200, Maxime Ripard wrote:
> Some boards have an entirely passive RGB to VGA bridge, based on either
> DACs or resistor ladders.
>
> Those might or might not have an i2c bus routed to the VGA connector in
> order to access the screen EDIDs.
>
> Add a bridge tha
When performing driver testing, one factor we want to test is how we
handle a foreign fence that is never signaled. We can wait on that fence
indefinitely, in which case the driver appears hung, or we can take some
remedial action (with risks regarding the state of any shared content).
Whatever the
ction that increments it is somehow
"optimized" out.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160720/058ba2dd/attachment-0001.html>
Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.
On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"ar
To Sebastian Reichel:
If this e-mail has the bizarre email address formatting issue you
noticed in the last patch series I sent please let me know. I haven't
gotten a chance to properly look at the e-mail you forwarded to me to
see what's causing the problem, but I d
From: Matt Roper
When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw. However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
o
Up until now we've actually been making the mistake of leaving the
watermark results for each pipe completely blank in skl_compute_wm()
when they haven't changed, fix this.
Fixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during atomic 'check'
(v2)")
Cc: stable at vger.kernel.org
Cc: Vil
As we've learned, all watermark updates on Skylake have to be strictly
atomic or things fail. While the bspec doesn't mandate that we need to
wait for pipes to finish after the third iteration of flushes, not doing
so gives us the opportunity to break this atomicity later. This example
assumes that
Manual pipe flushes are only necessary in order to make sure that we prevent
pipes with changed ddb allocations from overlapping from one another at
any point in time. Additionally, forcing us to wait for the next vblank
every time we have to update the watermark values because the cursor was
movin
Similar to how a vehicle will travel faster if you paint flames on it,
cleaning up this extra whitespace is guaranteed to provide additional
stability while updating watermark values.
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_pm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/driv
On Wed, Jul 20, 2016 at 04:59:57PM -0400, Lyude wrote:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
>
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> va
On Wed, Jul 20, 2016 at 04:59:58PM -0400, Lyude wrote:
> From: Matt Roper
>
> When we write watermark values to the hardware, those values are stored
> in dev_priv->wm.skl_hw. However with recent watermark changes, the
> results structure we're copying from only contains valid watermark and
> DD
On Wed, Jul 20, 2016 at 04:59:59PM -0400, Lyude wrote:
> Up until now we've actually been making the mistake of leaving the
> watermark results for each pipe completely blank in skl_compute_wm()
> when they haven't changed, fix this.
Should this be moved before patch #1? With the existing code we
Why is this useful if only root can use it?
Kristian
On Wed, Jul 20, 2016 at 12:39 PM, Chris Wilson
wrote:
> When performing driver testing, one factor we want to test is how we
> handle a foreign fence that is never signaled. We can wait on that fence
> indefinitely, in which case the driver a
x27;s video memory running
out, the game does not cause system OOM.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160720/d17ba5ff/attachment.html>
On Wed, Jul 20, 2016 at 05:00:00PM -0400, Lyude wrote:
> As we've learned, all watermark updates on Skylake have to be strictly
> atomic or things fail. While the bspec doesn't mandate that we need to
> wait for pipes to finish after the third iteration of flushes, not doing
> so gives us the oppor
On Wed, Jul 13, 2016 at 03:52:38PM -0700, Markus Mayer wrote:
> On Sat, Jul 09, 2016 at 09:11:05PM -0700, Markus Mayer wrote:
>> On 9 July 2016 at 20:13, Chris Metcalf wrote:
>>> On 7/8/2016 6:43 PM, Markus Mayer wrote:
This series introduces a family of generic string case conversion
>>
Em Wed, 20 Jul 2016 20:35:09 +0200
Markus Heiser escreveu:
> Am 20.07.2016 um 14:20 schrieb Mauro Carvalho Chehab s-opensource.com>:
>
> > Em Tue, 19 Jul 2016 14:36:50 +0200
> > Daniel Vetter escreveu:
> >
> >> On Tue, Jul 19, 2016 at 01:42:55PM +0200, Daniel Vetter wrote:
> >>> These are
Hi Daniel, hi Mauro,
Am 19.07.2016 um 17:32 schrieb Daniel Vetter :
> On Tue, Jul 19, 2016 at 5:25 PM, Daniel Vetter
> wrote:
>> On Tue, Jul 19, 2016 at 4:59 PM, Markus Heiser
>> wrote:
>>>
>>> Am 19.07.2016 um 13:42 schrieb Daniel Vetter :
>>>
Unfortunately warnings generated after par
Em Tue, 19 Jul 2016 14:36:50 +0200
Daniel Vetter escreveu:
> On Tue, Jul 19, 2016 at 01:42:55PM +0200, Daniel Vetter wrote:
> > These are the leftovers I could only track down using keep_warnings =
> > True. For some of them we might want to update our style guide on how
> > to reference structur
Am 20.07.2016 um 13:27 schrieb Daniel Vetter :
> On Wed, Jul 20, 2016 at 12:55 PM, Markus Heiser
> wrote:
>> Hi Daniel, hi Mauro,
>>
>> Am 19.07.2016 um 17:32 schrieb Daniel Vetter :
>>
>>> On Tue, Jul 19, 2016 at 5:25 PM, Daniel Vetter
>>> wrote:
On Tue, Jul 19, 2016 at 4:59 PM, Markus
Em Wed, 20 Jul 2016 14:29:01 +0200
Markus Heiser escreveu:
> Am 20.07.2016 um 13:27 schrieb Daniel Vetter :
>
> > On Wed, Jul 20, 2016 at 12:55 PM, Markus Heiser
> > wrote:
> >> Hi Daniel, hi Mauro,
> >>
> >> Am 19.07.2016 um 17:32 schrieb Daniel Vetter :
> >>
> >>> On Tue, Jul 19, 2016 a
Am 20.07.2016 um 14:20 schrieb Mauro Carvalho Chehab :
> Em Tue, 19 Jul 2016 14:36:50 +0200
> Daniel Vetter escreveu:
>
>> On Tue, Jul 19, 2016 at 01:42:55PM +0200, Daniel Vetter wrote:
>>> These are the leftovers I could only track down using keep_warnings =
>>> True. For some of them we might
92 matches
Mail list logo
