Hi,
On Mon, Mar 25, 2024 at 5:05 PM Hsin-Yi Wang wrote:
>
> On Mon, Mar 25, 2024 at 2:57 PM Douglas Anderson
> wrote:
> >
> > If at boot we fail to power up the eDP panel (most often happens if
> > the eDP panel never asserts HPD to us) or if we are unable to read the
> > EDID at bootup to
Hi,
On Mon, Mar 25, 2024 at 4:52 PM Hsin-Yi Wang wrote:
>
> On Mon, Mar 25, 2024 at 2:56 PM Douglas Anderson
> wrote:
> >
> > If we're using the generic "edp-panel" compatible string and we fail
> > to detect an eDP panel then we fall back to conservative timings for
> > powering up and
Hi,
On Sat, Feb 3, 2024 at 5:47 AM Dmitry Baryshkov
wrote:
>
> Both dp_link_adjust_levels() and dp_ctrl_update_vx_px() limit swing and
> pre-emphasis to 2, while the real maximum value for the sum of the
> voltage swing and pre-emphasis is 3. Fix the DP code to remove this
> limitation.
>
>
Hi,
On Tue, Mar 19, 2024 at 3:45 PM Dmitry Baryshkov
wrote:
>
> On Tue, 19 Mar 2024 at 22:58, Douglas Anderson wrote:
> >
> > In response to my patch removing the "wait for HPD" logic at the
> > beginning of the MSM DP transfer() callback [1], we had some debate
> > about what the "This is an
Hi,
On Sat, Mar 23, 2024 at 7:05 PM Emilio Mendoza Reyes
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> From: Emilio Mendoza Reyes
>
> The patch ("drm/panel: Check for already prepared/enabled in drm_panel")
> moved checking for (en/dis)abled and [un]prepared panels before
Hi,
On Mon, Mar 25, 2024 at 5:59 AM Pin-yen Lin wrote:
>
> Add support for the AUO B120XAN01.0 panel.
>
> Signed-off-by: Pin-yen Lin
> ---
>
> drivers/gpu/drm/panel/panel-edp.c | 1 +
> 1 file changed, 1 insertion(+)
Looks fine.
Reviewed-by: Douglas Anderson
Applied to drm-misc-next:
Hi,
On Sat, Mar 23, 2024 at 10:15 AM kernel test robot wrote:
>
> tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head: 657dd8fcd2f1d1205c6f98fdb8b60915228991d1
> commit: 0885186926a13c697d78f5af03f32445414b6ad5 [4/11] Merge remote-tracking
> branch 'drm-misc/drm-misc-next' into
Hi,
On Thu, Mar 14, 2024 at 3:32 PM Jessica Zhang wrote:
>
> On 3/13/2024 2:12 PM, Douglas Anderson via B4 Relay wrote:
> > From: Douglas Anderson
> >
> > When the atna33xc20 driver was first written the resume code never
> > returned an error. If there was a problem waiting for HPD it just
> >
Hi,
On Tue, Mar 19, 2024 at 1:55 PM Dmitry Baryshkov
wrote:
>
> > -* panel to finish powering on. This is an optional function.
> > +* panel to finish powering on. It is optional for DP AUX
> > controllers
> > +* to implement this function but
Hi,
On Tue, Mar 19, 2024 at 10:27 AM Dmitry Baryshkov
wrote:
>
> On Tue, 19 Mar 2024 at 19:13, Abhinav Kumar wrote:
> >
> >
> >
> > On 3/18/2024 5:55 PM, Dmitry Baryshkov wrote:
> > > On Tue, 19 Mar 2024 at 02:19, Abhinav Kumar
> > > wrote:
> > >>
> > >> +bjorn, johan as fyi for sc8280xp
> >
Hi,
On Mon, Mar 18, 2024 at 12:26 PM Stephen Boyd wrote:
>
> Quoting Douglas Anderson (2024-03-15 14:36:32)
> > This is a no-op change to just fix a typo in the name of a static function.
> >
> > Signed-off-by: Douglas Anderson
> > ---
> >
> > Changes in v2:
> > - ("Fix typo in static function
Hi,
On Wed, Mar 13, 2024 at 1:41 PM Abhinav Kumar wrote:
>
>
>
> On 3/12/2024 5:13 PM, Douglas Anderson wrote:
> > As documented in the description of the transfer() function of
> > "struct drm_dp_aux", the transfer() function can be called at any time
> > regardless of the state of the DP port.
Hi,
On Thu, Mar 7, 2024 at 3:07 PM Hsin-Yi Wang wrote:
>
> This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
> auo_b116xa3_mode""). It's found that 2 different AUO panels use the same
> product id. One of them requires an overridden mode, while the other should
> use the
Hi,
On Thu, Mar 7, 2024 at 1:37 AM Colin Ian King wrote:
>
> The variable out is being initialized and incremented but it is never
> actually referenced in any other way. The variable is redundant and can
> be removed.
>
> Cleans up clang scan build warning:
>
Hi,
On Tue, Mar 12, 2024 at 5:47 PM Guenter Roeck wrote:
>
> On Tue, Mar 12, 2024 at 5:14 PM Douglas Anderson
> wrote:
> >
> > As documented in the description of the transfer() function of
> > "struct drm_dp_aux", the transfer() function can be called at any time
> > regardless of the state
Hi,
On Thu, Mar 7, 2024 at 4:48 PM Xuxin Xiong
wrote:
>
> Add support for the following 2 panels:
> 1. BOE NT116WHM-N44
> 2. CMN N116BCA-EA1
>
> Signed-off-by: Xuxin Xiong
> Reviewed-by: Douglas Anderson
It's fine this time, but please be careful in the future. I never
actually gave you my
Hi,
On Fri, Mar 8, 2024 at 12:07 AM Jani Nikula wrote:
>
> On Thu, 07 Mar 2024, Hsin-Yi Wang wrote:
> > Create a type drm_edid_ident as the identity of an EDID. Currently it
> > contains panel id and monitor name.
> >
> > Create a function that can match a given EDID and an identity:
> > 1.
Hi,
On Thu, Mar 7, 2024 at 3:07 PM Hsin-Yi Wang wrote:
>
> Create a type drm_edid_ident as the identity of an EDID. Currently it
> contains panel id and monitor name.
>
> Create a function that can match a given EDID and an identity:
> 1. Reject if the panel id doesn't match.
> 2. If name is not
Hi,
On Thu, Mar 7, 2024 at 12:28 PM Jani Nikula wrote:
>
> On Thu, 07 Mar 2024, Hsin-Yi Wang wrote:
> > On Thu, Mar 7, 2024 at 5:28 AM Jani Nikula
> > wrote:
> >>
> >> On Wed, 06 Mar 2024, Doug Anderson wrote:
> >> > Hi,
> >> >
Hi,
On Thu, Mar 7, 2024 at 1:44 AM Xuxin Xiong
wrote:
>
> Add support for the following 2 panels:
> 1. BOE NT116WHM-N44
> 2. CMN N116BCA-EA1
>
> Signed-off-by: Xuxin Xiong
> ---
> drivers/gpu/drm/panel/panel-edp.c | 2 ++
> 1 file changed, 2 insertions(+)
The patch looks OK, but please resend
Hi,
On Wed, Mar 6, 2024 at 4:20 PM Hsin-Yi Wang wrote:
>
> On Wed, Mar 6, 2024 at 3:30 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang wrote:
> > >
> > > +static void
> > > +match_
Hi,
On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang wrote:
>
> @@ -1009,6 +1009,19 @@ static const struct panel_desc auo_b101ean01 = {
> },
> };
>
> +static const struct drm_display_mode auo_b116xa3_mode = {
> + .clock = 70589,
> + .hdisplay = 1366,
> + .hsync_start =
Hi,
On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang wrote:
>
> Currently edid quirks are matched by panel id only.
>
> Modify it to match with identity so it's easier to be extended
> for more complex matching if required.
>
> Suggested-by: Jani Nikula
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by:
Hi,
On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang wrote:
>
> @@ -2111,15 +2113,16 @@ static const struct edp_panel_entry edp_panels[] = {
> { /* sentinal */ }
> };
>
> -static const struct edp_panel_entry *find_edp_panel(u32 panel_id)
> +static const struct edp_panel_entry
Hi,
On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang wrote:
>
> +static void
> +match_identity(const struct detailed_timing *timing, void *data)
> +{
> + struct drm_edid_match_closure *closure = data;
> + unsigned int i;
> + const char *name = closure->ident->name;
> +
Hi,
On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang wrote:
>
> drm_edid_get_panel_id() now just directly call edid_extract_panel_id().
>
> Merge them into one function.
>
> Signed-off-by: Hsin-Yi Wang
> ---
> v4->v5: new
> ---
> drivers/gpu/drm/drm_edid.c | 39
Hi,
On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang wrote:
>
> @@ -2764,58 +2764,71 @@ static u32 edid_extract_panel_id(const struct edid
> *edid)
> }
>
> /**
> - * drm_edid_get_panel_id - Get a panel's ID through DDC
> - * @adapter: I2C adapter to use for DDC
> + * drm_edid_get_panel_id - Get a
Hi,
On Wed, Mar 6, 2024 at 6:38 AM Douglas Anderson wrote:
>
> This reverts commit 95bf25bb9ed5dedb7fb39f76489f7d6843ab0475.
>
> Apparently there was a previous discussion about emulation of formats
> and it was decided XRGB was the only format to support for legacy
> userspace [1]. Remove
Hi,
On Wed, Mar 6, 2024 at 4:07 AM Thomas Zimmermann wrote:
>
> Hi,
>
> sorry that I did not see the patch before.
>
> Am 27.02.24 um 23:19 schrieb Douglas Anderson:
> > Even though the UDL driver converts to RGB565 internally (see
> > pixel32_to_be16() in udl_transfer.c), it advertises XRGB
Cong,
On Mon, Mar 4, 2024 at 5:26 PM Cong Yang
wrote:
>
> The current measured frame rate is 59.95Hz, which does not meet the
> requirements of touch-stylus and stylus cannot work normally. After
> adjustment, the actual measurement is 60.001Hz. Now this panel looks
> like it's only used by me
Hi,
On Tue, Mar 5, 2024 at 12:17 AM Jani Nikula wrote:
>
> On Mon, 04 Mar 2024, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Mar 4, 2024 at 4:19 PM Hsin-Yi Wang wrote:
> >>
> >> > > Probably change to u32 drm_edid_get_panel_id(const struct
Hi,
On Tue, Feb 27, 2024 at 3:26 PM Dmitry Baryshkov
wrote:
>
> On Wed, 28 Feb 2024 at 00:19, Douglas Anderson wrote:
> >
> > Even though the UDL driver converts to RGB565 internally (see
> > pixel32_to_be16() in udl_transfer.c), it advertises XRGB for
> > compatibility. Let's add ARGB
Hi,
On Mon, Mar 4, 2024 at 4:19 PM Hsin-Yi Wang wrote:
>
> > > Probably change to u32 drm_edid_get_panel_id(const struct drm_edid
> > > *);? Given that we still need to parse id from
> > > drm_edid_read_base_block().
> >
> > No, we no longer need to parse the id outside of drm_edid.c. You'll
Hi,
On Fri, Mar 1, 2024 at 12:40 AM Zhengqiao Xia
wrote:
>
> For MNC207QS1-1 panel, Splash screen occur when switch from VT1 to VT2.
> The BL_EN signal does not conform to the VESA protocol.
> BL_EN signal needs to be pulled high after video signal.
> So add prepare_to_enable to 200ms.
>
>
Hi,
On Thu, Feb 29, 2024 at 10:11 PM Cong Yang
wrote:
>
> The current measured frame rate is 59.95Hz, which does not meet the
> requirements of touch-stylus and stylus cannot work normally. After
> adjustment, the actual measurement is 60.001Hz. Now this panel looks
> like it's only used by me
Hi,
On Sun, Mar 3, 2024 at 1:30 PM Dmitry Baryshkov
wrote:
>
> > The problem is that Dmitry didn't like the idea of using a hash and in
> > v2 Hsin-Yi has moved to using the name of the display. ...except of
> > course that eDP panels don't always properly specify
> > "EDID_DETAIL_MONITOR_NAME".
Hi,
On Thu, Feb 29, 2024 at 8:43 AM Jani Nikula wrote:
>
> On Wed, 28 Feb 2024, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Feb 27, 2024 at 5:27 PM Hsin-Yi Wang wrote:
> >>
> >> On Tue, Feb 27, 2024 at 1:09 AM Jani Nikula
> >> wrote:
>
Hi,
On Tue, Feb 27, 2024 at 5:11 PM Hsin-Yi Wang wrote:
>
> There are 2 different AUO panels using the same panel id. One of the
> variants requires using overridden modes to resolve glitching issue as
> described in commit 70e0d5550f5c ("drm/panel-edp: Add auo_b116xa3_mode").
> Other variants
Hi,
On Tue, Feb 27, 2024 at 5:11 PM Hsin-Yi Wang wrote:
>
> @@ -2107,13 +2113,41 @@ static const struct edp_panel_entry edp_panels[] = {
> { /* sentinal */ }
> };
>
> -static const struct edp_panel_entry *find_edp_panel(u32 panel_id)
> +static bool edid_has_name(struct edid *edid, const
Hi,
On Tue, Feb 27, 2024 at 5:11 PM Hsin-Yi Wang wrote:
>
> Some panels are interested in the EDID during early probe when connector
> is still unknown.
>
> Add a function drm_get_edid_no_connector() to get edid without connector.
> No functional change for existing usage.
>
> Signed-off-by:
Hi,
On Tue, Feb 27, 2024 at 5:27 PM Hsin-Yi Wang wrote:
>
> On Tue, Feb 27, 2024 at 1:09 AM Jani Nikula
> wrote:
> >
> > On Fri, 23 Feb 2024, Hsin-Yi Wang wrote:
> > > It's found that some panels have variants that they share the same panel
> > > id
> > > although their EDID and names are
Hi,
On Wed, Feb 28, 2024 at 8:52 AM wrote:
>
> On 28/02/2024 17:40, Doug Anderson wrote:
> > Neil,
> >
> > On Thu, Feb 15, 2024 at 8:53 AM Neil Armstrong
> > wrote:
> >>
> >> Hi Doug,
> >>
> >> On 15/02/2024 16:08, Doug Anderson
Neil,
On Thu, Feb 15, 2024 at 8:53 AM Neil Armstrong
wrote:
>
> Hi Doug,
>
> On 15/02/2024 16:08, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Feb 15, 2024 at 2:24 AM Jani Nikula wrote:
> >>
> >> On Wed, 14 Feb 2024, Doug Anderson wrote:
> &
Hi,
On Tue, Feb 27, 2024 at 1:09 AM Jani Nikula wrote:
>
> On Fri, 23 Feb 2024, Hsin-Yi Wang wrote:
> > It's found that some panels have variants that they share the same panel id
> > although their EDID and names are different. Besides panel id, now we need
> > the hash of entire EDID base
Hi,
On Mon, Feb 26, 2024 at 4:37 PM Dmitry Baryshkov
wrote:
>
> On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang wrote:
> >
> > This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
> > auo_b116xa3_mode""). It's found that 2 different AUO panels use the same
> > product id. One of
Hi,
On Mon, Feb 26, 2024 at 2:39 PM Hsin-Yi Wang wrote:
>
> On Mon, Feb 26, 2024 at 2:29 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Fri, Feb 23, 2024 at 2:40 PM Hsin-Yi Wang wrote:
> > >
> > > It's found that some panels have variants that th
Hi,
On Fri, Feb 23, 2024 at 2:40 PM Hsin-Yi Wang wrote:
>
> It's found that some panels have variants that they share the same panel id
> although their EDID and names are different. One of the variants requires
> using overridden modes to resolve glitching issue as described in commit
>
Hi,
On Fri, Feb 23, 2024 at 2:40 PM Hsin-Yi Wang wrote:
>
> @@ -2770,58 +2770,63 @@ static u32 edid_extract_panel_id(const struct edid
> *edid)
> }
>
> /**
> - * drm_edid_get_panel_id - Get a panel's ID through DDC
> - * @adapter: I2C adapter to use for DDC
> + * drm_edid_get_panel_id - Get a
Hi,
On Thu, Feb 22, 2024 at 9:32 AM Dmitry Baryshkov
wrote:
>
> On Thu, 22 Feb 2024 at 17:04, Bjorn Andersson
> wrote:
> >
> > On Thu, Feb 22, 2024 at 11:46:26AM +0200, Dmitry Baryshkov wrote:
> > > On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio
> > > wrote:
> > > >
> > > >
> > > >
> > > > On
Hi,
On Fri, Feb 16, 2024 at 12:21 AM Javier Martinez Canillas
wrote:
>
> > The kernel tree we landed on was the v5.15 tree, which is currently
> > serving all Qualcomm sc7180-based Chromebooks, all Mediatek 8173
> > Chromebooks and all Mediatek 8186 Chromebooks. There are also a pile
> > of x86
Hi,
On Thu, Feb 15, 2024 at 8:53 AM Neil Armstrong
wrote:
>
> Hi Doug,
>
> On 15/02/2024 16:08, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Feb 15, 2024 at 2:24 AM Jani Nikula wrote:
> >>
> >> On Wed, 14 Feb 2024, Doug Anderson wrote:
> &
Hi,
On Wed, Feb 14, 2024 at 1:41 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Feb 13, 2024 at 11:24 PM Hsin-Yi Wang wrote:
> >
> > This reverts commit 70e0d5550f5cec301ad116703b840a539fe985dc.
> >
> > The overridden mode fixes the panel glitching iss
Hi,
On Thu, Feb 15, 2024 at 2:24 AM Jani Nikula wrote:
>
> On Wed, 14 Feb 2024, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Feb 13, 2024 at 10:25 PM Hsin-Yi Wang wrote:
> >>
> >> On Wed, Feb 14, 2024 at 2:23 PM Douglas Anderson
> >>
Hi,
On Tue, Feb 13, 2024 at 10:25 PM Hsin-Yi Wang wrote:
>
> On Wed, Feb 14, 2024 at 2:23 PM Douglas Anderson
> wrote:
> >
> > If an eDP panel is not powered on then any attempts to talk to it over
> > the DP AUX channel will timeout. Unfortunately these attempts may be
> > quite slow.
Hi,
On Tue, Feb 13, 2024 at 11:24 PM Hsin-Yi Wang wrote:
>
> This reverts commit 70e0d5550f5cec301ad116703b840a539fe985dc.
>
> The overridden mode fixes the panel glitching issue on mt8186 chromebook.
> However, it causes the internal display not working on mt8173 chromebook.
> Revert the
Hi,
On Wed, Feb 14, 2024 at 1:34 AM Uwe Kleine-König
wrote:
>
> struct pwm_chip::dev is about to change. To not have to touch this
> driver in the same commit as struct pwm_chip::dev, use the accessor
> function provided for exactly this purpose.
>
> Signed-off-by: Uwe Kleine-König
> ---
>
Hi,
On Fri, Feb 2, 2024 at 12:25 PM Jeffrey Hugo wrote:
>
> The servers for the @codeaurora domain are long retired and any messages
> sent there bounce. Sandeep Panda's email address is no longer valid and
> should be repleaced. However Sandeep has left the company and has not
> been active
Hi,
On Mon, Feb 5, 2024 at 12:13 AM Markus Elfring wrote:
>
> From: Markus Elfring
> Date: Mon, 5 Feb 2024 08:58:21 +0100
>
> A wrapper function is available since the commit
> 890cc39a879906b63912482dfc41944579df2dc6
> ("drivers: provide devm_platform_get_and_ioremap_resource()").
> Thus
Hi,
On Mon, Feb 5, 2024 at 3:17 AM Jani Nikula wrote:
>
> On Fri, 02 Feb 2024, Douglas Anderson wrote:
> > If an eDP panel is not powered on then any attempts to talk to it over
> > the DP AUX channel will timeout. Unfortunately these attempts may be
> > quite slow. Userspace can initiate these
Hi,
On Fri, Feb 2, 2024 at 12:25 PM Jeffrey Hugo wrote:
>
> The servers for the @codeaurora domain are long retired and any messages
> sent there bounce. Sandeep Panda's email address is no longer valid and
> should be repleaced. However Sandeep has left the company and has not
> been active
Hi,
On Fri, Feb 2, 2024 at 10:29 AM Jeffrey Hugo wrote:
>
> Hi Doug,
>
> The DT binding for the TI SN65DSI86 [1] lists Sandeep Panda
> as the maintainer within the file. This is no
> longer valid because the @codeaurora domain bounces, and Sandeep appears
> to have left the company. As such
Hi,
On Thu, Jan 25, 2024 at 4:11 AM Uwe Kleine-König
wrote:
>
> This prepares the pwm driver of the ti-sn65dsi86 to further changes of
> the pwm core outlined in the commit introducing devm_pwmchip_alloc().
> There is no intended semantical change and the driver should behave as
> before.
>
>
Hi,
On Thu, Jan 25, 2024 at 4:11 AM Uwe Kleine-König
wrote:
>
> struct pwm_chip::dev is about to change. To not have to touch this
> driver in the same commit as struct pwm_chip::dev, use the macro
> provided for exactly this purpose.
>
> Signed-off-by: Uwe Kleine-König
> ---
>
Hi,
On Thu, Jan 18, 2024 at 9:30 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Jan 17, 2024 at 5:59 PM Hsin-Yi Wang wrote:
> >
> > Similar to commit 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge
> > is suspended in .post_disable()"). Add a mut
Hi,
On Wed, Jan 17, 2024 at 5:59 PM Hsin-Yi Wang wrote:
>
> Similar to commit 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge
> is suspended in .post_disable()"). Add a mutex to ensure that aux transfer
> won't race with atomic_disable by holding the PM reference and prevent
> the bridge
Hi,
On Wed, Jan 17, 2024 at 11:39 AM Hsin-Yi Wang wrote:
>
> On Wed, Jan 17, 2024 at 10:35 AM Douglas Anderson
> wrote:
> >
> > After commit 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge
> > is suspended in .post_disable()"), if we hit the error case in
> > ps8640_aux_transfer() then
Hi,
On Wed, Jan 17, 2024 at 9:34 AM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Jan 9, 2024 at 8:52 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Jan 9, 2024 at 4:05 AM Pin-yen Lin wrote:
> > >
> > > The ps8640 bridge seems to exp
Hi,
On Tue, Jan 9, 2024 at 8:52 AM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Jan 9, 2024 at 4:05 AM Pin-yen Lin wrote:
> >
> > The ps8640 bridge seems to expect everything to be power cycled at the
> > disable process, but sometimes ps8640_aux_transfer() hold
Hi,
On Tue, Jan 9, 2024 at 1:35 PM Uwe Kleine-König
wrote:
>
> Apart from the two of_xlate implementations this member is write-only.
> In the of_xlate functions of_pwm_xlate_with_flags() and
> of_pwm_single_xlate() it's more sensible to check for args->args_count
> because this is what is
Hi,
On Tue, Jan 9, 2024 at 4:05 AM Pin-yen Lin wrote:
>
> The ps8640 bridge seems to expect everything to be power cycled at the
> disable process, but sometimes ps8640_aux_transfer() holds the runtime
> PM reference and prevents the bridge from suspend.
>
> Prevent that by introducing a mutex
Hi,
On Wed, Dec 27, 2023 at 2:43 AM Pin-yen Lin wrote:
>
> Disable the autosuspend of runtime PM and use completion to make sure
> ps8640_suspend() is called in ps8640_atomic_post_disable().
>
> The ps8640 bridge seems to expect everything to be power cycled at the
> disable process, but
Hi,
On Mon, Dec 25, 2023 at 1:08 AM Pin-yen Lin wrote:
>
> Hi,
>
> On Fri, Dec 22, 2023 at 11:34 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Fri, Dec 22, 2023 at 2:29 AM Pin-yen Lin wrote:
> > >
> > > Hi Douglas,
> > >
>
Hi,
On Wed, Dec 20, 2023 at 2:43 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Dec 20, 2023 at 2:14 PM Hsin-Yi Wang wrote:
> >
> > Some edp panel requires T10 (Delay from end of valid video data transmitted
> > by the Source device to power-off) less than 500ms. Us
Hi,
On Fri, Dec 22, 2023 at 2:29 AM Pin-yen Lin wrote:
>
> Hi Douglas,
>
> On Fri, Dec 22, 2023 at 5:56 AM Douglas Anderson
> wrote:
> >
> > Unlike what is claimed in commit f5aa7d46b0ee ("drm/bridge:
> > parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux"), if
> > someone
Hi,
On Wed, Dec 20, 2023 at 2:14 PM Hsin-Yi Wang wrote:
>
> Some edp panel requires T10 (Delay from end of valid video data transmitted
> by the Source device to power-off) less than 500ms. Using autosuspend with
> delay set as 1000 violates this requirement.
>
> Use put_sync_suspend in
Hi,
On Mon, Dec 18, 2023 at 9:05 AM Douglas Anderson wrote:
>
> After commit 26195af57798 ("drm/bridge: ps8640: Drop the ability of
> ps8640 to fetch the EDID"), I got an error compiling:
>
> error: comparison of distinct pointer types
> ('typeof (len) *' (aka 'unsigned int *') and
>
Hi,
On Mon, Dec 18, 2023 at 1:59 AM Xuxin Xiong
wrote:
>
> Add support for the following 3 panels:
> 1. BOE NV116WHM-N49 V8.0
> 2. BOE NV122WUM-N41
> 3. CSO MNC207QS1-1
>
> Signed-off-by: Xuxin Xiong
> ---
> drivers/gpu/drm/panel/panel-edp.c | 4
> 1 file changed, 4 insertions(+)
Hi,
On Thu, Dec 14, 2023 at 12:38 PM Douglas Anderson wrote:
>
> While testing, I happened to notice a random crash that looked like:
>
> Kernel panic - not syncing: stack-protector:
> Kernel stack is corrupted in: drm_dp_dpcd_probe+0x120/0x120
>
> Analysis of drm_dp_dpcd_probe() shows that
Hi,
On Thu, Dec 14, 2023 at 12:38 PM Douglas Anderson wrote:
>
> For aux reads, the value `msg->size` indicates the size of the buffer
> provided by `msg->buffer`. We should never in any circumstances write
> more bytes to the buffer since it may overflow the buffer.
>
> In the ti-sn65dsi86
Hi,
On Thu, Dec 14, 2023 at 7:28 AM Pin-yen Lin wrote:
>
> Add the support of powered_on_to_enable delay as the minimum time that
> needs to have passed between the panel powered on and enable may begin.
>
> This delay is seen in BOE panels as the minimum delay of T3+T4+T5+T6+T8
> in the eDP
Hi,
On Mon, Dec 18, 2023 at 9:05 AM Douglas Anderson wrote:
>
> After commit 26195af57798 ("drm/bridge: ps8640: Drop the ability of
> ps8640 to fetch the EDID"), I got an error compiling:
>
> error: comparison of distinct pointer types
> ('typeof (len) *' (aka 'unsigned int *') and
>
Hi,
On Thu, Dec 14, 2023 at 7:28 AM Pin-yen Lin wrote:
>
> Add panels used by Mediatek MT8173 Chromebooks.
>
> Signed-off-by: Pin-yen Lin
> Reviewed-by: Douglas Anderson
>
> ---
>
> Changes in v3:
> - Collect review tag.
>
> drivers/gpu/drm/panel/panel-edp.c | 39
Hi,
On Thu, Dec 14, 2023 at 7:28 AM Pin-yen Lin wrote:
>
> These panels are used by Mediatek MT8173 Chromebooks, and they used to
> work with the downstream v4.19 kernel without any specified delay.
> Back in the v4.19 kernel, they used the "little white lie" approach,
> which is making the
Hi,
On Thu, Dec 14, 2023 at 12:32 PM Douglas Anderson wrote:
>
> While testing, I happened to notice a random crash that looked like:
>
> Kernel panic - not syncing: stack-protector:
> Kernel stack is corrupted in: drm_dp_dpcd_probe+0x120/0x120
>
> Analysis of drm_dp_dpcd_probe() shows that
Hi,
On Wed, Dec 13, 2023 at 7:34 AM Maxime Ripard wrote:
>
> > > > Repeating my comments from v1 here too, since I expect this patch to
> > > > sit on the lists for a little while:
> > > >
> > > >
> > > > This is OK w/ me, but it will need time on the mailing lists before
> > > > landing in case
Hi,
On Sat, Dec 9, 2023 at 7:31 AM Uwe Kleine-König
wrote:
>
> It's the ti_sn65dsi86.pwm auxiliary driver that creates the pwmchip, so
> let the auxiliary device be the parent of the pwm device.
>
> Note that getting a reference to the ti-sn65dsi86's pwm using pwm_get()
> isn't affected by this
Hi,
On Fri, Dec 8, 2023 at 9:30 AM Nikita Travkin wrote:
>
> Uwe Kleine-König писал(а) 27.11.2023 15:15:
> > It's the ti_sn65dsi86.pwm auxiliary driver that creates the pwmchip, so
> > let the auxiliary device be the parent of the pwm device.
> >
> > Note that getting a reference to the
Hi,
On Thu, Dec 7, 2023 at 10:58 AM Maxime Ripard wrote:
>
> On Thu, Dec 07, 2023 at 10:23:53AM -0800, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Dec 7, 2023 at 12:18 AM Pin-yen Lin wrote:
> > >
> > > These panels are used by Med
Hi,
On Thu, Dec 7, 2023 at 12:18 AM Pin-yen Lin wrote:
>
> These panels are used by Mediatek MT8173 Chromebooks but we can't find
> the corresponding data sheets, and these panels used to work on v4.19
> kernel without any specified delays.
>
> Therefore, instead of having them use the default
Hi,
On Thu, Dec 7, 2023 at 12:18 AM Pin-yen Lin wrote:
>
> Add panels used by Mediatek MT8173 Chromebooks.
>
> Signed-off-by: Pin-yen Lin
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/panel/panel-edp.c | 39 +++
> 1 file changed, 39 insertions(+)
Reviewed-by:
Hi,
On Thu, Dec 7, 2023 at 12:18 AM Pin-yen Lin wrote:
>
> Add the support of powered_on_to_enable delay as the minimum time that
> needs to have passed between the panel powered on and enable may begin.
>
> This delay is seen in BOE panels as the minimum delay of T3+T4+T5+T6+T8
> in the eDP
Hi,
On Thu, Dec 7, 2023 at 12:18 AM Pin-yen Lin wrote:
>
> Move the KDC panel entry to make the list sorted by the vendor string.
>
> Signed-off-by: Pin-yen Lin
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/panel/panel-edp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Hi,
On Fri, Nov 17, 2023 at 3:00 PM Doug Anderson wrote:
>
> Hi,
>
> On Fri, Sep 22, 2023 at 2:06 PM Lyude Paul wrote:
> >
> > actually very glad to see this because I think I've seen one bug in the wild
> > as a result of things not getting shut down :)
&
Hi,
On Tue, Dec 5, 2023 at 4:37 AM Pin-yen Lin wrote:
>
> These panels are used by Mediatek MT8173 Chromebooks but we can't find
> the corresponding data sheets, and these panels used to work on v4.19
> kernel without any specified delays.
>
> Therefore, instead of having them use the default
Hi,
On Tue, Dec 5, 2023 at 4:36 AM Pin-yen Lin wrote:
>
> @@ -1999,10 +2031,17 @@ static const struct edp_panel_entry edp_panels[] = {
> EDP_PANEL_ENTRY('I', 'V', 'O', 0x854b, _200_500_p2e100,
> "R133NW4K-R0"),
> EDP_PANEL_ENTRY('I', 'V', 'O', 0x8c4d, _200_150_e200, "R140NWFM
>
Hi,
On Tue, Dec 5, 2023 at 4:36 AM Pin-yen Lin wrote:
>
> Add the support of powered_on_to_enable delay as the minimum time that
> needs to have passed between the panel powered on and enable may begin.
>
> This delay is seen in BOE panels as the minimum delay of T3+T4+T5+T6+T8
> in the eDP
Hi,
On Tue, Dec 5, 2023 at 4:36 AM Pin-yen Lin wrote:
>
> Move the order of CMN 0x14e5 to make the list sorted.
>
> Signed-off-by: Pin-yen Lin
> ---
>
> drivers/gpu/drm/panel/panel-edp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Pushed to drm-misc-next:
4900e0396e59
Hi,
On Mon, Dec 4, 2023 at 8:46 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Dec 4, 2023 at 12:54 AM Abel Vesa wrote:
> >
> > Add support for the SDC ATNA45AF01 panel.
> >
> > Signed-off-by: Abel Vesa
> > ---
> > Changes in v2:
> > - m
Hi,
On Tue, Dec 5, 2023 at 5:40 AM Laurent Pinchart
wrote:
>
> On Tue, Dec 05, 2023 at 02:31:24PM +0100, Geert Uytterhoeven wrote:
> > On Tue, Dec 5, 2023 at 1:16 PM Laurent Pinchart wrote:
> > > On Tue, Dec 05, 2023 at 12:30:02PM +0100, Geert Uytterhoeven wrote:
> > > > From: Douglas Anderson
Hi,
On Mon, Dec 4, 2023 at 12:54 AM Abel Vesa wrote:
>
> Add support for the SDC ATNA45AF01 panel.
>
> Signed-off-by: Abel Vesa
> ---
> Changes in v2:
> - moved the panel entry in the proper place, as suggested by Doug
> - Link to v1:
>
101 - 200 of 1345 matches
Mail list logo
