tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.1-wip
head: f9028b9278422fdf186f1b88662e28ed24e13df8
commit: 43a6a02eb3558d1f3a0618f9bf02328662fb06e3 [197/225] drm/amd/display:
Re-enable CRC capture following modeset
config: x86_64-randconfig-s2-02021031 (attached as .config)
On Fri, 2019-02-01 at 14:37 +0100, Sam Ravnborg wrote:
> Hi Thierry.
>
> > I'm slightly on the fence about this patch.
>
> Please ignore patch 3-19, there is no consensus on the logging changes.
> We do not want to apply these and then have to redo parts/all of
> it later.
>
> But the first two
Most of these are just cases where code comments used contractions
(it's, who's) where they actually mean to use a possessive pronoun (its,
whose) or vice-versa.
Signed-off-by: Matt Roper
---
A couple of these were bugging me enough that I did a quick search for
other similar mistakes in the DRM
https://bugs.freedesktop.org/show_bug.cgi?id=109022
--- Comment #9 from e88z4 ---
I tried to enable NIR using R600_DEBUG=nir, I got a different behaviour on GFX
timeout.
[Feb 1 19:44] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but
soft recovered
[ +10.240122]
Atomic checks should never modify anything outside of the state that
they're passed in. Unfortunately this appears to be exactly what we're
doing in nv50_msto_atomic_check() where we update mstc->pbn every time
the function is called. This hasn't caused any bugs yet, but it needs to
be fixed in
Since we now have an easy way of refcounting drm_dp_mst_port structs and
safely accessing their contents, there isn't any good reason to keep
validating ports here. It doesn't prevent us from performing modesets on
branch devices that have been removed either, and we already disallow
enabling new
This fixes the extra issues I discovered upstream after the introduction
of my rework of the atomic VCPI helpers that occur during
suspend/resume.
This time around, we use a slightly different but much less complicated
approach for fixing said issues.
Cc: Daniel Vetter
Lyude Paul (4):
Since
commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
connectors harder")
We've been failing atomic checks if they try to enable new displays on
unregistered connectors. This is fine except for the one situation that
breaks atomic assumptions: suspend/resume. If a
In drm_dp_mst_deallocate_vcpi(), we currently unconditionally call
drm_dp_mst_put_port_malloc() on the port that's passed to us, even if we
never successfully allocated VCPI to it. This is contrary to what we do
in drm_dp_mst_allocate_vcpi(), where we only call
drm_dp_mst_get_port_malloc() on the
Daniel Vetter and I were discussing about this solution. We figured out that
after these patches, tests were passing but when the computer has a heavy
background workload, tests fail.
I tried a new solution. Instead of change the vblank_time variable, make the
`get_vblank_timestamp` return false
Important! below
On Fri, 2019-02-01 at 18:57 +0100, Daniel Vetter wrote:
> On Thu, Jan 31, 2019 at 08:14:50PM -0500, Lyude Paul wrote:
> > Since
> >
> > commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
> > connectors harder")
> >
> > We've been failing atomic checks if
Ville Syrjälä wrote:
> > @@ -1774,6 +1776,45 @@ static const u32 skl_planar_formats[] = {
> >DRM_FORMAT_NV12,
> > };
> >
> > +static const uint32_t icl_hdr_plane_formats[] = {
>
> Please switch to u32 & co. We recently had a mass conversion in the
> driver.
Will do. Looks like the CI
Hi Paweł
Looks good, thanks for addressing all the review feedback.
On Fri, Feb 01, 2019 at 06:28:52PM +0100, Paweł Chmiel wrote:
> This patch adds Samsung S6E63M0 AMOLED LCD panel driver, connected over
> spi. It's based on already removed, non dt s6e63m0 driver and
> panel-samsung-ld9040. It
On Fri, Feb 1, 2019 at 3:25 PM Nathan Chancellor
wrote:
>
> Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2314:38:
> warning: suggest braces around initialization of subobject
> [-Wmissing-braces]
> struct dc_surface_dcc_cap output = {0};
>
On Thu 31-01-19 11:10:06, Jerome Glisse wrote:
>
> Andrew what is your plan for this ? I had a discussion with Peter Xu
> and Andrea about change_pte() and kvm. Today the change_pte() kvm
> optimization is effectively disabled because of invalidate_range
> calls. With a minimal couple lines patch
On Fri, Feb 01, 2019 at 09:43:40AM -0800, Kevin Strasser wrote:
> 64 bpp half float formats are supported on hdr planes only and are subject
> to the following restrictions:
> * 90/270 rotation not supported
> * Yf Tiling not supported
> * Frame Buffer Compression not supported
> * Color
On Fri, Feb 1, 2019 at 5:05 AM Daniel Vetter wrote:
>
> On Fri, Feb 1, 2019 at 12:57 AM Stephen Rothwell
> wrote:
> >
> > Hi all,
> >
> > In commit
> >
> > a93587b31e34 ("drm/amd/display: Only get the connector state for VRR when
> > toggled")
> >
> > Fixes tag
> >
> > Fixes: 3cc22f281318
On Fri, Feb 1, 2019 at 5:42 AM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in a dev_err message. Fix it.
>
> Signed-off-by: Colin Ian King
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Fri, Feb 01, 2019 at 09:43:39AM -0800, Kevin Strasser wrote:
> Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
> formatted in IEEE-754 half-precision float (binary16) 1:5:10
> MSb-sign:exponent:fraction form.
>
> This patch attempts to address the feedback provided
tree: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
head: e01c78172871cc703e6228fe2b195a3876e1a0a9
commit: db5652be58a96bdde402cabebc0567ee08631276 [10/24] gpu: host1x: Introduce
support for wide opcodes
config: arm-tegra_defconfig (attached as .config)
compiler:
On Wed, Jan 30, 2019 at 06:24:25PM +0530, Uma Shankar wrote:
> This patch adds a DP colorspace property, enabling
> userspace to switch to various supported colorspaces.
> This will help enable BT2020 along with other colorspaces.
>
> v2: Addressed Maarten and Ville's review comments. Enhanced
>
On Wed, Jan 30, 2019 at 06:24:26PM +0530, Uma Shankar wrote:
> This patch attaches the colorspace connector property to the
> hdmi connector. Based on colorspace change, modeset will be
> triggered to switch to new colorspace.
>
> Based on colorspace property value create an infoframe
> with
On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
> Create a new connector property to program colorspace to sink
> devices. Modern sink devices support more than 1 type of
> colorspace like 601, 709, BT2020 etc. This helps to switch
> based on content type which is to be displayed. The
On Thu, Jan 31, 2019 at 08:14:50PM -0500, Lyude Paul wrote:
> Since
>
> commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
> connectors harder")
>
> We've been failing atomic checks if they try to enable new displays on
> unregistered connectors. This is fine except for the
On Thu, Jan 31, 2019 at 08:14:49PM -0500, Lyude Paul wrote:
> Since we now have an easy way of refcounting drm_dp_mst_port structs and
> safely accessing their contents, there isn't any good reason to keep
> validating ports here. It doesn't prevent us from performing modesets on
> branch devices
On Fri, Feb 01, 2019 at 06:13:48PM +0100, Daniel Vetter wrote:
> On Wed, Jan 30, 2019 at 03:48:50PM -0800, Matt Roper wrote:
> > On Wed, Jan 30, 2019 at 09:57:10PM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 30, 2019 at 10:56:26AM -0800, Matt Roper wrote:
> > > > On Wed, Jan 30, 2019 at
64 bpp half float formats are supported on hdr planes only and are subject
to the following restrictions:
* 90/270 rotation not supported
* Yf Tiling not supported
* Frame Buffer Compression not supported
* Color Keying not supported
v2:
- Drop handling pixel normalize register
- Don't
Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
formatted in IEEE-754 half-precision float (binary16) 1:5:10
MSb-sign:exponent:fraction form.
This patch attempts to address the feedback provided when 2 of these
formats were previosly proposed:
On Fri, Feb 01, 2019 at 06:37:49PM +0100, Daniel Vetter wrote:
> On Sat, Jan 26, 2019 at 01:25:23PM +0100, Sam Ravnborg wrote:
> > The use of drmP.h is discouraged and removal of it from
> > drm_modeset_helper.h caused vboxvideo to fail to build.
> >
> > This patch introduce the necessary fixes
This series defines new formats and adds implementation to the i915 driver.
Since posting v1 I have removed the pixel normalize property, as it's not needed
for basic functionality. Also, I have been working on adding support to
userspace, but we can't land any patches until drm_fourcc.h has been
On Fri, Feb 1, 2019 at 11:12 AM Eric Anholt wrote:
>
> Rob Herring writes:
>
> > Now that the base struct drm_gem_object has a reservation_object, use it
> > and remove the private BO one.
> >
> > Cc: Eric Anholt
> > Cc: Daniel Vetter
> > Cc: David Airlie
> > Cc:
On Sat, Jan 26, 2019 at 01:25:23PM +0100, Sam Ravnborg wrote:
> The use of drmP.h is discouraged and removal of it from
> drm_modeset_helper.h caused vboxvideo to fail to build.
>
> This patch introduce the necessary fixes to prepare for the
> drmP.h removal from drm_modeset_helper.h.
>
> In the
01.02.2019 16:28, Thierry Reding пишет:
> From: Thierry Reding
>
> The HOST1X_CHANNEL_DMAEND is an offset relative to the value written to
> the HOST1X_CHANNEL_DMASTART register, but it is currently treated as an
> absolute address. This can cause SMMU faults if the CDMA fetches past a
>
This patch adds Samsung S6E63M0 AMOLED LCD panel driver, connected over
spi. It's based on already removed, non dt s6e63m0 driver and
panel-samsung-ld9040. It can be found for example in some of Samsung
Aries based phones.
Signed-off-by: Paweł Chmiel
---
Changes from v1:
- Correct order of
01.02.2019 17:10, Thierry Reding пишет:
> On Fri, Feb 01, 2019 at 04:48:56PM +0300, Dmitry Osipenko wrote:
>> 01.02.2019 16:41, Thierry Reding пишет:
>>> On Fri, Feb 01, 2019 at 04:37:59PM +0300, Dmitry Osipenko wrote:
01.02.2019 16:28, Thierry Reding пишет:
> From: Thierry Reding
>
ping
On Sat, 19 Jan 2019 19:21:29 +0100
Andreas Kemnade wrote:
> This panel has a backlight, so add a property describing that and
> add the code to use that.
> This makes things like xset dpms force off
> also turn off the backlight, so we do not need to rely on additional
> userspace programs
On 1/28/19 8:36 AM, Oleksandr Andrushchenko wrote:
> On 1/26/19 2:05 PM, YueHaibing wrote:
>> There is no need to have the 'struct drm_framebuffer *fb' variable
>> static since new value always be assigned before use it.
>>
>> Signed-off-by: YueHaibing
> Good catch, thank you!
> Reviewed-by:
On 1/30/19 11:09 AM, Oleksandr Andrushchenko wrote:
> On 1/29/19 9:07 PM, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> When GEM backing storage is allocated those are normal pages,
>>> so there is no point
01.02.2019 16:28, 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 the geometry is used as-is, allocations of IOVA space can end up in a
>
01.02.2019 16:28, Thierry Reding пишет:
> 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
01.02.2019 16:28, Thierry Reding пишет:
> 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
Hi,
Beside the binding for "rockchip,rk3066-vop" this patch series
also has a new binding for "rockchip,rk3066-hdmi".
Can Rob Herring advise here? Including the document describing the binding.
This patch still has the original license text included.
Can the copyright holder (or Sandy) approve
From: Jonathan Bakker
This commit adds documentation for Samsung s6e63m0 AMOLED LCD panel
driver.
Signed-off-by: Jonathan Bakker
Signed-off-by: Paweł Chmiel
---
Changes from v1:
- Add missing subject prefix
- Rename reset-gpio to reset-gpios
- Add link to spi properites documentation.
This patch adds a binding that describes the HDMI controller for
rk3066.
Signed-off-by: Johan Jonker
---
.../display/rockchip/rk3066_hdmi-rockchip.txt | 60 ++
1 file changed, 60 insertions(+)
create mode 100644
01.02.2019 16:28, Thierry Reding пишет:
> 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
On Thu, Jan 31, 2019 at 6:04 PM Heiko Stuebner wrote:
>
> Am Donnerstag, 31. Januar 2019, 13:31:52 CET schrieb Souptick Joarder:
> > On Thu, Jan 31, 2019 at 5:37 PM Heiko Stuebner wrote:
> > >
> > > Am Donnerstag, 31. Januar 2019, 04:08:12 CET schrieb Souptick Joarder:
> > > > Previouly drivers
01.02.2019 16:28, 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 the geometry is used as-is, allocations of IOVA space can end up in a
>
01.02.2019 16:28, Thierry Reding пишет:
> 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
>
01.02.2019 16:41, Thierry Reding пишет:
> On Fri, Feb 01, 2019 at 04:37:59PM +0300, Dmitry Osipenko wrote:
>> 01.02.2019 16:28, Thierry Reding пишет:
>>> From: Thierry Reding
>>>
>>> The HOST1X_CHANNEL_DMAEND is an offset relative to the value written to
>>> the HOST1X_CHANNEL_DMASTART register,
01.02.2019 16:28, Thierry Reding пишет:
> From: Thierry Reding
>
> The HOST1X_CHANNEL_DMAEND is an offset relative to the value written to
> the HOST1X_CHANNEL_DMASTART register, but it is currently treated as an
> absolute address. This can cause SMMU faults if the CDMA fetches past a
>
01.02.2019 16:28, Thierry Reding пишет:
> From: Thierry Reding
>
> The host1x CDMA push buffer is terminated by a special opcode (RESTART)
> that tells the CDMA to wrap around to the beginning of the push buffer.
> To accomodate the RESTART opcode, an extra 4 bytes are allocated on top
> of the
On 2019/2/1 16:15, Dan Carpenter wrote:
On Fri, Feb 01, 2019 at 02:59:46PM +0800, Qing Xia wrote:
In the first loop, gfp_flags will be modified to high_order_gfp_flags,
and there will be no chance to change back to low_order_gfp_flags.
Fixes: e7f63771 ("ION: Sys_heap: Add cached pool to
On Thu, Jan 31, 2019 at 06:50:52PM -0600, Rob Herring wrote:
> This series implements the todo to add reservation_object to
> drm_gem_object. I converted the easy drivers, but not Intel or AMD. The
> series is build tested only.
Maybe keep the todo around the (just update it a bit) untill the
On Thu, Jan 31, 2019 at 06:50:53PM -0600, Rob Herring wrote:
> Many users of drm_gem_object embed a struct reservation_object into
> their subclassed struct, so let's add one to struct drm_gem_object.
> This will allow removing the reservation object from the subclasses
> and removing the
On Thu, Jan 31, 2019 at 10:44:09AM -0200, Rodrigo Siqueira wrote:
> Hi,
>
> First of all, thanks for your patch :)
>
> I tested your patch against the tests that you implemented in the IGT
> [1]. All the alpha tests passed, but there was a weird warning that
> says:
>
> $ sudo
On Wed, Jan 30, 2019 at 03:48:50PM -0800, Matt Roper wrote:
> On Wed, Jan 30, 2019 at 09:57:10PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 30, 2019 at 10:56:26AM -0800, Matt Roper wrote:
> > > On Wed, Jan 30, 2019 at 10:51:19AM -0800, Matt Roper wrote:
> > > > Previous patch series was here:
> >
Rob Herring writes:
> Now that the base struct drm_gem_object has a reservation_object, use it
> and remove the private BO one.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
dri-devel mailing list
Rob Herring writes:
> Now that the base struct drm_gem_object has a reservation_object, use it
> and remove the private BO one.
>
> Cc: Eric Anholt
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring
> @@ -453,8 +453,6 @@
On Fri, Feb 1, 2019 at 8:01 PM Maxime Ripard wrote:
>
> On Tue, Jan 29, 2019 at 11:01:31PM +0530, Jagan Teki wrote:
> > On Tue, Jan 29, 2019 at 8:43 PM Maxime Ripard
> > wrote:
> > >
> > > On Mon, Jan 28, 2019 at 03:06:10PM +0530, Jagan Teki wrote:
> > > > On Sat, Jan 26, 2019 at 2:54 AM Maxime
On Fri, Feb 1, 2019 at 9:19 PM Maxime Ripard wrote:
>
> On Fri, Feb 01, 2019 at 09:12:09PM +0530, Jagan Teki wrote:
> > Here is next version changes for Allwinner A64 MIPI-DSI support
> >
> > This series grouped the changes like previous version[1] with different
> > sets to support three
On Fri, Feb 01, 2019 at 09:12:09PM +0530, Jagan Teki wrote:
> Here is next version changes for Allwinner A64 MIPI-DSI support
>
> This series grouped the changes like previous version[1] with different
> sets to support three different panels types that can fit into the DSI
> controller.
>
>
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
Tested-by:
Add MIPI DSI pipeline for Allwinner A64.
- dsi node, with A64 compatible since it doesn't support
DSI_SCLK gating unlike A33
- dphy node, with A64 compatible with A33 fallback since
DPHY on A64 and A33 is similar
- finally, attach the dsi_in to tcon0 for complete MIPI DSI
Signed-off-by:
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 =
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
As per the user manual, look like mod clock is not mandatory
for all Allwinner MIPI DSI controllers, it is connected to
CLK_DSI_SCLK for A31 and not available in A64.
So add has_mod_clk quirk and process the clk accordingly.
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
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
Tested-by: Merlijn Wajer
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 ++-
1 file changed, 6
The MIPI DSI controller in Allwinner A64 is similar to A33.
But unlike A33, A64 doesn't have DSI_SCLK gating so add compatible
for Allwinner A64 with uninitialized has_mod_clk driver.
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 +++
1
Allwinner MIPI DSI controllers are supplied with SoC DSI power rails
via VCC-DSI pin.
Add support for this supply pin by adding voltage regulator handling
code to MIPI DSI driver.
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 14 ++
Allwinner MIPI DSI controllers are supplied with SoC DSI
power rails via VCC-DSI pin.
Some board still work without supplying this but give more
faith on datasheet and hardware schematics and document this
supply property in required property list.
Signed-off-by: Jagan Teki
Reviewed-by: Rob
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
Burst mode in DSI would require separate setup initialization
with respect to conventional video mode.
Allwinner DSI controller would need below sequence to setup the
burst mode.
1) configure the burst drq.
2) configure the burst line.
3) finally enable mode.
To configure burst drq, controller
Allwinner MIPI DSI drq has enable mode bit and set bits.
1) drq for non-burst, with front porch less than 20 would need to
set both enable mode bit and set bits.
2) drq for non-burst, with front porch greater or equal to 20 would
not require to do any drq bit setup.
3) drq for burst mode,
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
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
---
TCON dotclock compute the desired DCLK register divider based on panel
pixel clock along with input DCLK or DSI clock dividers from tcon driver.
The current code allowing an input DCLK dividers ranging from 4 to 127,
but the existing dclock logic is unable to compute the desired output
DCLK
Loop N1 instruction delay varies between burst and non-burst video modes.
1) for burst mode panels it is computed based on the panel pixel clock
along with horizontal sync and porch timings.
2) for non-burst mode panels, it is same as existing (50 - 1)
Reference code is available in BSP (from
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
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 simply add burst mode timings without touching existing mode
timings.
Reference code taken from BSP (from
Here is next version changes for Allwinner A64 MIPI-DSI support
This series grouped the changes like previous version[1] with different
sets to support three different panels types that can fit into the DSI
controller.
set:1, for 4-lane, burst mode support
- patch 0001: 0009, DSI controller
The MIPI DSI controller in Allwinner A64 is similar to A33.
But unlike A33, A64 doesn't have DSI_SCLK gating so it is valid
to with separate compatible for A64 on the same driver.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
Tested-by: Merlijn Wajer
---
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:
The burst mode panels with 4-lane would require to enable trail bits
in DSI basic control register.
So, enable 2byte trail and trail_env for 4-lane burst mode devices.
Allwinner A64 BSP should also relie on same setup for enabling trail
bit in DSI controller.
Reference code avialable in BSP
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
Tested-by: Merlijn Wajer
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 +++
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 1 +
2 files changed, 8
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
Tested-by: Merlijn Wajer
---
Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 +
1 file
https://bugs.freedesktop.org/show_bug.cgi?id=108824
--- Comment #2 from olivier.jo...@laposte.net ---
I also encounter what is most probably this same bug (same assertion at least)
in a randomly fashion when using Blender 2.80.
My setup is debian unstable with a Radeon HD 7950 (and also GeForce
https://bugs.freedesktop.org/show_bug.cgi?id=108824
--- Comment #1 from olivier.jo...@laposte.net ---
Created attachment 143269
--> https://bugs.freedesktop.org/attachment.cgi?id=143269=edit
backtrace of crash when hitting this assert (from 18.3.3/19.0.0-rc1)
--
You are receiving this mail
Hi Rob,
On Wed, Jan 30, 2019 at 10:39:10AM -0600, Rob Herring wrote:
> On Tue, Jan 22, 2019 at 05:44:28PM +0200, Laurent Pinchart wrote:
> > On Tue, Jan 22, 2019 at 03:25:46PM +, Biju Das wrote:
> >> Document the RZ/G1N (R8A7744) LVDS bindings.
> >>
> >> Signed-off-by: Biju Das
> >
> >
Hi Dave, Daniel,
Here is the drm-misc-next PR for this week.
Thanks!
Maxime
drm-misc-next-2019-02-01:
drm-misc-next for 5.1:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- Split out some part of drm_crtc_helper.h into drm_probe_helper.h
- DRIVER_* flags improvements
- New tasks
Friendly ping, Ben.
I see that in `nouveau_fence_done()` there is a check on `chan` not being NULL
prior to passing it to `nouveau_fence_update()`. Would something similar be
needed here?
Pierre
On 2018-11-15 — 12:14, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
>
On Tue, Jan 29, 2019 at 11:01:31PM +0530, Jagan Teki wrote:
> On Tue, Jan 29, 2019 at 8:43 PM Maxime Ripard
> wrote:
> >
> > On Mon, Jan 28, 2019 at 03:06:10PM +0530, Jagan Teki wrote:
> > > On Sat, Jan 26, 2019 at 2:54 AM Maxime Ripard
> > > wrote:
> > > >
> > > > On Fri, Jan 25, 2019 at
On Mon, Dec 10, 2018 at 10:51:04PM +0100, Arnd Bergmann wrote:
> In this usage, the two are completely equivalent, but the
> completion documents better what is going on, and we generally
> try to avoid semaphores these days.
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/host1x/cdma.c |
Hi Emil,
Am Donnerstag, den 24.01.2019, 14:42 + schrieb Emil Velikov:
> > On Wed, 23 Jan 2019 at 11:26, Emil Velikov wrote:
> >
> > On Wed, 23 Jan 2019 at 11:04, Eric Engestrom
> > wrote:
> > >
> > > On Wednesday, 2019-01-23 10:45:17 +, Emil Velikov wrote:
> > > > > > > > From: Emil
Hi Guido
On Fri, Feb 01, 2019 at 09:49:54AM +0100, Guido Günther wrote:
> Add support for the MIXEL DPHY IP as found in the NXP's i.MX8MQ.
>
> Signed-off-by: Guido Günther
> ---
> .../bindings/phy/mixel,mipi-dsi-phy.txt | 29 +++
> 1 file changed, 29 insertions(+)
>
On Fri, Feb 01, 2019 at 04:48:56PM +0300, Dmitry Osipenko wrote:
> 01.02.2019 16:41, Thierry Reding пишет:
> > On Fri, Feb 01, 2019 at 04:37:59PM +0300, Dmitry Osipenko wrote:
> >> 01.02.2019 16:28, Thierry Reding пишет:
> >>> From: Thierry Reding
> >>>
> >>> The HOST1X_CHANNEL_DMAEND is an
On Fri, Jan 25, 2019 at 11:00:57AM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The SOR has a crossbar that can map each lane of the SOR to each of the
> SOR pads. The mapping is usually the same across designs for a specific
> SoC generation, but every now and then there's a design
On Fri, Feb 01, 2019 at 04:37:59PM +0300, Dmitry Osipenko wrote:
> 01.02.2019 16:28, Thierry Reding пишет:
> > From: Thierry Reding
> >
> > The HOST1X_CHANNEL_DMAEND is an offset relative to the value written to
> > the HOST1X_CHANNEL_DMASTART register, but it is currently treated as an
> >
Hi Thierry.
> I'm slightly on the fence about this patch.
Please ignore patch 3-19, there is no consensus on the logging changes.
We do not want to apply these and then have to redo parts/all of
it later.
But the first two patches has not seen any feedback yet:
[PATCH v1 01/19] drm/panel:
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
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
1 - 100 of 161 matches
Mail list logo
