On Thu, Jan 31, 2019 at 11:47:38AM +0100, Noralf Trønnes wrote:
>
>
> Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> > Add 3d resource parameters to virtio_gpu_object_params struct. With
> > that in place we can use it for virtio_gpu_cmd_resource_create_3d()
> > calls.
> >
> > Signed-off-by: Gerd
> > - ret = virtio_gpu_gem_create(file_priv, dev, args->size, &gobj,
> > + params.pinned = false,
>
> You have a comma here, but assigning to false isn't really necessary
> since the struct is zeroed. Same goes for the same assignment further down.
Hmm, yes, but it likewise isn't used, so I t
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 spead up cached buffer
> alloc")
Huh...
On 2019-01-27 09:27, Boris Brezillon wrote:
> On Thu, 10 Jan 2019 15:10:28 +
> Peter Rosin wrote:
>
>> Hi!
>>
>> I found an unfortunate issue while recoding plane handling to use
>> drm_atomic_helper_check_plane_state(). The driver rotates clockwise,
>> which is not correct. I simply fixed it
On Thu, Jan 31, 2019 at 03:43:39PM +0530, Souptick Joarder wrote:
> On Thu, Jan 31, 2019 at 2:09 PM Mike Rapoport wrote:
> >
> > On Thu, Jan 31, 2019 at 08:38:12AM +0530, Souptick Joarder wrote:
> > > Previouly drivers have their own way of mapping range of
> > > kernel pages/memory into user vma
On 2019-01-31 12:02 p.m., Jason Gunthorpe wrote:
> I still think the right direction is to build on what Logan has done -
> realize that he created a DMA-only SGL - make that a formal type of
> the kernel and provide the right set of APIs to work with this type,
> without being forced to expose s
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 spead up cached buffer
alloc")
Signed-off-by: Qing Xia
---
drivers/staging/android/ion/ion_system_heap.c
On Thu, Jan 31, 2019 at 12:19:31PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-31 12:02 p.m., Jason Gunthorpe wrote:
> > I still think the right direction is to build on what Logan has done -
> > realize that he created a DMA-only SGL - make that a formal type of
> > the kernel and provide the
On Thu, Jan 31, 2019 at 2:09 PM Mike Rapoport wrote:
>
> On Thu, Jan 31, 2019 at 08:38:12AM +0530, Souptick Joarder wrote:
> > Previouly drivers have their own way of mapping range of
> > kernel pages/memory into user vma and this was done by
> > invoking vm_insert_page() within a loop.
> >
> > As
On Thu, Jan 31, 2019 at 02:35:14PM -0500, Jerome Glisse wrote:
> > Basically invert the API flow - the DMA map would be done close to
> > GUP, not buried in the driver. This absolutely doesn't work for every
> > flow we have, but it does enable the ones that people seem to care
> > about when talk
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 have their own way of mapping range of
> > kernel pages/memory into user vma and this was done by
> > invoking vm_insert_page() within a loop.
> >
On Thu, Jan 31, 2019 at 09:13:55AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 03:52:13PM -0700, Logan Gunthorpe wrote:
> > > *shrug* so what if the special GUP called a VMA op instead of
> > > traversing the VMA PTEs today? Why does it really matter? It could
> > > easily change to a
Thanks.
On 2019/2/1 14:59, 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 spead up cached buffer
> alloc")
> Signed-off-by: Qing
On 2019-01-31 12:35 p.m., Jerome Glisse wrote:
> So what is this O_DIRECT thing that keep coming again and again here :)
> What is the use case ? Note that bio will always have valid struct page
> of regular memory as using PCIE BAR for filesystem is crazy (you do not
> have atomic or cache coher
This adds initial support for the Mixel IP based mipi dphy as found on i.MX8
processors. It has support for the i.MX8MQ, support for other variants can be
added - once the necessary parts are in - via the provided devdata.
The driver is somewhat based on what's found in NXPs BSP.
Documentation on
Hi Sam,
On Fri, Jan 25, 2019 at 05:53:55PM +0100, Sam Ravnborg wrote:
[..snip..]
> > +struct mixel_dphy_cfg {
> > + u32 cm;
> > + u32 cn;
> > + u32 co;
> > + unsigned long hs_clk_rate;
> > + u8 mc_prg_hs_prepare;
> > + u8 m_prg_hs_prepare;
> > + u8 mc_prg_hs_zero;
> > + u8 m_prg_hs_
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(+)
create mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
diff --git
This adds support for the Mixel DPHY as found on i.MX8 CPUs but since
this is an IP core it will likely be found on others in the future. So
instead of adding this to the nwl host driver make it a generic PHY
driver.
The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be
added on
Add vendor prefix "mixel" for Mixel Inc. Will be used for a MIPI DSI
PHY driver.
Signed-off-by: Guido Günther
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devic
Hi,
On 31-01-19 14:36, Maarten Lankhorst wrote:
Op 29-01-2019 om 15:22 schreef Hans de Goede:
We really want to have fastboot enabled by default to avoid an ugly
modeset during boot.
Currently we are enabling fastboot by default on gen9+ (Skylake and newer).
The intention is to enable it on ol
Hi Thierry.
>
> I personally like the DRM_DEV_* variants better because of the
> additional information that they provide. That can be useful when
> grepping logs etc.
>
> I'm slightly on the fence about this patch. The unwritten, and
> admittedly fuzzy, rules that I've been using so far are tha
Den 01.02.2019 09.01, skrev Gerd Hoffmann:
> On Thu, Jan 31, 2019 at 11:47:38AM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 30.01.2019 10.43, skrev Gerd Hoffmann:
>>> Add 3d resource parameters to virtio_gpu_object_params struct. With
>>> that in place we can use it for virtio_gpu_cmd_resource_cre
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 ("drm/amdgpu: Set FreeSync state using drm VRR
> properties")
>
> has these proble
On 31.01.2019 16:50, Neil Armstrong wrote:
> On 31/01/2019 15:13, Andrzej Hajda wrote:
>> On 31.01.2019 14:25, Neil Armstrong wrote:
>>> Hi Andrzej, Laurent,
>>>
>>> On 15/01/2019 13:33, Neil Armstrong wrote:
This patchset aims to add support for the following HDMI2.0 4k60 modes:
- 594Mhz
On Fri, 01 Feb 2019, Sam Ravnborg wrote:
> Hi Thierry.
>
>>
>> I personally like the DRM_DEV_* variants better because of the
>> additional information that they provide. That can be useful when
>> grepping logs etc.
>>
>> I'm slightly on the fence about this patch. The unwritten, and
>> admitte
From: Colin Ian King
There is a spelling mistake in a dev_err message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
b/drivers/gpu/drm/amd/amdgpu/a
Hi Daniel,
On Fri, 1 Feb 2019 11:05:43 +0100 Daniel Vetter wrote:
>
> Another one: Is the above checker script available somewhere, could be
> useful to put that into our own scripts to make sure this doesn't
> happen again.
I have attached the script. It accepts a range of commits.
--
Cheers,
On 01.02.2019 11:30, Jani Nikula wrote:
> On Fri, 01 Feb 2019, Sam Ravnborg wrote:
>> Hi Thierry.
>>
>>> I personally like the DRM_DEV_* variants better because of the
>>> additional information that they provide. That can be useful when
>>> grepping logs etc.
>>>
>>> I'm slightly on the fence abo
On Fri, 01 Feb 2019, Andrzej Hajda wrote:
> On 01.02.2019 11:30, Jani Nikula wrote:
>> On Fri, 01 Feb 2019, Sam Ravnborg wrote:
>>> Hi Thierry.
>>>
I personally like the DRM_DEV_* variants better because of the
additional information that they provide. That can be useful when
grepp
Hi Guido,
Thanks for the respin. It looks better :-)
On Fri, Feb 1, 2019 at 6:50 AM Guido Günther wrote:
> +config PHY_MIXEL_MIPI_DPHY
> + tristate "Mixel MIPI DSI PHY support"
> + depends on OF
> + select GENERIC_PHY
> + select GENERIC_PHY_MIPI_DPHY
Since you converted
Le 01/02/2019 11:25, Andrzej Hajda a écrit :
> On 31.01.2019 16:50, Neil Armstrong wrote:
>> On 31/01/2019 15:13, Andrzej Hajda wrote:
>>> On 31.01.2019 14:25, Neil Armstrong wrote:
Hi Andrzej, Laurent,
On 15/01/2019 13:33, Neil Armstrong wrote:
> This patchset aims to add supp
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
for these modes in the connector if the platform supports them.
We limit these modes to DW-HDMI IP version >= 0x200a which
are designed to support HDMI2.0 display modes.
Signed-off-by: Neil Armstrong
Tested-by: Heiko Stuebner
In order to support the HDMI2.0 YUV420 display modes, this patch
adds support for the YUV420 TMDS Clock divided by 2 and the controller
passthrough mode.
YUV420 Synopsys PHY support will need some specific configuration table
to support theses modes.
This patch is based on work from Zheng Yang i
Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
Scrambling when supported or mandatory.
This patch also adds an helper to setup the control bit to support
the high TMDS Bit Period/TMDS Clock-Period Ratio as required with
TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes.
Th
Add support for TMDS Clock > 3.4GHz for HDMI2.0 display modes.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson
From: Zheng Yang
To get input/output bus_format/enc_format dynamically, this patch
introduce following functions in plat_data:
- get_input_bus_format
- get_output_bus_format
- get_enc_in_encoding
- get_enc_out_encoding
Signed-off-by: Zheng Yang
Signed-off-by: Nei
This patchset aims to add support for the following HDMI2.0 4k60 modes:
- 594Mhz TMDS frequency needing TMDS Scramling and 1/40 rate for RGB/YUV4:4:4
- 297MHz TMDS frequency with YUV4:2:0 encoding
The first mode uses the SCDC helpers introduced by intel to :
- discover where the monitor support SC
Now we support the TMDS Clock > 3.4GHz and support the SCDC Control
operation in the DW-HDMI Controller, we can enable support for the
HDMI2.0 3840x2160@60/50 RGB444 display modes.
Signed-off-by: Neil Armstrong
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/meson/meson_venc.c | 2 ++
1 file cha
This patch adds support for the YUV420 output from the Amlogic Meson SoCs
Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixe
With the YUV420 handling, we can dynamically setup the HDMI output
pixel format depending on the mode and connector info.
So now, we can output in YUV444, which is the native video pipeline
format, directly to the HDMI Sink if it's supported without
necessarily involving the HDMI Controller CSC.
S
https://bugs.freedesktop.org/show_bug.cgi?id=107990
--- Comment #11 from Timothy Arceri ---
(In reply to John from comment #10)
> Hey Timothy,
>
> is this something fairly easy to get into for someone with no knowledge of
> OpenGL or Mesa (I've had a patch 5 years ago, so pretty much the same as
Am 31.01.19 um 17:10 schrieb Jerome Glisse:
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 top of th
https://bugs.freedesktop.org/show_bug.cgi?id=109352
Chris Wilson changed:
What|Removed |Added
QA Contact|intel-gfx-bugs@lists.freede |
|sktop.org
://github.com/0day-ci/linux/commits/Rob-Herring/Add-reservation_object-to-drm_gem_object/20190201-160738
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
net/mac80211/sta_info.h:590: warning: Function parameter or member
'tx_stats.bytes' not described in 'sta_
On 01.02.2019 13:07, Neil Armstrong wrote:
> In order to support the HDMI2.0 YUV420 display modes, this patch
> adds support for the YUV420 TMDS Clock divided by 2 and the controller
> passthrough mode.
>
> YUV420 Synopsys PHY support will need some specific configuration table
> to support theses
On Thu, Jan 31, 2019 at 02:25:50PM +0100, Paul Kocialkowski wrote:
> When initializing clocks, a reference to the TCON channel 0 clock is
> obtained. However, the clock is never prepared and enabled later.
> Switching from simplefb to DRM actually disables the clock (that was
> usually configured b
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 registe
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
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.
To
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
pushbuffer's IOMMU mapping.
Properly setting the DMAEND pre
From: Thierry Reding
The CDMA push buffer can currently only handle opcodes that take a
single word parameter. However, the host1x implementation on Tegra186
and later supports opcodes that require multiple words as parameters.
Unfortunately the way the push buffer is structured, these wide opco
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 --g
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 setti
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.
Wh
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 no
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.
T
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
drivers/gpu/host1x/h
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
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 strai
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 automatically
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 i
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 512 * 8 = 4096 bytes needed for the 512 slots (1 slot
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 54
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: d
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
> > absol
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 th
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 offset
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(+)
> creat
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 V
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 | 6
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 01:28
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:
>
> drivers
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
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
> >
> > Revi
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&action=edit
backtrace of crash when hitting this assert (from 18.3.3/19.0.0-rc1)
--
You are receiving this m
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 G
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 chan
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: Jag
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 (fro
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 insertion
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
---
Documentation/devicetree/bindings
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 chang
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 t
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
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
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 divide
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
---
.../dts/allwinner/sun50
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 backlight
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, wou
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 wo
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 following
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 f
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
---
drivers/gpu/dr
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 insertions(+)
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 ++
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 followin
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 Herr
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: Jagan
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 = 2<<(4*DSI_
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: Merl
1 - 100 of 161 matches
Mail list logo
