On 04/25/2016 11:18 PM, twp at codeaurora.org wrote:
> On 2016-04-25 03:16, Archit Taneja wrote:
>> Calling the legacy gpio_free on an invalid GPIO (a GPIO numbered -1)
>> results in kernel warnings. This causes a lot of backtraces when
>> we try to unload the drm/m
calls. The first patch
adds some more clean up code to Mark's original patch.
Archit Taneja (3):
drm/msm/dsi: Fix regulator API abuse
drm/msm/edp: Drop regulator_set_voltage call
drm/msm/mdp4: Don't manage DSI PLL regulators in MDP driver
drivers/gpu/drm/msm/dsi/dsi.h
to set voltages any more. Mention in
comments the voltages that each regulator expects.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/dsi/dsi.h | 2 --
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 34 -
drivers/gpu/drm/msm/dsi/dsi_host.c
needs to change the voltage during runtime. Drop the
regulator_set_voltage call. Mention in a comment the voltage that the
regulator expects.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/edp/edp_ctrl.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gp
should be specified on the
regulator via DT and managed by the regulator core.
Remove all the DSI PLL regulator related code from the MDP4 driver. It's
managed in the DSI driver for MSM8960/APQ8064 already.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp4/
On 8/4/2016 1:36 AM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Tuesday 19 Jul 2016 12:06:41 Archit Taneja wrote:
>> Hi Dave,
>>
>> This is an update to the previous drm bridge pull request. The ADV7511
>> driver's conversion from slave encoder to bridge me
Hi,
On 08/09/2016 10:11 PM, Peter Senna Tschudin wrote:
> Add a driver that create a drm_bridge and a drm_connector for the LVDS
> to DP++ display bridge of the GE B850v3.
>
> There are two physical bridges on the video signal pipeline: a
> STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The har
ghtly,
> so:
> Tested-by: Yakir Yang
>
> Also add Archit into CC list, guess this patch should go through his
> drm_bridge's tree.
Reviewed-by: Archit Taneja
>
> Thanks,
> - Yakir
>
>> ---
>>
>> Changes in v2:
>> - Added panel_i
tform driver to implement
> the PSR function in hardware side:
> - analogix_dp_active_psr()
> - analogix_dp_inactive_psr()
Could this in any way mess things up if the dev_type is EXYNOS_DP?
Otherwise,
Reviewed-by: Archit Taneja
>
> Signed-off-by: Yakir Yang
> Reviewed-by:
On 11/30/2016 03:53 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Wednesday 30 Nov 2016 10:35:02 Archit Taneja wrote:
>> On 11/29/2016 11:27 PM, Laurent Pinchart wrote:
>>> On Tuesday 29 Nov 2016 15:57:06 Archit Taneja wrote:
>>>> On 11/29/2016 02:34 PM, L
On 11/30/2016 4:35 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Wednesday 30 Nov 2016 16:30:53 Archit Taneja wrote:
>> On 11/30/2016 03:53 PM, Laurent Pinchart wrote:
>>> On Wednesday 30 Nov 2016 10:35:02 Archit Taneja wrote:
>>>> On 11/29/2016 11:27
Hi Maxime,
On 09/30/2016 08:07 PM, Maxime Ripard wrote:
> Some boards have an entirely passive RGB to VGA bridge, based on either
> DACs or resistor ladders.
>
> Those might or might not have an i2c bus routed to the VGA connector in
> order to access the screen EDIDs.
>
> Add a bridge that doesn'
On 09/27/2016 06:58 PM, Sean Paul wrote:
> On Fri, Sep 23, 2016 at 10:06 AM, Tomeu Vizoso
> wrote:
>> So users know whether PSR should be enabled or not.
>>
>> Signed-off-by: Tomeu Vizoso
>> Cc: Sean Paul
>> Cc: Yakir Yang
>> Cc: Archit Taneja
>
w
>> times.
>>
>> Signed-off-by: Tomeu Vizoso
>
> Thanks for digging into this.
>
> Reviewed-by: Sean Paul
>
queued to drm-misc.
Archit
>
>
>> Cc: Sean Paul
>> Cc: Yakir Yang
>> Cc: Archit Taneja
>> ---
>> drivers/g
On 10/06/2016 02:47 PM, Daniel Vetter wrote:
> On Thu, Oct 06, 2016 at 11:02:58AM +0200, Andrzej Hajda wrote:
>> Hi Daniel, Archit,
>>
>> On 30.09.2016 12:33, Andrzej Hajda wrote:
>>> On 30.09.2016 12:07, Daniel Vetter wrote:
>>>> On Fri, Sep 30, 201
On 10/06/2016 12:51 PM, Maxime Ripard wrote:
> Hi Archit,
>
> On Mon, Oct 03, 2016 at 04:40:57PM +0530, Archit Taneja wrote:
>> Hi Maxime,
>>
>> On 09/30/2016 08:07 PM, Maxime Ripard wrote:
>>> Some boards have an entirely passive RGB to VGA bridge, based on
On 10/07/2016 02:34 AM, Laurent Pinchart wrote:
> Hi Sean,
>
> On Thursday 06 Oct 2016 15:53:28 Sean Paul wrote:
>> On Thu, Oct 6, 2016 at 1:27 PM, Laurent Pinchart wrote:
>>> On Thursday 06 Oct 2016 17:09:57 Archit Taneja wrote:
>>>> On 10/06/2016 12:51 P
On 10/07/2016 02:44 PM, Maxime Ripard wrote:
> On Fri, Oct 07, 2016 at 10:27:31AM +0530, Archit Taneja wrote:
>>
>>
>> On 10/07/2016 02:34 AM, Laurent Pinchart wrote:
>>> Hi Sean,
>>>
>>> On Thursday 06 Oct 2016 15:53:28 Sean Paul wrote:
>&
On 10/10/2016 12:45 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Monday 10 Oct 2016 11:05:10 Archit Taneja wrote:
>> On 10/07/2016 02:44 PM, Maxime Ripard wrote:
>>> On Fri, Oct 07, 2016 at 10:27:31AM +0530, Archit Taneja wrote:
>
> [snip]
>
>>>>
Hi Brian,
On 10/11/2016 08:23 PM, Brian Starkey wrote:
> Hi,
>
> This RFC series introduces a new connector type:
> DRM_MODE_CONNECTOR_WRITEBACK
> It is a follow-on from a previous discussion: [1]
>
> Writeback connectors are used to expose the memory writeback engines
> found in some display con
_check() and assign the stages appropriately.
The patch looks good. I couldn't test the problematic scenario since I
don't have an easy way to reproduce it, but it doesn't break regular
usage (where base layer is full screen).
Reviewed-by: Archit Taneja
>
> Signed-off-by: R
Hi,
On 10/14/2016 6:57 PM, Eugeniy Paltsev wrote:
> ARC PGU driver starts crashing on initialization after
> 'commit e12c2f645557 ("drm/i2c: adv7511: Convert to drm_bridge")'
> This happenes because in "arcpgu_drm_hdmi_init" function we get pointer
> of "drm_i2c_encoder_driver" structure, which do
On 10/13/2016 10:18 PM, Rob Clark wrote:
> If the bottom-most layer is not fullscreen, we need to use the BASE
> mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT). The
> blend_setup() code pretty much handled this already, we just had to
> figure this out in _atomic_check() and a
On 10/15/2016 5:02 PM, Rob Clark wrote:
> On Sat, Oct 15, 2016 at 5:39 AM, Archit Taneja
> wrote:
>>
>> On 10/13/2016 10:18 PM, Rob Clark wrote:
>>>
>>> If the bottom-most layer is not fullscreen, we need to use the BASE
>>> mixer stage for soli
On 10/15/2016 6:38 PM, Rob Clark wrote:
> On Sat, Oct 15, 2016 at 8:57 AM, Archit Taneja
> wrote:
>>
>>
>> On 10/15/2016 5:02 PM, Rob Clark wrote:
>>>
>>> On Sat, Oct 15, 2016 at 5:39 AM, Archit Taneja
>>> wrote:
>>>>
>>>
Hi,
On 10/18/2016 04:11 AM, Laurent Pinchart wrote:
> Hello,
>
> Various pieces of information about DRM formats (number of planes, color
> depth, chroma subsampling, ...) are scattered across different helper
> functions in the DRM core. Callers of those functions often need to access
> more than
driver to be able work with drm bridge hdmi encoder
> interface. The hdmi connector code isn't needed anymore as we expect
> the adv7511 bridge driver to create/manage the connector.
Looks good now.
Reviewed-by: Archit Taneja
>
> Signed-off
Hi.,
On 10/19/2016 6:37 PM, Sharma, Jitendra wrote:
> Hi Laurent,
>
>
> On 10/19/2016 5:21 PM, Laurent Pinchart wrote:
>> Hi Jitendra,
>>
>> Thank you for the patch.
>>
>> On Wednesday 19 Oct 2016 17:12:48 Jitendra Sharma wrote:
>>> Remove redundant condition check
>>> Remove not necessary if-else
On 10/20/2016 01:50 PM, Laurent Pinchart wrote:
> Hi Russell,
>
> On Wednesday 19 Oct 2016 10:35:21 Russell King - ARM Linux wrote:
>> On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote:
>>> On Wednesday 19 Oct 2016 10:11:22 Russell King - ARM Linux wrote:
In any case, I don't
On 10/20/2016 02:45 PM, Russell King - ARM Linux wrote:
> On Thu, Oct 20, 2016 at 02:38:25PM +0530, Archit Taneja wrote:
>>
>>
>> On 10/20/2016 01:50 PM, Laurent Pinchart wrote:
>>> Hi Russell,
>>>
>>> On Wednesday 19 Oct 2016 10:35:21 Russell King
Hi,
On 10/19/2016 07:55 PM, Laurent Pinchart wrote:
> The drm_bridge object models on- or off-chip hardware encoders and
> provide an abstract control API to display drivers. In order to help
> display drivers creating the right kind of drm_encoder object, expose
> the type of the hardware encoder
On 10/19/2016 07:55 PM, Laurent Pinchart wrote:
> The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be
> controlled through a power save pin, and requires a power supply.
> However, on most boards where the device is used neither the power save
> signal nor the power supply are co
On 10/19/2016 07:55 PM, Laurent Pinchart wrote:
> The LVDS encoder driver is a DRM bridge driver that supports the
> parallel to LVDS encoders that don't require any configuration. The
> driver thus doesn't interact with the device, but creates an LVDS
> connector for the panel and exposes its si
On 10/21/2016 03:52 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Friday 21 Oct 2016 10:43:34 Archit Taneja wrote:
>> On 10/19/2016 07:55 PM, Laurent Pinchart wrote:
>>> The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be
>>> controlled through
On 03/28/2017 07:02 PM, Jyri Sarha wrote:
On 03/27/17 08:58, Archit Taneja wrote:
Hi,
On 03/07/2017 03:21 AM, Christopher Spinrath wrote:
Hi Fabio,
On 03/06/2017 10:46 PM, Fabio Estevam wrote:
Hi Christopher,
On Mon, Mar 6, 2017 at 6:40 PM,
wrote:
From: Christopher Spinrath
On some
Hi,
On 03/31/2017 07:55 PM, Neil Armstrong wrote:
The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
in combination with a very custom PHY.
Thanks to Laurent Pinchart's changes, the HW report the following :
Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy)
On 03/30/2017 01:49 PM, Peter Senna Tschudin wrote:
Reordering of the device nodes based on unit address resulted in
ge_b850v3_lvds_attach() being called before
ge_b850v3_lvds_ptr->stdp4028_i2c was populated.
This patch moves the drm bridge initialization from
ge_b850v3_lvds_init() to stdp4028
Add Laurent and Andrzej as maintainers for DRM bridge chip drivers. They
actively review and contribute to bridge drivers and the bridge API.
Cc: Laurent Pinchart
Cc: Andrzej Hajda
Signed-off-by: Archit Taneja
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b
Hi Laurent,
On 4/6/2017 2:40 PM, Laurent Pinchart wrote:
Hi Archit,
On Wednesday 05 Apr 2017 16:53:50 Archit Taneja wrote:
Add Laurent and Andrzej as maintainers for DRM bridge chip drivers. They
actively review and contribute to bridge drivers and the bridge API.
How about adding me as a
plat_data->input_bus_encoding too?
You might want to rephrase it as the "default color space", or
something along those lines.
This patch changes the if test to > 0.
The change technically makes the if statement check for a
non-zero value.
Reviewed-by: Archit Taneja
Feel free
Hi,
On 4/7/2017 5:47 PM, Romain Perier wrote:
This helper is supposed to validate or reject the modeline before it
applied by the mode setting. Currently this function has been dropped,
it was previously set to a dummy function that always returned true. For
both cases, this means that userspace
Hi,
On 04/07/2017 07:49 PM, Romain Perier wrote:
This set of patches split the stream handling functions in two parts. It
introduces new callbacks that are specific to each variant, one for I2S
and one for AHB.
Then, as requested by the datasheet for the I2S variant, it adds support
for gating
Add Laurent as a reviewer and Andrzej as a maintainer for DRM bridge chip
drivers. They actively review and contribute to bridge drivers and the
bridge API.
Acked-by: Andrzej Hajda
Acked-by: Laurent Pinchart
Acked-by: Sean Paul
Signed-off-by: Archit Taneja
---
v2:
- Collected Acks. Changed
On 04/08/2017 12:03 AM, Daniel Vetter wrote:
On Fri, Apr 07, 2017 at 02:17:43PM +0200, Romain Perier wrote:
This helper is supposed to validate or reject the modeline before it
applied by the mode setting. Currently this function has been dropped,
it was previously set to a dummy function that
Hi,
On 04/04/2017 12:27 AM, Laura Abbott wrote:
Now that we call dma_map in the dma_buf API callbacks there is no need
to use the existing cache APIs. Remove the sync ioctl and the existing
bad dma_sync calls. Explicit caching can be handled with the dma_buf
sync API.
We could get rid of the I
Hi,
On 04/04/2017 12:27 AM, Laura Abbott wrote:
The new method of syncing with dma_map means that the page faulting sync
implementation is no longer applicable. Remove it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 117 --
1 file ch
there. For now this is good enough I
think.
All true.
Reviewed-by: Daniel Stone
Thanks for this, Daniel!
Reviewed-by: Sumit Semwal
Acked-by: Archit Taneja
Thanks,
Archit
Best,
Sumit.
Cheers,
Daniel
___
dri-devel mailing list
dri-
On 04/14/2017 02:01 PM, Romain Perier wrote:
Currently, CTS+N is forced to zero as a workaround of the IP block for
i.MX platforms. This is requested in the datasheet of the corresponding
IP for AHB mode only. However, we have seen that it introduces glitches
or delays when playing a sound on H
On 04/14/2017 02:01 PM, Romain Perier wrote:
Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
step E. and is kept enabled for later use. This clock should be enabled
and disabled along with the actual audio stream and not always on (that
is bad for PM). Futhermore, as descr
:
Tested-by: Archit Taneja
Thanks,
Archit
Jordan Crouse (6):
drm/msm: Add a quick and dirty PIL loader
drm/msm: gpu: Use the zap shader on 5XX if we can
drm/msm: Improve the zap shader
drm/msm: Create a child device for the zap shader
drm/msm: Move zap shader firmware name to the device
On 04/19/2017 10:21 AM, Archit Taneja wrote:
On 04/14/2017 02:01 PM, Romain Perier wrote:
Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
step E. and is kept enabled for later use. This clock should be enabled
and disabled along with the actual audio stream and not
Hi,
On 04/27/2017 10:06 PM, Eric Anholt wrote:
Many DRM drivers have common code to make a stub connector
implementation that wraps a drm_panel. By wrapping the panel in a DRM
bridge, all of the connector code (including calls during encoder
enable/disable) goes away.
Signed-off-by: Eric Anhol
On 05/03/2017 10:00 PM, Eric Anholt wrote:
Archit Taneja writes:
Hi,
On 04/27/2017 10:06 PM, Eric Anholt wrote:
Many DRM drivers have common code to make a stub connector
implementation that wraps a drm_panel. By wrapping the panel in a DRM
bridge, all of the connector code (including
On 01/23/2017 04:03 PM, Andrzej Hajda wrote:
On 23.01.2017 09:31, Archit Taneja wrote:
On 01/20/2017 01:08 PM, Andrzej Hajda wrote:
Due to asynchronous nature of MHL flow of execution is dispersed. Logical
continuation of some actions happens after response of peer, i.e in interrupt
handler
On 01/23/2017 04:42 PM, Andrzej Hajda wrote:
On 23.01.2017 10:17, Archit Taneja wrote:
On 01/20/2017 01:08 PM, Andrzej Hajda wrote:
MHL3 protocol requires registry adjustments depending on chosen video mode.
Necessary information is gathered in mode_fixup callback. In case of HDMI
video
On 01/20/2017 01:08 PM, Andrzej Hajda wrote:
MHL3 requires that after reading EDID from the sink source should ask
peer for features. To make both protocols happy the patch splits the code
accordingly.
I was wondering about the EDID code in the driver, what does it exactly
do with the EDID? W
ephen Boyd
Signed-off-by: Archit Taneja
---
v2:
- Use clk_hw_register/add_hw_provider funcs instead
- Fix some build warnings on arm32 caught by kbuild
drivers/gpu/drm/msm/Kconfig|7 +
drivers/gpu/drm/msm/Makefile |2 +
drivers/gpu/drm/msm/dsi/dsi.h
g).
Also some minor drive-by polish where it makes sense, I read a lot
of docs ...
This seems like a leftover from the older version of the patch, which
we decided to not take. I guess we could drop it.
Archit
Cc: Archit Taneja
Cc: Jani Nikula
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
On 01/24/2017 05:09 PM, Andrzej Hajda wrote:
On 24.01.2017 11:31, Archit Taneja wrote:
On 01/20/2017 01:08 PM, Andrzej Hajda wrote:
MHL3 requires that after reading EDID from the sink source should ask
peer for features. To make both protocols happy the patch splits the code
accordingly.
I
On 01/26/2017 07:20 PM, Andrzej Hajda wrote:
MHL3 protocol uses vendor specific infoframes to transmit additional
information to the sink. This patch adds definitions of structures and
constants used to create such frames.
Signed-off-by: Andrzej Hajda
---
include/drm/bridge/mhl.h | 32 ++
On 01/30/2017 10:35 PM, Jani Nikula wrote:
On Sat, 28 Jan 2017, Peter Senna Tschudin wrote:
On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote:
Hi Archit,
Thank you for the comments!
[...]
+ total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH;
+ if
Herring
Cc: Fabio Estevam
Cc: David Airlie
Cc: Thierry Reding
Cc: Thierry Reding
Cc: Archit Taneja
Cc: Enric Balletbo
Signed-off-by: Peter Senna Tschudin
---
drivers/gpu/drm/bridge/Kconfig | 11 +
drivers/gpu/drm/bridge/Makefile| 1 +
.../drm/bridge/me
On 02/01/2017 01:17 PM, Andrzej Hajda wrote:
Hi Archit,
Sorry for spamming, forgot to add the list.
This quite big patchset adds support for 4K Ultra HD modes in SiI8620 MHL
bridge.
To support it full MHL3 protocol and its sub-protocols should be implemented.
Patchset contains also various f
On 02/01/2017 05:51 PM, Peter Senna Tschudin wrote:
On 01 February, 2017 12:35 CET, Daniel Vetter wrote:
On Wed, Feb 01, 2017 at 10:58:43AM +, Peter Senna Tschudin wrote:
Hi Archit,
On 01 February, 2017 10:44 CET, Archit Taneja wrote:
On 01/30/2017 10:35 PM, Jani Nikula wrote
k;
+ }
This check isn't needed. As of now, we don't create a fbdev device if we don't
have kms initialized.
Otherwise,
Reviewed-by: Archit Taneja
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
On 02/11/2017 10:47 AM, Dan Carpenter wrote:
Hello Hai Li,
This is a semi-automatic email about new static checker warnings.
The patch b62aa70a98c5: "drm/msm/dsi: Move PHY operations out of
host" from Jan 7, 2017, leads to the following Smatch complaint:
./drivers/gpu/drm/msm/dsi/dsi_manager
pending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.
For the bridge drivers:
Reviewed-by: Archit Taneja
Thanks,
Archit
Signed-off-by: Rob Herring
---
v2:
- fix wrong node ptr in imx-ldb
- build fixes in kirin and imx drivers
drive
kernel is not a
DT validator.
For the msm and adv75xx driver:
Tested by: Archit Taneja
Signed-off-by: Rob Herring
Acked-by: Neil Armstrong
Acked-by: Philipp Zabel
Tested-by: Liviu Dudau
Tested-by: Eric Anholt
---
v2:
- tilcdc fix (Jyri Sarha)
- Dropped an incomplete meson change.
drive
On 02/10/2017 12:35 AM, Rob Herring wrote:
Many drivers have a common pattern of searching the OF graph for either an
attached panel or bridge and then finding the DRM struct for the panel
or bridge. Also, most drivers need to handle deferred probing when the
DRM device is not yet instantiated.
On 2/9/2017 8:55 PM, Wei Yongjun wrote:
From: Wei Yongjun
Fixes the following sparse warning:
drivers/gpu/drm/bridge/ti-tfp410.c:223:24: warning:
symbol 'tfp410_platform_driver' was not declared. Should it be static?
This was queued to drm-misc-next
Thanks,
Archit
Signed-off-by: Wei Y
Hi,
On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:
It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper fun
m_dsi) corresponding to the current bridge.
Usage of the wrong DSI pointer also resulted in a static checker
warning. That too is resolved with this fix.
Fixes: b62aa70a98c5 (drm/msm/dsi: Move PHY operations out of host)
Reported-by: Dan Carpenter
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/ms
On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
Hi,
On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:
It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP
On 02/22/2017 05:31 AM, Pandiyan, Dhinakaran wrote:
On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:
On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
Hi,
On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:
It is necessary
A couple of the kms functions didn't have the correct/newest names.
This prevented them to be identified as refs in the html doc.
Signed-off-by: Archit Taneja
---
include/drm/drm_mode_config.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/includ
On 2/24/2017 7:11 PM, Eric Engestrom wrote:
On Wednesday, 2017-02-22 14:17:41 +0530, Archit Taneja wrote:
A couple of the kms functions didn't have the correct/newest names.
This prevented them to be identified as refs in the html doc.
Signed-off-by: Archit Taneja
Thanks!
Review
On 02/27/2017 03:17 AM, Daniel Vetter wrote:
On Sun, Feb 26, 2017 at 07:14:07PM +0530, Archit Taneja wrote:
On 2/24/2017 7:11 PM, Eric Engestrom wrote:
On Wednesday, 2017-02-22 14:17:41 +0530, Archit Taneja wrote:
A couple of the kms functions didn't have the correct/newest names.
;funcs is also
non-NULL. This is needed for MDP5, since during msm_drm_int(), priv->kms
becomes non-NULL early, but msm_kms_init() is called on it only later
in mdp5_kms_init().
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/msm_drv.c | 2 +-
drivers/gpu/drm/msm/msm_gem_sh
>pdev = pdev;
>
> + drm_modeset_lock_init(&mdp5_kms->state_lock);
> + mdp5_kms->state = kzalloc(sizeof(*mdp5_kms->state), GFP_KERNEL);
> + if (!mdp5_kms->state) {
> + ret = -ENOMEM;
> + goto fail;
> + }
> +
This would pro
Hi,
Minor comments below. LGTM otherwise.
On 11/05/2016 09:56 PM, Rob Clark wrote:
> (re)assign the hw pipes to planes based on required caps, and to handle
> situations where we could not modify an in-use plane (ie. SMP block
> reallocation).
>
> This means all planes advertise the superset of f
N layer-mixers (LM). The first N planes become primary
> + * planes for the CRTCs, with the remainder as overlay planes:
> + */
Jfyi, we might need to change this a bit in the future. It'll be better to
get the max number of displays connected on our platform via parsing D
On 11/7/2016 8:18 PM, Rob Clark wrote:
> On Mon, Nov 7, 2016 at 5:38 AM, Archit Taneja
> wrote:
>>
>>
>> On 11/05/2016 09:55 PM, Rob Clark wrote:
>>>
>>> Split out the hardware pipe specifics from mdp5_plane. To start, the hw
>>> pipes are
Hi Jitao,
I couldn't locate the original mail, so posting on this thread instead.
Some comments below.
On 11/10/2016 10:09 PM, Enric Balletbo Serra wrote:
> Hi Jitao,
>
> 2016-08-27 8:44 GMT+02:00 Jitao Shi :
>> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
>>
>> Signed-off
Hi,
On 11/14/2016 07:11 PM, Jitao Shi wrote:
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
Thanks for the incorporating the fixes. I have commented on one issue
below.
The only thing that seems to be left now is the firmware update bits, right?
Can we get the firmware
On 11/15/2016 10:39 PM, Sean Paul wrote:
> On Thu, Nov 3, 2016 at 3:17 AM, Jianqun Xu wrote:
>> Reference from drm_dp_aux description (about transfer):
>> Upon success, the implementation should return the number of payload bytes
>> that were transferred, or a negative error-code on failure. Hel
Hi,
On 11/15/2016 08:29 AM, Chen-Yu Tsai wrote:
> Hi,
>
> On Wed, Nov 2, 2016 at 9:33 AM, Chen-Yu Tsai wrote:
>> On Mon, Oct 31, 2016 at 2:28 PM, Rob Herring wrote:
>>> On Sat, Oct 29, 2016 at 07:06:10PM +0800, Chen-Yu Tsai wrote:
Some dumb VGA DACs are active components which require exter
On 11/16/2016 07:38 PM, Daniel Vetter wrote:
> Again something that's in the drm-misc fold.
Acked-by: Archit Taneja
>
> Cc: Archit Taneja
> Signed-off-by: Daniel Vetter
> ---
> MAINTAINERS | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/M
.
Remove the extra of_node_put calls. This fixes warnings seen when
we try to insert the driver as a module on IFC6410.
Reported-by: Ilia Mirkin
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/msm_drv.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm
Hi,
Thanks for the patch.
On 11/16/2016 09:12 PM, Chen-Yu Tsai wrote:
> Some dumb VGA DACs are active components which require external power.
> Add support for specifying a regulator as its power supply.
>
> Signed-off-by: Chen-Yu Tsai
> Acked-by: Rob Herring
> ---
> .../bindings/display/brid
On 11/17/2016 01:08 PM, Daniel Vetter wrote:
> There's a really big pile of additional connector properties, a lot of
> them standardized. But they're all for specific outputs (panels, TV,
> scaling, ...) so I left them out for now since this is enough for a
> start.
>
> I typed this to give Mana
On 11/17/2016 01:25 PM, Chen-Yu Tsai wrote:
> On Thu, Nov 17, 2016 at 3:48 PM, Archit Taneja
> wrote:
>> Hi,
>>
>> Thanks for the patch.
>>
>>
>> On 11/16/2016 09:12 PM, Chen-Yu Tsai wrote:
>>>
>>> Some dumb VGA DACs are active
t;
> I typed this to give Manasi a place to add her new link status
> property documentation.
Reviewed-by: Archit Taneja
>
> v2: forgot to git add all the bits (Manasi).
>
> v3: Be more epxlicit about integrated tiled panels (Archit)
>
> Cc: Manasi Navare
&g
On 11/23/2016 01:16 AM, John Stultz wrote:
> On Tue, Nov 22, 2016 at 9:38 AM, Laurent Pinchart
> wrote:
>> Hi John,
>>
>> On Tuesday 22 Nov 2016 09:25:22 John Stultz wrote:
>>> On Tue, Nov 22, 2016 at 12:14 AM, Laurent Pinchart wrote:
On Monday 21 Nov 2016 16:37:30 John Stultz wrote:
>>> @
Hi,
On 11/24/2016 10:43 AM, Kuninori Morimoto wrote:
>
> Hi Archit, David, and DRM ML
>
> I had heared that Archit is the maintainer of dw-hdmi driver, but am I wrong
> ??
> I'm posting this patch series since half year ago, but no response
> from him, and nothing happen (I got review from Russel
On 11/28/2016 06:37 AM, Kuninori Morimoto wrote:
>
> Hi
>
>> The newly added sound driver depends on SND_SOC_HDMI_CODEC, which in
>> turn only makes sense when ASoC is enabled, as shown by this warning:
>>
>> warning: (DRM_MSM && DRM_STI && DRM_MEDIATEK_HDMI && DRM_I2C_NXP_TDA998X &&
>> DRM_DW_H
lator supply for ADV7511 too in the binding docs.
- Update the driver to manage regulators for both ADV7511 and ADV7533.
- Have separate supply entries for AVDD, DVDD, PVDD, A2VDD pins.
- Use regulator_bulk_* API to configure regulators.
Archit Taneja (2):
dt-bindings: drm/bridge: adv7511: Add regu
Maintain a table of regulator names expect by ADV7511 and ADV7533.
Use regulator_bulk_* api to configure these.
Initialize and enable the regulators during probe itself. Controlling
these dynamically is left for later.
Signed-off-by: Archit Taneja
---
v3:
- Drop the additional 1.8V supply names
: Rob Herring
Signed-off-by: Archit Taneja
---
v3:
- Revert back to having a common avdd-supply property for the 1.8V
supplies
Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/display
On 11/29/2016 12:03 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> Thank you for the patch.
>
> On Tuesday 29 Nov 2016 11:37:41 Archit Taneja wrote:
>> Add the regulator supply properties needed by ADV7511 and ADV7533.
>>
>> The regulators are specified as optional
On 11/29/2016 02:34 PM, Laurent Pinchart wrote:
> Instead of linking encoders and bridges in every driver (and getting it
> wrong half of the time, as many drivers forget to set the drm_bridge
> encoder pointer), do so in core code. The drm_bridge_attach() function
> needs the encoder and optiona
1 - 100 of 1388 matches
Mail list logo
