Hi Gustavo,
On 20 June 2016 at 16:53, Gustavo Padovan wrote:
> - - port libsync tests to kselftest
I believe the tests haven't landed yet right, so this should stay right ?
-Emil
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160623/3e2be3d9/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160623/975d0488/attachment.html>
For RK3399's GRF module, if we want to operate the graphic related grf
registers, we need to enable the pclk_vio_grf which supply power for VIO
GRF IOs, so it's better to introduce an optional grf clock in driver.
Signed-off-by: Yakir Yang
---
Hi all,
This is an external patch for analogix_dp mi
The document about rockchip platform make a mistaken in available
compatible name of "rk3288-edp", we should correct it to "rk3288-dp"
which correspond to the compatible name in driver.
This mistaken was introduced in commit be91c36247089 ("dt-bindings:
add document for rockchip variant of analogi
For RK3399's GRF module, if we want to operate the graphic related grf
registers, we need to enable the pclk_vio_grf which supply power for VIO
GRF IOs, so it's better to introduce an optional grf clock in driver.
Signed-off-by: Yakir Yang
---
Hi all,
This is an external patch for analogix_dp mi
e - the graphical glitches are gone
--
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/20160623/e2f34b6d/attachment.html>
from Michel Dänzer ---
Matt, any ideas?
--
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/20160623/854bcf58/attachment.html>
Hi Maxime,
Today's linux-next merge of the sunxi tree got a conflict in:
drivers/gpu/drm/sun4i/sun4i_drv.c
between commit:
366e292df678 ("drm/sun4i: Remove open-coded drm_connector_register_all()")
from the drm-misc tree and commit:
7aa2e2b731b3 ("drm/sun4i: Convert to connector registe
distro developers may need to
be informed about this, as I have seen a number of bug reports complaining
about symptoms similar to what I have experienced.
Thanks again!
--
Best Regards
Neoklis - Ham Radio Call:5B4AZ
http://www.5b4az.org/
--
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/20160623/c75abce1/attachment-0001.html>
The following patch implements precise vblank timestamping
for RaspberryPi's VC4, at least for standard progressive
scan display modes.
It has been tested on the HDMI output with half a dozen different
video modes using special hardware measurement equipment to compare
generated time stamps agains
Precise vblank timestamping is implemented via the
usual scanout position based method. On VC4 the
pixelvalves PV do not have a scanout position
register. Only the hardware video scaler HVS has a
similar register which describes which scanline for
the output is currently composited and stored in th
On Thu, Jun 23, 2016 at 8:17 AM, Mario Kleiner
wrote:
> The following patch implements precise vblank timestamping
> for RaspberryPi's VC4, at least for standard progressive
> scan display modes.
>
> It has been tested on the HDMI output with half a dozen different
> video modes using special hard
On Fri, Jun 17, 2016 at 2:03 PM, Jon Hunter wrote:
> Add the DPAUX pinctrl states for the DPAUX nodes defining all three
> possible states of "aux", "i2c" and "off". Also add the 'i2c-bus'
> node for the DPAUX nodes so that the I2C driver core does not attempt
> to parse the pinctrl state nodes.
On Fri, Jun 17, 2016 at 6:58 PM, Thierry Reding
wrote:
> Oh wait... there's the pinctrl helper function that is a build-
> dependency. Linus, would you be okay if I took that through the
> drm-tegra tree along with the DPAUX driver change, and provide a
> stable branch for you to resolve conflict
patch upstream.
Regards
--
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/20160623/a362ed87/attachment.html>
p.org/archives/dri-devel/attachments/20160623/8bf3a2ff/attachment.html>
and then you can pull it too.
>
> Would that work?
Yes, that would be just fine.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freed
Hi Lin,
On 2016ë
06ì 22ì¼ 21:25, hl wrote:
> Hi Chanwoo Choi,
>
> On 2016å¹´06æ22æ¥ 15:11, Chanwoo Choi wrote:
>> Hi,
>>
>> On 2016ë
06ì 06ì¼ 19:13, Lin Huang wrote:
>>> when in ddr frequency scaling process, vop can not do
>>> enable or disable operate, since dcf will base on vop vb
Hi Philipp,
On Wed, Jun 22, 2016 at 4:51 PM, Philipp Zabel
wrote:
> Hi Nicolas,
>
> Am Mittwoch, den 22.06.2016, 14:32 +0800 schrieb Nicolas Boichat:
>> >> Actually, experimenting a bit more with the code, I realized that the
>> >> connector is always attached to the encoder, not the bridge, so
On Wed, 22 Jun 2016, Daniel Vetter wrote:
> On Wed, Jun 22, 2016 at 4:31 PM, Thierry Reding
> wrote:
>> Perhaps another way to avoid that would be to put the two files into a
>> separate directory, as in:
>>
>> /sys/kernel/debug/dri//crtc-/crc/
>> +-- control
>> +-- data
>
On 23 June 2016 at 10:21, Jani Nikula wrote:
> On Wed, 22 Jun 2016, Daniel Vetter wrote:
>> On Wed, Jun 22, 2016 at 4:31 PM, Thierry Reding
>> wrote:
>>> Perhaps another way to avoid that would be to put the two files into a
>>> separate directory, as in:
>>>
>>> /sys/kernel/debug/dri//c
tting you in
an 'unfair position'.
--
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/20160623/7bcd36c7/attachment.html>
that arriving at the sink.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160623/b2d24dac/attachment.sig>
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/20160623/4571f601/attachment-0001.html>
On Thu, 23 Jun 2016, Andy Lutomirski wrote:
> I have a Dell XPS 13 9350 (Skylake) and a Dell DA200 adapter. The
> latter is a Thunderbolt device that includes an HDMI port and connects
> over USB Type C. I believe that it's internally using DP Alternate
> Mode.
> I don't know whether this is a
Am Donnerstag, den 23.06.2016, 12:08 +0800 schrieb Nicolas Boichat:
[...]
> >> >> I think it'd be a bit weird to have the DDC bus phandle on the DP
> >> >> connector, as we're not reading the EDID on the DP side of the bridge,
> >> >> but on the HDMI side (and the bridge can do all sort of things t
On Thu, Jun 23, 2016 at 10:04 AM, Thierry Reding
wrote:
> On Thu, Jun 23, 2016 at 09:49:20AM +0200, Linus Walleij wrote:
>> On Fri, Jun 17, 2016 at 6:58 PM, Thierry Reding
>> wrote:
>>
>> > Oh wait... there's the pinctrl helper function that is a build-
>> > dependency. Linus, would you be okay i
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160623/e8cb2cb4/attachment.html>
On Thu, Jun 23, 2016 at 10:43 AM, Thierry Reding
wrote:
> On Thu, Jun 23, 2016 at 10:24:46AM +0200, Tomeu Vizoso wrote:
>> On 23 June 2016 at 10:21, Jani Nikula wrote:
>> > On Wed, 22 Jun 2016, Daniel Vetter wrote:
>> >> On Wed, Jun 22, 2016 at 4:31 PM, Thierry Reding
>> >> wrote:
>> >>> Perhap
From: Thierry Reding
The SOR clock can have various sources, with the most commonly used
being the sor_safe, pll_d2_out0, pll_dp and sor_brick clocks. These
are configured using a three level mux, of which the first 2 levels
can be treated as one. The direct parents of the SOR clock are the
sor_s
From: Thierry Reding
When running in HDMI mode, the sor1 IP block needs to use the sor1_src
as parent clock, and in turn configure the sor1_src to use pll_d2_out0
as its parent.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 14 +-
1 file changed, 13 insertions(+),
On Tue, 2016-06-21 at 17:00 -0400, James Bottomley wrote:
> On Tue, 2016-06-21 at 18:44 +0300, Ville Syrjälä wrote:
> > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > Cc: Ville
> > > >
> > > > On Mon, 20 Jun 20
Atomic updates may acquire more state than initially locked through
drm_modeset_lock_crtc, running with heavy stress can cause a
WARN_ON(crtc->acquire_ctx) in drm_modeset_lock_crtc:
[ 601.491296] [ cut here ]
[ 601.491366] WARNING: CPU: 0 PID: 2411 at
drivers/gpu/drm/drm_
Hi all
This series patch is for rockchip Type-C phy and DisplayPort controller
driver.
The USB Type-C PHY is designed to support the USB3 and DP applications.
The PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and H
This patch adds a binding that describes the cdn DP controller for
rk3399.
Signed-off-by: Chris Zhong
---
Changes in v3:
- add SoC specific compatible string
- remove reg = <1>;
Changes in v2: None
Changes in v1:
- add extcon node description
- add #sound-dai-cells description
.../bindings/d
Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware
2016-06-22 1:45 GMT+02:00 Laurent Pinchart :
> Hi Benjamin,
>
> Thank you for the patch.
>
> Could you please reply to Ville's comment to v1 of this patch (posted on April
> the 25th) ?
>
For each iteration of the patches we have swap between two solutions:
- have normalization done between 0 to N
On Thu, 23 Jun 2016, Steven Newbury wrote:
> [ Unknown signature status ]
> On Sun, 2016-06-19 at 14:53 -0700, James Bottomley wrote:
>> On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
>> > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
>> > > On Fri, 17 Jun 2016, Daniel Vetter w
l_type from OpRegion panel details
> > >
> > > After being more careful about waiting to identify flicker, this
> > > one
> > > seems to be the one the bisect finds.  I'm now running v4.7-rc3
> > > with
> > > this one reverted and am currently seeing no flicker
> > > problems.  It
> > > is,
> > > however, early days because the flicker can hide for long
> > > periods, so
> > > I
> > > 'll wait until Monday evening and a few reboots before declaring
> > > victory.
> > >
> > > Â
> > I'm seeing this on my IvyBridge. Â I'll try reverting the commit
> > here
> > too, to see if it's the same issue.
>
> IvyBridge doesn't have low vswing for eDP. If reverting helps, it's a
> different failure mode.
>
It must be something else then. Â Actually, in my case linus/master is
okay. Â I saw the subject and though it must be the same issue. Â I'm
seeing it with drm-intel nightly/next branches. Â Shall I try to bisect
it? Â Symptoms are similar, although I would describe it more like
flashes of a different buffer across parts of the screen.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160623/1f99b976/attachment.sig>
On Thu, Jun 23, 2016 at 08:17:49AM +0200, Mario Kleiner wrote:
> The following patch implements precise vblank timestamping
> for RaspberryPi's VC4, at least for standard progressive
> scan display modes.
>
> It has been tested on the HDMI output with half a dozen different
> video modes using spe
idate bad commit is this one:
>
> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> Author: Ville Syrjälä
> Date:Â Â Â Mon Apr 11 10:23:51 2016 +0300
>
> Â Â Â Â drm/i915: Get panel_type from OpRegion panel details
>
> After being more careful about waiting to identify flicker, this one
> seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
> this one reverted and am currently seeing no flicker problems.  It
> is,
> however, early days because the flicker can hide for long periods, so
> I
> 'll wait until Monday evening and a few reboots before declaring
> victory.
>
>Â
I'm seeing this on my IvyBridge. Â I'll try reverting the commit here
too, to see if it's the same issue.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160623/c628480a/attachment-0001.sig>
On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote:
> Rename RK3288_DP macros to ROCKCHIP_DP, prepare to add eDP
> support for more Rockchip chips.
>
>
> Signed-off-by: Yakir Yang
> Reviewed-by: Stéphane Marchesin
> Tested-by: Javier Martinez Canillas
I'm ok with this as long as there aren't
On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote:
> As vendor document indicate, when REF_CLK bit set 0, then DP
> phy's REF_CLK should switch to 24M source clock.
>
> But due to IC PHY layout mistaken, some chips need to flip this
> bit(like RK3288), and unfortunately they didn't indicate in the
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160623/9c612d16/attachment.html>
On Thu, Jun 23, 2016 at 01:45:06PM +0200, Maarten Lankhorst wrote:
> Atomic updates may acquire more state than initially locked through
> drm_modeset_lock_crtc, running with heavy stress can cause a
> WARN_ON(crtc->acquire_ctx) in drm_modeset_lock_crtc:
>
> [ 601.491296] [ cut here ]
On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote:
> RK3399 and RK3288 shared the same eDP IP controller, only some light
> difference with VOP configure and GRF configure.
>
> Signed-off-by: Yakir Yang
> Acked-by: Mark Yao
> ---
> Changes in v3:
> - Give the "rk3399-edp" a separate line for cla
On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote:
> Some boards don't need to declare a panel device node, like the
> display interface is DP monitors, so it's necessary to make the
> panel detect to an optional action.
>
> Signed-off-by: Yakir Yang
> Acked-by: Mark Yao
> ---
> Changes in v3:
>
On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote:
> It's better to pass the connector to platform driver in .get_modes()
> callback, just like what the .get_modes() helper function designed.
>
> Signed-off-by: Yakir Yang
Reviewed-by: Sean Paul
> ---
> Changes in v3:
> - Avoid to change any in
This patchset adds the last bits needed for getting the MSM display
bindings in correct shape, and as an example, adds display support for
MSM8916.
One problem with the MDP5 driver was that device hierarchy didn't match
with the hardware. All MDP5 based display blocks contain a top-level
MDSS wrap
The driver gets the irq number using platform_get_irq on the main kms
platform device. This works fine since both MDP4 and MDP5 currently
have a flat device hierarchy. The platform device tied with the
drm_device points to the MDP DT node in both cases.
This won't work when MDP5 supports a tree-li
With MDP5 as a new device, we need to do less for MDP when initializing
modeset after all the components are bound.
Create mdp5_kms_init2/destroy2 funcs that inits modeset. These will
eventually replace the older kms_init/destroy funcs.
In the new kms_init2, the platform_device used is the one co
In order to have a tree-like device hierarchy between MDSS and its
sub-blocks (MDP5, DSI, HDMI, eDP etc), we need to create a separate
device/driver for MDP5. Currently, MDP5 and MDSS are squashed
together are are tied to the top level platform_device, which is
also the one used to create drm_devic
Call msm_mdss_init in msm_drv to set up top level registers/irq line.
Start using the new kms_init2/destroy2 funcs to inititalize MDP5 KMS.
With the MDSS interrupt and irqdomain set up, the old MDP5 irq code
can be dropped.
The mdp5_hw_init kms func now uses the platform device tied to MDP5
inste
The MDP5 sub-block register offsets are relative to the top level
MDSS register address.
Now that we have the start of MDP5 register address space, provide
the offsets relative to that. This involves subtracting the offsets
with 0x1000 or 0x100 depending on the MDP5 version.
Signed-off-by: Archit
With the new device hierarchy for MDP5, we need to enable runtime PM
for both the toplevel MDSS device and the MDP5 device itself. Enable
runtime PM for the new devices.
Since MDP4 and MDP5 now have different places where runtime PM is
enabled, remove the previous pm_runtime_enable/disable calls,
Since runtime PM isn't implemented yet, we need to call
mdp5_enable/disable in a few more places. These would later be
replaced by runtime PM get/put calls.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 2 ++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 2 ++
2 files ch
This isn't needed as we only support OF.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/msm_drv.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index a02dc2b..476eafe 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/d
These aren't used. Probably left overs when driver was refactored to
support both MDP4 and MDP5.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/msm_kms.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index e3c..009
SoCs that contain MDP5 have a top level wrapper called MDSS that manages
clocks, power and irq for the sub-blocks within it.
Currently, the MDSS portions are stuffed into the MDP5 driver. This makes
it hard to represent the DT bindings in the correct way. We create a top
level MDSS helper that han
With the new kms_init/destroy funcs in place for MDP5, we can get rid of
the old kms funcs. Some members of the mdp5_kms struct also become
redundant, so we remove those too.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 228 +---
drivers/
Since MDSS registers were stuffed within the the MDP5 register
space, we had an __offset_MDP() macro to identify the offset
between the start of MDSS and MDP5 address spaces. This offset
macro expected a MDP index argument, which didn't make much
sense since we don't have multiple MDPs.
The offset
Simplifies some of the code that we'll add later.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/msm_drv.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 1c18690..1b8b915 100644
The kms driver currently identifies all the mdss components it needs by
parsing a phandle list from the 'connectors' DT property.
Instead of this, describe a list of ports that the MDP hardware provides
to the external world. These ports are linked to external encoder
interfaces such as DSI, HDMI.
For MDP5 based platforms, the master device isn't the MDP5 platform
device, but the top level MDSS device, which is a parent to MDP5 and
interface (DSI, HDMI, eDP etc) devices.
In order to add components on MDP5 platforms, we first need to populate
the MDSS children, locate the MDP5 child, and the
The driver currently identifies the GPU components it needs by parsing
a phandle list from the 'gpus' DT property.
This isn't the right binding to go with. So, for now, just search all
device nodes and find the gpu node we need by parsing a list of
compatible strings.
Once we know how to link the
Introduce new compatible strings for the top level MDSS wrapper device,
and the MDP5 device.
Previously, the "qcom,mdp5" and "qcom,mdss_mdp" compatible strings
were used to match the top level platform_device (which was also tied
to the top level drm_device struct). Now, these strings are used
to
The DSI host and PHY driver currently expects the DT bindings to provide
custom properties "qcom,dsi-host-index" and "qcom,dsi-phy-index" so that
the driver can identify which DSI instance it is.
The binding isn't acceptable, but the driver still needs to figure out
what its instance id. This is n
MDP4 and MDP5 vary a bit in terms of device hierarchy and the properties
they require. Rename the binding doc to mdp4.txt and remove MDP5 specific
pieces. A separate document will be created for MDP5
Acked-by: Rob Herring
Signed-off-by: Archit Taneja
---
.../devicetree/bindings/display/msm/mdp.
Add a new doc for DT bindings for platforms that contain MDP5 display
controller hardware. The doc describes bindings for the top level
MDSS wrapper hardware and MDP5 itself.
Add an example for the bindings as found in MSM8916.
Acked-by: Rob Herring
Signed-off-by: Archit Taneja
---
.../devicet
The MDP4/5 DT node now contains a list of ports that describe how it
connects to external encoder interfaces like DSI and HDMI. These follow
the standard of_graph bindings, and allow us to get rid of the 'connectors'
phandle that contained a list of all the external encoders connected to
MDP.
Acke
Remove the DSI index properties from the DSI host and PHY binding
documentation. The indices aren't a valid property and shouldn't
be a part of the DT binding.
Signed-off-by: Archit Taneja
---
Documentation/devicetree/bindings/display/msm/dsi.txt | 6 --
1 file changed, 6 deletions(-)
diff
Remove the power-domain property from the DSI, HDMI and eDP dt-binding
docs. The power domain only needs to be specified in the parent MDSS
device node (that too only for SoCs which contain MDSS).
Signed-off-by: Archit Taneja
---
Documentation/devicetree/bindings/display/msm/dsi.txt | 3 ---
Do
The MSM8916 SoC contains a MDP5 based display block, and one DSI output.
Add the top level MDSS DT node, and the MDP5, DSI and DSI PHY children
sub-blocks. Establish the link between MDP5's INTF1 output port and DSI's
input port.
Cc: Andy Gross
Cc: Rob Herring
Cc: devicetree at vger.kernel.org
The APQ8016-sbc provides a HDMI output. The APQ8016 display block only
provides a MIPI DSI output. So, the board has a ADV7533 DSI to HDMI
encoder chip that sits between the DSI PHY output and the HDMI
connector.
Add the ADV7533 DT node under its I2C control bus, and tie the DSI
output port to the
On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote:
> Rockchip VOP couldn't output YUV video format for eDP controller, so
> when driver detect connector support YUV video format, we need to hack
> it down to RGB888.
>
> Signed-off-by: Yakir Yang
> Acked-by: Mark Yao
> ---
> Changes in v3:
> - Ho
On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote:
> The hardware IC designed that VOP must output the RGB10 video format to
> eDP contoller, and if eDP panel only support RGB8, then eDP contoller
> should cut down the video data, not via VOP contoller, that's why we need
> to hardcode the VOP out
On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote:
> The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
> send drm hp event when the irq_type and the enum value is true.
>
> if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
> drm_helper_hpd_irq_event(dp->drm_dev);
>
> So there
On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote:
> eDP controller need to declare which vop provide the video source,
> and it's defined in GRF registers.
>
> But different chips have different GRF register address, so we need to
> create a device data to declare the GRF messages for each chips.
On Tue, Jun 14, 2016 at 7:46 AM, Yakir Yang wrote:
> There're an register define error in ANALOGIX_DP_PLL_REG_1 which introduced
> by commit bcec20fd5ad6 ("drm: bridge: analogix/dp: add some rk3288 special
> registers setting").
>
> The PHY PLL input clock source is selected by ANALOGIX_DP_PLL_REG
The vGEM mmap code has bitrotted slightly and now immediately BUGs.
Since vGEM was last updated, there are new core GEM facilities to
provide more common functions, so let's use those here.
v2: drm_gem_free_mmap_offset() is performed from
drm_gem_object_release() so we can remove the redundant cal
Enable the standard GEM dma-buf interface provided by the DRM core, but
only for exporting the VGEM object. This allows passing around the VGEM
objects created from the dumb interface and using them as sources
elsewhere. Creating a VGEM object for a foriegn handle is not supported.
v2: With additi
vGEM buffers are useful for passing data between software clients and
hardware renders. By allowing the user to create and attach fences to
the exported vGEM buffers (on the dma-buf), the user can implement a
deferred renderer and queue hardware operations like flipping and then
signal the buffer r
regards,
Rui
--
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/20160623/96be1485/attachment.html>
On Thu, Jun 23, 2016 at 9:13 AM, Archit Taneja
wrote:
> The DSI host and PHY driver currently expects the DT bindings to provide
> custom properties "qcom,dsi-host-index" and "qcom,dsi-phy-index" so that
> the driver can identify which DSI instance it is.
>
> The binding isn't acceptable, but the
_to_cpu and
> friends)? If not, maybe it would be an interesting GSoC project, assuming
> such patches were accepted?
Yes, endian swap helpers exist in mesa.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment
From: Gustavo Padovan
Hi all,
This is an attempt to improve fence support on Sync File. The basic idea
is to have only sync_file->fence and store all fences there, either as
normal fences or fence_arrays. That way we can remove some potential
duplication when using fence_array with sync_file: th
From: Gustavo Padovan
When using fences in sync files we need to clean up everything when
the sync file needs to be freed, thus we need to teardown fence_array,
by removing the callback of its fences and putting extra references to the
fence_array base fence.
Signed-off-by: Gustavo Padovan
---
From: Gustavo Padovan
get_fences() should return a copy of all fences in the fence as some
fence subclass (such as fence_array) can store more than one fence at
time.
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/fence.c | 14 ++
include/linux/fence.h | 3 +++
2 files chang
From: Gustavo Padovan
fence_array requires a function to clean up its state before we
are able to call fence_put() and release it.
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/fence.c | 7 +++
include/linux/fence.h | 7 +++
2 files changed, 14 insertions(+)
diff --git a/driver
From: Gustavo Padovan
This function returns a copy of the array of fences.
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/fence-array.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/dma-buf/fence-array.c b/drivers/dma-buf/fence-array.c
index 601448a..ce98249 1
From: Gustavo Padovan
Create sync_file->fence to abstract the type of fence we are using for
each sync_file. If only one fence is present we use a normal struct fence
but if there is more fences to be added to the sync_file a fence_array
is created.
This behaviour is transparent all sync_file fu
The Display Port Auxiliary (DPAUX) channel pads can be shared with an
internal I2C controller. Add pinctrl support for these pads so that the
I2C controller can request and use these pads.
This series has been tested with Thierry's patches for correcting the
parent clock for the DPAUX devices [0].
When registering the Tegra power partitions with the generic PM domain
framework, the current state of the each partition is checked and used
as the default state for the partition. However, the state of each reset
associated with the partition is not initialised and so it is possible
that the stat
If the probing of the DPAUX fails, then clocks are left enabled and the
DPAUX reset de-asserted. Add code to perform the necessary clean-up on
probe failure by disabling clocks and asserting the reset.
Signed-off-by: Jon Hunter
---
drivers/gpu/drm/tegra/dpaux.c | 22 --
1 fil
In preparation for adding pinctrl support for the DPAUX pads, add
helpers functions for configuring the pads and controlling the power
for the pads.
Please note that although a simple if-statement could be used instead
of a case statement for configuring the pads as there are only two
possible mod
Update the DPAUX compatibility string information for Tegra124, Tegra132
and Tegra210.
Signed-off-by: Jon Hunter
---
.../devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/di
To utilise the DPAUX on Tegra, the SOR power partition must be enabled.
Now that Tegra supports the generic PM domain framework we manage the
SOR power partition via this framework for DPAUX. However, the sequence
for gating/ungating the SOR power partition requires that the DPAUX
reset is asserted
The pinconf-generic.h file exposes functions for creating generic mappings
but it does not expose a function for freeing the mappings. Add a function
for freeing generic mappings.
Signed-off-by: Jon Hunter
Acked-by: Linus Walleij
---
drivers/pinctrl/pinconf-generic.c | 8
include
The I2C driver core for boards using device-tree assumes any subnode of
an I2C adapter in the device-tree blob as being a I2C slave device.
Although this makes complete sense, some I2C adapters may have subnodes
which are not I2C slaves but subnodes presenting other features. For
example some Tegra
1 - 100 of 119 matches
Mail list logo
