Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c
Add support for Innolux TV123WAM, which is a 12.3" eDP
display panel with 2160x1440 resolution.
Changes in v1:
- Add the compatibility string, display_mode and panel_desc
structures in alphabetical order (Sean Paul).
Signed-off-by: Sandeep Panda
Reviewed-by: Sean Paul
---
Properties like data-lanes, clock-noncontinuous and lane-polarities
are applicable to DSI and DisplayPort interface also. So update the
documentation to mention the same.
Change-Id: I544bdf178bd6b207fa9e2e2e4aad819da320be3b
Signed-off-by: Sandeep Panda
---
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Changes in v1:
- Rephrase the dt-binding descriptions to be more inline with existing
bindings (Andrzej Hajda).
- Add missing dt-binding that are parsed by corresponding driver
(Andrzej Hajda).
Changes in v2:
- Remove edp
Changes in current patchset:
- Use presence of refclk to determine if continuous dsi clock is required or
not.
- Update media/video-interface.txt documentatio for DSI and DP interface.
Sandeep Panda (5):
drm/bridge: add support for sn65dsi86 bridge driver
dt-bindings: drm/bridge: Document
Innolux TV123WAM is a 12.3" eDP display panel with
2160x1440 resolution, which can be supported by simple
panel driver.
Changes in v1:
- Make use of simple panel driver instead of creating
a new driver for this panel (Sean Paul).
- Combine dt-binding and driver changes into one patch
as
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c
On Thu, Jun 14, 2018 at 12:30:35PM +0530, Vivek Gautam wrote:
> Hi Jordan,
>
> On Mon, Jun 11, 2018 at 11:56 PM, Jordan Crouse
> wrote:
> > Now that the IOMMU is the master of it's own power we don't need to bring
> > up the GPU to do IOMMU operations. This is good because bringing up a6xx
> >
On Tue, Jun 12, 2018 at 06:17:47PM -0700, Jeykumar Sankaran wrote:
> Switch to state based resource management. This patch
> overhauls the resource manager and HW allocation methods by
> maintaining the global resource pool and allocated hw
> blocks in respective drm component states.
>
> Global
On Tue, Jun 12, 2018 at 06:17:43PM -0700, Jeykumar Sankaran wrote:
> This patchset introduces drm private object in KMS to manage HW
> resource management. It modifies the resource manager by
> introducing API's to do per DRM object resource allocation/cleanups.
>
> The patchset is based on:
On Wed, Jun 13, 2018 at 12:01:21PM -0700, Jeykumar Sankaran wrote:
> On 2018-06-13 09:44, Jordan Crouse wrote:
> > On Tue, Jun 12, 2018 at 06:17:47PM -0700, Jeykumar Sankaran wrote:
> > > Switch to state based resource management. This patch
> > > overhauls the resource manager and HW allocation
On Mon, Jun 11, 2018 at 02:13:17PM -0700, Jeykumar Sankaran wrote:
> Submitting a series of patches to further clean up DPU driver by stripping
> down a list of custom properties supporting proprietary features. It
> removes the property installers/handlers and cleans up relevant files of
> of
Hi Jordan,
On Mon, Jun 11, 2018 at 11:56 PM, Jordan Crouse wrote:
> Now that the IOMMU is the master of it's own power we don't need to bring
> up the GPU to do IOMMU operations. This is good because bringing up a6xx
> requires the GMU so calling pm_runtime_get_sync() too early in the process
>
13 matches
Mail list logo