https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #61 from Zheng Luo ---
I experienced similar problems, but mine is much worse. I can't recover from
black screen after reboot/hard reset unless I drain the builtin battery.
However this problem disappears in 5.0rc3 (in contrast to
On Thu, Jan 24, 2019 at 05:58:24PM +0100, Daniel Vetter wrote:
> This should not result in any changes.
I'd love to merge https://patchwork.freedesktop.org/series/53951/
instead (which will -- among other things -- switch qxl over to the
generic fbdev emulation and remove the code you are
https://bugs.freedesktop.org/show_bug.cgi?id=109445
Mike Mestnik changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
In some cases, such as running a new kernel with an old device tree that
has the frontend disabled, the backend's matching frontend might be
unavailable.
When this happens, the layers should only declare support for formats
that the backend support. This partially reverts commit 1c29d263f624
The display pipeline has the same structure, resources and connections
on both the A23 and A33. The differences include:
- compatible strings
- extra clock, reset control, and IO region for SAT in the backend
only found on the A33
- missing ch1 clock for the TCON
However, while the A23
Hi everyone,
This series enables the display pipeline on the Allwinner A23 SoC.
A few fixes are included for corner cases when the frontend isn't
enabled.
The A23 display pipeline is very much the same as the A33, except
that the A23 does not have the SAT IP block embedded within the
display
The NAND controller device node was inserted into the wrong position,
probably due to a rebase or merge, as the file's structure does not
provide enough context for git to accurately match the previous device
node block.
Fixes: d7b843df13ea ("ARM: dts: sun8i: add NAND controller node for
Now that the compatible strings for the display pipeline on the A23 have
been added to the bindings, add the corresponding compatibles to the
device nodes already in the A23/A33 shared dtsi.
While the A23 has the TCON ch1 clock defined in the CCU, and the channel
1 registers are available, it
The A23's display pipeline is similar to the A33. Differences include:
- Display backend supports larger layers, 8192x8192 instead of 2048x2048
- TCON has DMA input
- There is no SAT module packed in the display backend
Add support for the display pipeline and its components.
As the
We might want to use the backend pointer from DRM callbacks that get
called within drm_universal_plane_init(), such as the
.format_mod_supported callback.
Move the assignment of the layer's backend pointer to right after the
structure is allocated.
Signed-off-by: Chen-Yu Tsai
---
The display backend does not support BGRX. There is also no trace
of this in the original list of supported formats before the commit
b636d3f97d04 ("drm/sun4i: frontend: Add support for the BGRX input
format"). Nor do the backend configuration helpers handle this format.
Remove BGRX
The Q8 design for A23/A33 tablets have an 18-bit RGB LCD panel connected
to the LCD interface on the SoC, the DC1SW output on the PMIC providing
power for the LCD, and PH7 toggling the reset pin for the panel.
This patch adds a device node for the panel, describing the above, and
enables the
The Q8 tablets follow the A23/A33 tablet reference design, and normally
use a "generic" 800x480 LCD panel. The actual panel may vary between
production runs, and there are no visible markings denoting its model.
This patch uses a panel that has the same dimensions and timings that
are close to
The PLL-MIPI clock is somewhat special as it has its own LDOs which
need to be turned on for this PLL to actually work and output a clock
signal.
Add the 2 LDO enable bits to the gate bits.
Fixes: 5690879d93e8 ("clk: sunxi-ng: Add A23 CCU")
Signed-off-by: Chen-Yu Tsai
---
The A23's display pipeline is similar to the A33. Differences include:
- Display backend supports larger layers, 8192x8192 instead of 2048x2048
- TCON has DMA input
- There is no SAT module packed in the display backend
Add compatible strings for the display pipeline and its components.
Hi,
On Fri, 25 Jan 2019 01:21:26 + "Li, Weinan Z" wrote:
>
> I am not sure about the problem. The commit id "0cce2823ed37" is just
> for the patch of "drm/i915/gvt: Refine error handling for
> prepare_execlist_workload". Is there any other problems I missed?
Its just that the subject line
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #46 from Shmerl ---
(In reply to Jerry Zuo from comment #45)
> Please try the patch and see if that fixes your issue. We will come up with
> proper solution later.
I tested the patch, and it didn't fix the issue for me.
--
You
The pull request you sent on Fri, 25 Jan 2019 07:54:37 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-01-25-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d73aba1115cf40630cc8b4b7aed049ed8117b458
Thank you!
--
Deet-doot-dot, I am a bot.
Thank Stephen.
I am not sure about the problem. The commit id "0cce2823ed37" is just for the
patch of "drm/i915/gvt: Refine error handling for prepare_execlist_workload".
Is there any other problems I missed?
Regards.
-Weinan
> -Original Message-
> From: Jani Nikula
On Thu, Jan 24, 2019 at 04:52:59PM -0800, ndesaulni...@google.com wrote:
> arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The
> AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn
> on SSE2 to support emitting double precision floating point instructions
>
On Fri, Jan 25, 2019 at 3:26 AM Colin Ian King wrote:
>
> ping?
I've pushed this, and the others you pinged about, to my tree.
Thank you,
Ben.
>
> On 04/09/2018 16:23, Colin King wrote:
> > From: Colin Ian King
> >
> > Don't populate the array vsoff on the stack but instead make it
> > static.
Hi Linus,
Live from LCA pull, some fixes all over the place,
i915:
- GVT workload destruction fix
msm:
- A6XX opp-level fix, build fixes, hard-coded irq removal
amdgpu:
- overclocking fix
- hybrid gfx fix
sun4i:
- fix TMDS clock usage
Dave.
drm-fixes-2019-01-25-1:
drm fixes. msm, sun4i,
Hi Sean/Hans.
> > Hans de Goede sent out patches in September to convert it to a proper
> > atomic driver.
> > I recall that the feedback was mostly positive and that there was only
> > minor things to left to do. Hans?
I browsed the archieves and I could not find anything that was not
ST7701 designed for small and medium sizes of TFT LCD display, is
capable of supporting up to 480RGBX864 in resolution. It provides
several system interfaces like MIPI/RGB/SPI.
Currently added support for Techstar TS8550B which is ST7701 based
480x854, 2-lane MIPI DSI LCD panel.
Driver now
Techstar TS8550B MIPI DSI panel is 480x854, 2-lane MIPI DSI LCD panel
with inbuilt ST7701 chip.
The default regulator names in ST7701 chip is renamed in Techstar TS8550B
so, add specific binding names for them.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
---
Changes for v8, v9:
- none
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #45 from Jerry Zuo ---
Please try the patch and see if that fixes your issue. We will come up with
proper solution later.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=109445
--- Comment #5 from Bas Nieuwenhuizen ---
to clarify, try idle=nomwait on the kernel commandline.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=109445
--- Comment #4 from Bas Nieuwenhuizen ---
since you mentioned your system does not respond to ping or ssh I wonder if it
is actually not a gpu problem, but more generally being under load.
maybe try idle=nomwait? That solved regular lockup
Hi,
I tested your patch with kms_cursor_crc, and everything worked as
expected! Really nice patch :)
I just have some tiny comments inline.
On 01/24, Mamta Shukla wrote:
> Use the alpha value to blend vaddr_src with vaddr_dst instead
> of overwriting it in blend().
>
> Signed-off-by: Mamta
Hi Dave,
A few fixes for v5.0.. the opp-level fix and removal of hard-coded irq
name is partially to make things smoother in v5.1 merge window to
avoid dependency on drm vs dt trees, but are otherwise sane changes.
The following changes since commit ba0ede185ef4c74bfecfe1c992be5dbcc5c5ac04:
On Thu, Jan 24, 2019 at 09:17:49PM +0100, Sam Ravnborg wrote:
> Hi Sean.
>
> > >
> > > Merge the previous 5 patches from this series, but this now goes boom on
> > > vbox in staging. Needs another prep patch I think.
> >
> > Soo, can we drop vboxvideo yet?
>
> Hans de Goede sent out patches in
Hi Sean.
> >
> > Merge the previous 5 patches from this series, but this now goes boom on
> > vbox in staging. Needs another prep patch I think.
>
> Soo, can we drop vboxvideo yet?
Hans de Goede sent out patches in September to convert it to a proper
atomic driver.
I recall that the feedback
On Thu, Jan 24, 2019 at 03:03:20PM +0100, Daniel Vetter wrote:
> On Sat, Jan 19, 2019 at 09:40:14AM +0100, Sam Ravnborg wrote:
> > With the removal of drmP.h from drm_modeset_helper.h
> > the drmP.h are no longer included by any include files
> > in include/drm.
> > The drmP.h file is thus only
Current driver is calculating hfp maximum value by subtracting
htotal with hsync_end which is front back value, but the
hpp refers to front porch.
Front porch value is calculating by subtracting hsync_start with
hdisplay as per drm_mode timings, and BSP code from BPI-M64-bsp
is eventually
This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M64 board.
DSI panel connected via board DSI port with,
- DLDO1 as VDD supply
- PD6 gpio for reset pin
- PD5 gpio for backlight enable pin
- PD7 gpio for backlight vdd supply
Signed-off-by: Jagan Teki
---
The MIPI DSI PHY controller on Allwinner A64 is similar
on the one on A31.
Add A64 compatible and append A31 compatible as fallback.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 +
1 file changed, 1 insertion(+)
diff
Current driver is calculating hbp maximum value by subtracting
hsync_start with hdisplay which is front porch value, but the
hbp refers to back porch.
Back porch value is calculating by subtracting htotal with
hsync_end as per drm_mode timings, and BSP code from BPI-M64-bsp
is eventually
Amarula A64-Relic board by default bound with Techstar TS8550B
MIPI-DSI panel, add support for it.
DSI panel connected via board DSI port with,
- DLDO2 as VCC supply
- DLDO2 as IOVCC supply
- DLDO1 as VCC-DSI supply
- PD24 gpio for reset pin
- PD23 gpio for backlight enable pin
Signed-off-by:
Short transfer write support for DCS and Generic transfer types
share similar way to process command sequence in DSI block so
add generic write 2 param transfer type macro so-that the panels
which are requesting similar transfer type may process properly.
Signed-off-by: Jagan Teki
---
Feiyang FY07024DI26A30-D MIPI_DSI panel is desiged to attach with
DSI connector on pine64 boards, enable the same for pine64 LTS.
DSI panel connected via board DSI port with,
- DC1SW as AVDD supply
- DLDO2 as DVDD supply
- DLDO1 as VCC-DSI supply
- PD24 gpio for reset pin
- PH10 gpio for
The A64 has a MIPI-DSI block which is similar to A31.
Add dsi, dphy nodes with A31 fallback compatible and finally
connect the dsi node to tcon0 node to make proper DSI pipeline.
Signed-off-by: Jagan Teki
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 47 +++
1 file
For 4-lane, burst mode panels would need to enable 2byte trail_fill
along with filling trail_env in dsi base control register.
Similar reference code avialable in BSP (from linux-sunxi/
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
if (panel->lcd_dsi_lane == 4)
{
Setting up burst mode display would require to compute
- Horizontal timing edge values to fill burst drq register
- Line, sync values to fill burst line register
Since there is no direct documentation for these computations
the edge and line formulas are taken from BSP code (from linux-sunxi/
Horizontal back porch, sync active and sync end bits are
needed to disable for burst mode panel operations.
So, disable them via dsi base control register.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff
Some boards have VCC-DSI pin connected to voltage regulator which may
not be turned on by default.
Add support for such boards by adding voltage regulator handling code to
MIPI DSI driver.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 14 ++
Probe tcon0 during dsi_bind, so-that the tcon attributes like
divider value, clock rate can get whenever it need.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 +++
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 1 +
2 files changed, 8 insertions(+)
diff --git
Minimum PLL used for MIPI is 500MHz, as per manual, but
lowering the min rate by 300MHz can result proper working
nkms divider with the help of desired dclock rate from
panel driver.
Signed-off-by: Jagan Teki
Acked-by: Stephen Boyd
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 1 +
1 file
The MIPI DSI controller in Allwinner A64 is similar to A33.
But unlike A33, A64 doesn't have DSI_SCLK gating which eventually
set the mod clock rate for the controller.
So, use the DSI_DPHY gating for the similar purpose of mod clock
so-that the controller can operate properly.
Signed-off-by:
Some NKM PLLs doesn't work well when their output clock rate is set below
certain rate.
So, add support for minimal rate for relevant PLLs.
Signed-off-by: Jagan Teki
Acked-by: Stephen Boyd
---
drivers/clk/sunxi-ng/ccu_nkm.c | 5 +
drivers/clk/sunxi-ng/ccu_nkm.h | 1 +
2 files changed, 6
Most of the Allwinner MIPI DSI controllers are supply with
VCC-DSI pin. which need to supply for some of the boards to
trigger the power.
So, document the supply property so-that the required board
can eable it via device tree.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
---
Sometimes tcon attributes like tcon divider, clock rate etc are needed
in interface drivers like DSI. So for such cases interface driver must
probe the respective tcon and get the attributes.
Since tcon0 probe is already available, via sun4i_get_tcon0 function,
export the same instead of probing
Allwinner MIPI DSI drq has enable mode and set bits.
- for burst mode, drq need to set enable mode bit.
- for non-burst video modes, drq need to set enable mode,
set bits for those front proch greater than 20 and for
rest drq is not used.
This patch simplifies existing drq code by grouping
Burst mode display timings are different from conventional
video mode, for burst mode most of the timings hsa, hbp, hfp,
vblk are 0 and hblk is computed as (mode->hdisplay * Bpp)
This patch add burst mode timings and directly goto alloc buffer.
Reference code taken from BSP (from linux-sunxi/
Instruction loop selection would require before writing
loop number registers, so enable idle, LP11 bits on
loop selection register.
Reference code available in BSP (from linux-sunxi/
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
(dsi_dev[sel]->dsi_inst_loop_sel.dwval =
Loop N1 instruction delay varies between burst and non-burst
video modes. for burst mode panels it is computed based on the
panel clock along with horizontal sync and porch timings and
the rest it is simply (50 - 1)
Reference code is available in BSP (from linux-sunxi
Here is next version changes for Allwinner A64 MIPI-DSI support
This series grouped the changes from previous version A64 MIPI-DSI[1]
along with burst mode[2].
Though the series seems to have more patches, but all patches are ordered
in a way that the review process is as smooth as possible.
Hi Jagan.
Thanks for this nice patch, a few comments below.
On Fri, Jan 25, 2019 at 12:13:13AM +0530, Jagan Teki wrote:
> Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
>
> Add panel driver for it.
>
> Signed-off-by: Jagan Teki
> ---
> Changes for v5:
> - rebase on master
>
Hi Jagan.
Thanks for being persistent and keep follow-up on this driver.
On Thu, Jan 24, 2019 at 11:58:44PM +0530, Jagan Teki wrote:
> ST7701 designed for small and medium sizes of TFT LCD display, is
> capable of supporting up to 480RGBX864 in resolution. It provides
> several system interfaces
https://bugs.freedesktop.org/show_bug.cgi?id=107978
Alex Deucher changed:
What|Removed |Added
Attachment #143225|application/mbox|text/plain
mime type|
Chris Wilson writes:
> Quoting Koenig, Christian (2019-01-22 08:49:30)
>> Am 22.01.19 um 00:20 schrieb Chris Wilson:
>> > Rather than every backend and GPU driver reinventing the same wheel for
>> > user level debugging of HW execution, the common dma-fence framework
>> > should include the
Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
Add panel driver for it.
Signed-off-by: Jagan Teki
---
Changes for v5:
- rebase on master
- adjust the hporch values to satisfy the refresh
Changes for v4:
- use simple structure for command init
- update proper comments on power,
Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
Add dt-bingings for it.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
---
Changes for v4, v3:
- none
Changes for v2:
- new patch, derived from another dsi series
.../display/panel/feiyang,fy07024di26a30d.txt | 20
ST7701 designed for small and medium sizes of TFT LCD display, is
capable of supporting up to 480RGBX864 in resolution. It provides
several system interfaces like MIPI/RGB/SPI.
Currently added support for Techstar TS8550B which is ST7701 based
480x854, 2-lane MIPI DSI LCD panel.
Driver now
Techstar TS8550B MIPI DSI panel is 480x854, 2-lane MIPI DSI LCD panel
with inbuilt ST7701 chip.
The default regulator names in ST7701 chip is renamed in Techstar TS8550B
so, add specific binding names for them.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
---
Changes for v8, v7:
-
On Wed, Jan 23, 2019 at 04:41:44PM +0300, Dmitry Osipenko wrote:
> 23.01.2019 12:39, Thierry Reding пишет:
> > From: Thierry Reding
> >
> > On Tegra186 and later, the ARM SMMU provides an input address space that
> > is 48 bits wide. However, memory clients can only address up to 40 bits.
> > If
From: Thierry Reding
The version of VIC found in Tegra186 and later incorporates improvements
with regards to context isolation. As part of those improvements, stream
ID registers were added that allow to specify separate stream IDs for
the Falcon microcontroller and the VIC memory interface.
From: Thierry Reding
Enable address translation for VIC via the SMMU on Tegra186.
Signed-off-by: Thierry Reding
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
From: Thierry Reding
Upon driver failure, the driver core will take care of clearing the
driver data, so there's no need to do so explicitly in the driver.
Reviewed-by: Dmitry Osipenko
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/vic.c | 1 -
1 file changed, 1 deletion(-)
diff
From: Thierry Reding
On Tegra186 and later, the ARM SMMU provides an input address space that
is 48 bits wide. However, memory clients can only address up to 40 bits.
If the geometry is used as-is, allocations of IOVA space can end up in a
region that cannot be addressed by the memory clients.
From: Thierry Reding
Loading the firmware requires an allocation of IOVA space to make sure
that the VIC's Falcon microcontroller can read the firmware if address
translation via the SMMU is enabled.
However, the allocation currently happens at a time where the geometry
of an IOMMU domain may
From: Thierry Reding
Tegra186 and later are different from earlier generations in that they
use an ARM SMMU rather than the Tegra SMMU. The ARM SMMU driver behaves
slightly differently in that the geometry for IOMMU domains is set only
after a device was attached to it. This is to make sure that
From: Thierry Reding
Move initialization of the shared IOMMU domain after the host1x device
has been initialized. At this point all the Tegra DRM clients have been
attached to the shared IOMMU domain.
This is important because Tegra186 and later use an ARM SMMU, for which
the driver defers
From: Thierry Reding
Tegra186 and later support 40 bits of address space. Additional
registers need to be programmed to store the full 40 bits of push
buffer addresses.
Since command stream gathers can also reside in buffers in a 40-bit
address space, a new variant of the GATHER opcode is also
From: Thierry Reding
On Tegra186 and later, the ARM SMMU provides an input address space that
is 48 bits wide. However, memory clients can only address up to 40 bits.
If the geometry is used as-is, allocations of IOVA space can end up in a
region that is not addressable by the memory clients.
From: Thierry Reding
Tegra DRM clients need access to their parent, so store a pointer to it
upon registration. It's technically possible to get at this by going via
the host1x client's parent and getting the driver data, but that's quite
complicated and not very transparent. It's much more
From: Thierry Reding
If we use the IOMMU API directly to map buffers into host1x' IOVA space,
we must make sure that the DMA API doesn't already set up a mapping, or
else translation will fail.
The direct DMA API allows us to allocate memory that will not be mapped
through an IOMMU
From: Thierry Reding
When processing command streams, make sure the host1x's stream ID is
programmed for the channel so that addresses are properly translated
through the SMMU.
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/hw/channel_hw.c | 12
From: Thierry Reding
The host1x and clients instantiated on Tegra186 support addressing 40
bits of memory.
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index
From: Thierry Reding
In order to enable the MMIO path stream ID protection provided by the
incarnation of host1x found in Tegra186 and later, the host1x must be
provided with the list of stream ID register offsets for each of its
clients. Some clients (such as VIC) have multiple stream ID
Hi Daniel.
On Thu, Jan 24, 2019 at 05:58:14PM +0100, Daniel Vetter wrote:
> Should not result in any changes.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Junwei Zhang
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: Daniel Vetter
> Cc: Sean Paul
> Cc: YueHaibing
> Cc: Sam
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #44 from Jerry Zuo ---
Created attachment 143225
--> https://bugs.freedesktop.org/attachment.cgi?id=143225=edit
Patch for fixing MST reboot/poweroff sequence
--
You are receiving this mail because:
You are the assignee for the
On Thu, Jan 24, 2019 at 6:46 PM Greg KH wrote:
>
> On Thu, Jan 24, 2019 at 11:43:12AM +0100, Daniel Vetter wrote:
> > On Wed, Jan 23, 2019 at 11:54:07AM +0100, Noralf Trønnes wrote:
> > >
> > >
> > > Den 22.01.2019 20.30, skrev Daniel Vetter:
> > > > On Tue, Jan 22, 2019 at 8:07 PM Noralf Trønnes
On Thu, Jan 24, 2019 at 05:18:12PM +0100, Thierry Reding wrote:
> On Thu, Jan 24, 2019 at 12:01:55PM -0300, Ezequiel Garcia wrote:
> > On Tue, 2018-10-30 at 10:15 +0100, Heiko Stuebner wrote:
> > > From: Nickey Yang
> > >
> > > Support Kingdisplay kd097d04 9.7" 1536x2048 TFT LCD panel,
> > > it
On Thu, Jan 24, 2019 at 11:43:12AM +0100, Daniel Vetter wrote:
> On Wed, Jan 23, 2019 at 11:54:07AM +0100, Noralf Trønnes wrote:
> >
> >
> > Den 22.01.2019 20.30, skrev Daniel Vetter:
> > > On Tue, Jan 22, 2019 at 8:07 PM Noralf Trønnes wrote:
> > >>
> > >>
> > >>
> > >> Den 22.01.2019 10.32,
Hi Daniel.
On Thu, Jan 24, 2019 at 05:58:11PM +0100, Daniel Vetter wrote:
> The fbdev emulation helpers pretty much assume that this is set.
> Let's do it for everyone.
I do not know this code at all.
But I failed to follow the code from the patch description.
It do not give _me_ a clue why the
Den 24.01.2019 17.58, skrev Daniel Vetter:
> The fbdev split between fix and var information is kinda
> pointless for drm drivers since everything is fixed: The fbdev
> emulation doesn't support changing modes at all.
>
> Create a new simplified helper and use it in the generic fbdev
> helper
Hi Daniel.
> +
> + /**
> + * @DRIVER_HAVE_DMA:
> + *
> + * Driver supports DMA, the userspace DMA API will be supported. Only
> + * for legacy drivers. Do not use.
> + */
> + DRIVER_HAVE_DMA = BIT(4),
What about grouping all the "legacy, do not
ping?
On 04/09/2018 16:23, Colin King wrote:
> From: Colin Ian King
>
> Don't populate the array vsoff on the stack but instead make it
> static. Makes the object code smaller by 67 bytes:
>
> Before:
>text data bss dec hex filename
>5753 112 0
ping?
On 19/12/2018 15:29, Colin King wrote:
> From: Colin Ian King
>
> Currently the uninitialized values in the array reply are printed out
> when exec is false and nvkm_pmu_send has not updated the array. Avoid
> confusion by only dumping out these values if they have been actually
>
ping?
On 25/11/2018 17:09, Colin King wrote:
> From: Colin Ian King
>
> Currently, the expression for calculating RON is always going to result
> in zero no matter the value of ram->mr[1] because the ! operator has
> higher precedence than the shift >> operator. I believe the missing
>
On Thu, Jan 24, 2019 at 5:58 PM Daniel Vetter wrote:
>
> Looking at the oldest/most popular drivers ${driver}drmfb seems to be
> the standard, except i915.ko went with "inteldrmfb". I guess renaming
> that for consistency won't hurt, it definitely confused me when I
> started with kms 10 years
Should not result in any changes.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Alex Deucher
Cc: "Christian König"
Cc: Junwei Zhang
Cc: Daniel Vetter
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 2 +-
drivers/gpu/drm/mgag200/mgag200_fb.c | 8 +---
2 files changed, 2 insertions(+), 8
This should not result in any changes.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_fb.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git
Not used by drivers anymore.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 38 +
include/drm/drm_fb_helper.h | 4
2 files changed, 5 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c
This changes the fb name from "omapdrm" to "omapdrmfb".
Signed-off-by: Daniel Vetter
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_fbdev.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
This should not result in any changes.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_fb.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git
Another driver that didn't set fbinfo->fix.id before.
Signed-off-by: Daniel Vetter
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/fb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tegra/fb.c
Looking at the oldest/most popular drivers ${driver}drmfb seems to be
the standard, except i915.ko went with "inteldrmfb". I guess renaming
that for consistency won't hurt, it definitely confused me when I
started with kms 10 years ago.
I hope this never became uapi ... worst case drivers can
This should not result in any changes.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Sean Paul
Cc: Mikulas Patocka
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Emil Lundmark
---
drivers/gpu/drm/udl/udl_fb.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
This changes the fb name from "inteldrmfb" to "i915drmfb".
Signed-off-by: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_fbdev.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git
1 - 100 of 212 matches
Mail list logo
