Hi Phillipe,
On Saturday 03 February 2018 03:49 AM, Philippe CORNU wrote:
Hi Archit, Andrzej, Laurent & Brian,
What is your opinion regarding this patch? Do you have any advice for
handling hw versions?
Do not hesitate to comment.
The patch looks mostly good to me. One query below.
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
it to create a connector for us or not. Because,
it looks like both can potentially create connectors. This isn't a big
problem either if we have DT. We just need to check whether our output
port is connected to another bridge or a connector.
Thanks,
Archit
> Cc: Martyn Welch
> Cc: Mar
On 08/09/2016 08:05 AM, Yakir Yang wrote:
> + Archit
>
>
> On 08/09/2016 02:53 AM, Sean Paul wrote:
>> Instead of just preparing the panel on bind, actually prepare/unprepare
>> during modeset/disable. The panel must be prepared in order to read hpd
>> status and
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
ified in the string, we don't need to
specifically mention "bridge" in the string. Also, bridge is a drm
specific term.
- "simple" is considered because it's an unconfigurable bridge, and it
might be misleading for other VGA DACs to not use "vga-dac".
What d
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]
>
>>>>
rspace.
- Besides the above property, writeback hardware can have provisions
for scaling, color space conversion and rotation. This would mean that
we'd eventually add more writeback specific props/params in
drm_connector/drm_connector_state. Would we be okay adding mor
_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
er_slave_funcs;
This should go away too.
> ret = drm_encoder_init(drm, &encoder->base, &arcpgu_drm_encoder_funcs,
> DRM_MODE_ENCODER_TMDS, NULL);
> if (ret)
> @@ -147,37 +95,15 @@ int arcpgu_drm_hdmi_init(struct drm_device *drm,
yer is not fullscreen, we need to use
> + * it for solid-color:
> + */
> + if (!is_fullscreen(state, &pstates[0].state->base))
> + base++;
> +
I get a crash here when fbcon is enabled and there are no connectors
connected. We're tryi
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:
>>>>
>>>
H v2 00/20] OMAP
> DRM fixes and improvements" patch series previously posted.
>
> All patches have been acked, the series is ready to be merged for v4.10.
Queued all patches to drm-misc.
Thanks,
Archit
>
> Changes since v4:
>
> - Rebased on top of latest drm/master branc
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
ntion of this patch is not to change any functionality, also
>>> changes looks simple enough.So, didn't verified Patch v1 over hardware
>> You should *ALWAYS* verify patches before sending them out.
> Will keep in mind
>>
>> I assume you've now properly test
objects as part of the KMS UABI was probably a mistake.
> Better solutions would have been to expose no encoder at all or all encoders
> in the chain. We are however stuck with this model as we can't break the UABI.
> For that reason a DRM encoder object doesn't represent an en
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
when needed without breaking backward
> compatibility.
Shouldn't we have a DT binding doc for ADV7123, even if it's sharing
the dumb vga driver for now?
Same query for the Thine LVDS encoder.
Thanks,
Archit
>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Laurent Pinchart
* published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
&
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
media
changes via the drm-misc branch? If so, I guess we could go ahead
and push the series to drm-misc-next.
Thanks,
Archit
Changes since v5 at [6] :
- Small addition in V4L YUV bus formats documentation
Changes since v4 at [5] :
- Rebased on drm-misc-next at bd283d2f66c2
- Fix 4:2:0 bus fo
to stdp4028_ge_b850v3_fw_probe() ensuring that
ge_b850v3_lvds_ptr->stdp4028_i2c is properly populated.
queued to drm-misc-next
Archit
Signed-off-by: Peter Senna Tschudin
---
drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
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
it in the
bridge's mode_fixup op.
Daniel,
Is it okay to use the connector's atomic_check to validate a mode.
(by peeping into the new_crtc_state->mode?)
Thanks,
Archit
Signed-off-by: Romain Perier
---
drivers/gpu/drm/bridge/dw-hdmi.c | 16
1 file changed, 16 i
git://anongit.freedesktop.org/drm-misc drm-misc-next
The dw-hdmi driver is now under drivers/gpu/drm/bridge/synopsis/
Thanks,
Archit
Romain Perier (2):
drm: dw-hdmi: add specific I2S and AHB functions for stream handling
drm: dw-hdmi: Gate audio clock from the I2S enablement callbacks
driver
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
dge's mode_fixup hook.
Acked-by: Daniel Vetter
queued to drm-misc-next-fixes (so that it makes it into 4.12).
Thanks,
Archit
---
drivers/gpu/drm/bridge/dw-hdmi.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge
ION_FLAG_CACHED_NEEDS_SYNC flag in this patch
too.
Thanks,
Archit
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/compat_ion.c| 1 -
drivers/staging/android/ion/ion-ioctl.c | 6
drivers/staging/android/ion/ion.c | 40
move the vfree(buffer->pages) call in ion_buffer_destroy. In
fact, we
could removes 'pages' member from ion_buffer altogether.
Thanks,
Archit
- if (!buffer->pages) {
- ret = -ENOMEM;
- goto err1;
- }
-
-
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-
set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
+}
+
I get some sparse warnings asking for the above 3 to be static.
Thanks,
Archit
void dw_hdmi_audio_enable(struct dw_hdmi *hdmi)
{
unsigned long flags;
spin_lock_irqsave(&hdmi->audio_lock, flags);
hdm
;
+}
+
+void dw_hdmi_i2s_audio_disable(struct dw_hdmi *hdmi)
+{
+ hdmi_enable_audio_clk(hdmi, false);
}
This should be static too.
If you're okay with the suggestions, I can fix these myself and push. Let
me know if that's okay.
Thanks,
Archit
void dw_hdmi_audio_enable(struct dw_hdmi *hdm
:
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
call drm_panel_prepare() and related functions a bit differently. We won't
be able to use drm_panel_bridge for those drivers.
For msm, we check whether the DSI encoder is connected directly to a panel
or an external bridge. If it's connected to an external bridge, we
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
? We don't seem to be populating connector modes with it.
I saw a func called sii8620_set_upstream_edid(), but didn't understand
what it does.
Archit
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/sil-sii8620.c | 31 +++
1 file changed, 27 insert
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
sequential, left-right */
+ mhl3_3d_format_type_tb_lr /* top-bottom, left-right */
+};
+
Can we keep the enums in caps?
Thanks,
Archit
+struct mhl3_infoframe {
+ unsigned char version;
+ enum mhl3_video_format video_format;
+ enum mhl3_3d_format_type format_type
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
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
} else {
174 msm_dsi_host_reset_phy(mdsi->host);
^^
Unchecked dereference.
This looks like a typo, it should have been msm_dsi->host. Will post a patch
to fix this.
Thanks,
Archit
175
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
to the bridge/panel input port.
Thanks,
Archit
+ * @panel: pointer to hold returned drm_panel
+ * @bridge: pointer to hold returned drm_bridge
+ *
+ * Given a DT node's port and endpoint number, find the connected node and
+ * return either the associated struct drm_panel or drm_bridge dev
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-o
k if the obj_state doesn't already exist. I
don't understand the locking stuff toowell, I just noticed this difference when
comparing this approach with what is done in the msm kms driver (where we
have subclassed drm_atomic_state to msm_kms_state).
Thanks,
Archit
+
+ num_ob
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
t: */
> - bool full_modeset = false;
> - if (state->fb->pixel_format != old_state->fb->pixel_format) {
> - DBG("%s: pixel_format change!", plane->name);
> - full_modeset = true;
> - }
> - if (state->src_w != old_state->src_w) {
> - DBG("%s: src_w change!", plane->name);
> - full_modeset = true;
> - }
> - if (to_mdp5_plane_state(old_state)->pending) {
> - DBG("%s: still pending!", plane->name);
> - full_modeset = true;
> - }
> - if (full_modeset) {
> - struct drm_crtc_state *crtc_state =
> - drm_atomic_get_crtc_state(state->state,
> state->crtc);
> - crtc_state->mode_changed = true;
> + /* (re)assign hwpipe if needed, otherwise keep old one: */
> + if (new_hwpipe) {
> + /* TODO maybe we want to re-assign hwpipe sometimes
> + * in cases when we no-longer need some caps to make
> + * it available for other planes?
> + */
> + struct mdp5_hw_pipe *hwpipe = mdp5_state->hwpipe;
Maybe hwpipe above could be curr_hwpipe or old_hwpipe?
> + mdp5_state->hwpipe =
> + mdp5_pipe_assign(state->state, plane, caps);
> + if (IS_ERR(mdp5_state->hwpipe)) {
> + DBG("%s: failed to assign hwpipe!",
> plane->name);
> + return PTR_ERR(mdp5_state->hwpipe);
> + }
> + mdp5_pipe_release(state->state, hwpipe);
> }
> }
Thanks,
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
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
ge, fw);
>> + if (ret)
>> + return ret;
>> +
>> + mutex_lock(&ps_bridge->fw_mutex);
>> + if (!ps_bridge->in_fw_update) {
>> + if (!ps8640_status_backup)
>> + ps8640_pre_enable
are pushed on the linux-firmware git repo [1]?
Or
Remove the firmware update parts for now (including the SPI stuff,
since that seems to be only used for writing fw)?
[1] http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/
Thanks,
Archit
>
> Signed-off-by:
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
t;> + .disable= dumb_vga_disable,
>>>> };
>>>>
>>>> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>>>> @@ -169,6 +196,14 @@ static int dumb_vga_probe(struct platform_device
>>>> *pd
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
if (ret) {
> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
> + return;
We don't need this return for now. If you're okay with it, can I fix this
and queue to misc?
Thanks,
Archit
> + }
> +}
> +
> +static void dumb
sinks), or high-res integrated panels (like dual-link DSI).
> + * Drivers should update this property using
> + * drm_mode_connector_set_tile_property(). Userspace cannot change this
> + * property.
This contradicts the comment on @tile_blob_ptr in drm_connector.h a bit w.r.t
high-
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
ithout the audio subsystem,
>> adding a dependency here seems the right solution.
>>
>> Fixes: 2761ba6c0925 ("drm: bridge: add DesignWare HDMI I2S audio support")
>> Signed-off-by: Arnd Bergmann
>> ---
>
> Acked-by: Kuninori Morimoto
Added to drm-misc-n
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
1 - 100 of 1389 matches
Mail list logo
