On Fri, Apr 10, 2020 at 9:03 AM Rafael J. Wysocki wrote:
>
> From: "Rafael J. Wysocki"
>
> Rename DPM_FLAG_NEVER_SKIP to DPM_FLAG_NO_DIRECT_COMPLETE which
> matches its purpose more closely.
>
> No functional impact.
>
> Signed-off-by: Rafael J. Wysocki
Acked-by: Jeff Kirsher
For the driver c
On Thu, Apr 09, 2020 at 03:46:10AM +0300, Laurent Pinchart wrote:
> Now that the driver supports all the connector-related bridge
> operations, make the connector creation optional. This enables usage of
> the adv7511 with the DRM bridge connector helper.
>
> Signed-off-by: Laurent Pinchart
Acked
Hi Laurent.
On Thu, Apr 09, 2020 at 03:46:08AM +0300, Laurent Pinchart wrote:
> To prepare for making the connector creation optional, move the related
> code out of adv7511_bridge_attach() to a separate function.
>
> Signed-off-by: Laurent Pinchart
On nit below, but otherwise:
Acked-by: Sam Ra
Hi Laurent.
On Thu, Apr 09, 2020 at 03:46:07AM +0300, Laurent Pinchart wrote:
> To prepare for the implementation of the DRM bridge connector
> operations, move EDID read out of adv7511_get_modes() to a separate
> function.
>
> Signed-off-by: Laurent Pinchart
The code do not check if drm_do_get
On Thu, Apr 09, 2020 at 03:36:36AM +0300, Laurent Pinchart wrote:
> Make the connector creation optional to enable usage of the
> simple-bridge with the DRM bridge connector helper.
>
> Signed-off-by: Laurent Pinchart
Looks straightforward.
Acked-by: Sam Ravnborg
Some rambling below you can ig
Hi Laurent.
On Thu, Apr 09, 2020 at 03:36:35AM +0300, Laurent Pinchart wrote:
> Instead of poking into the DT node of the next bridge for its DDC bus
> and implementing the .get_modes() and .detect() connector operations
> manually, retrieve the next bridge in the chain and delegate these
> operat
Reviewed-by: Evan Quan
-Original Message-
From: Christophe JAILLET
Sent: Saturday, April 11, 2020 10:04 PM
To: Deucher, Alexander ; Koenig, Christian
; Zhou, David(ChunMing) ;
airl...@linux.ie; dan...@ffwll.ch; Zhang, Hawking ;
Quan, Evan ; Grodzovsky, Andrey ;
Liu, Monk ; Russell,
On Wed, Apr 08, 2020 at 11:01:41PM +0300, Laurent Pinchart wrote:
> Hi Sam,
>
> Thank you for the patch.
>
> On Wed, Apr 08, 2020 at 08:29:26PM +0200, Sam Ravnborg wrote:
> > Laurent Pinchart and
> > Jani Nikula both
> > suggested to make the pointer to struct ipu_di_signal_cfg const.
> >
> >
Fix following warning:
vt8500lcdfb.c: In function 'vt8500lcd_blank':
vt8500lcdfb.c:229:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
^
vt8500lcdfb.c:233:2: note: here
case FB_BLANK_UNBLANK:
^~~~
Addi
Hi Rob.
On Thu, Apr 09, 2020 at 10:11:10AM -0600, Rob Herring wrote:
> On Wed, Apr 8, 2020 at 1:51 PM Sam Ravnborg wrote:
> >
> > Both port and ports names may be used.
> > port - for a single port
> > ports - if there is more than one port in sub-nodes
> >
> > Fixes the following warning:
> > ad
Hi Enric.
Just a "drive-by" comment.
I browsed all the patches - and nothing jumped at me.
But then I did not follow all the changes.
> @@ -1202,10 +1055,19 @@ static int mtk_dsi_probe(struct platform_device *pdev)
> }
>
> ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
> -
https://bugzilla.kernel.org/show_bug.cgi?id=205497
--- Comment #23 from albertogomezma...@gmail.com ---
I did not test it. I have not here the laptop to do it. I have now another
laptop with ryyzen 7 3700U
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 2020-04-12 07:35, Christophe JAILLET wrote:
Duplicated 'we'
Signed-off-by: Christophe JAILLET
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drive
The wiring property is used to describe the wiring between
the connector and the panel. The property can be used when the
wiring is used to change the mode from for example
BGR to RGB. The first users are the at91sam9 family where
such a wiring trick is sometimes used.
The possilbe values are so fa
Add a new binding file to describe the bindings
for the Atmel LCDC IP.
This replaces the old txt based binding.
The binding file describes the current binding,
including properties to specify register values etc.
The binding will be updated in a follow-up patch,
the current binding describes the a
The following four patches update the bindings for Atmel
LCDC, HLCDC display controllers to DT Schema.
The bindings were re-written in DT Schema format,
and examples adjusted/updated to fit.
This patch-set introduces a new endpoint property in video-interfaces
used to tell if red and blue wiring
Update the Atmel LCDC binding to include:
- pwm. Used for backlight
- endpoints using port node
Used for handle to panel
- Added wiring property that is used to describe
the wiring between the LCDC and the panel
Existing properties that should not be used in new
bindings are deprecated.
Updat
atmel hlcdc is a MFD devide with two sub-devices:
- PWM
- Display controller
Add binding files for each device:
- mfd/atmel-hlcdc - this is overall device
- pwm/atmel-hlcdc-pwm - the pwm part, used for backlight
- display/atmel/hlcdc-dc - the display controller
The hlcdc IP is present in seve
https://bugzilla.kernel.org/show_bug.cgi?id=205497
--- Comment #22 from Luya Tshimbalanga (l...@fedoraproject.org) ---
(In reply to albertogomezmarin from comment #21)
> (In reply to Luya Tshimbalanga from comment #20)
> > I confirm the fix landed on kernel 5.4. Thanks Alex for a quick
> > investi
Hi Laurent,
On Fri, Apr 10, 2020 at 03:57:32PM +0300, Laurent Pinchart wrote:
> Hi Guido,
>
> On Fri, Apr 10, 2020 at 02:45:16PM +0200, Guido Günther wrote:
> > On Fri, Apr 10, 2020 at 02:23:42PM +0300, Laurent Pinchart wrote:
> > > On Thu, Apr 09, 2020 at 12:42:01PM +0200, Guido Günther wrote:
>
Hi,
On Mon, Mar 09, 2020 at 09:51:55PM +0200, Laurent Pinchart wrote:
> Hello,
>
> This patch series adds i.MX7 support to the mxsfb driver. The eLCDIF
> instance found in the i.MX7 is backward-compatible with the already
> supported LCDC v4, but has extended features amongst which the most
> nota
https://bugzilla.kernel.org/show_bug.cgi?id=207183
--- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Erik Huelsmann from comment #5)
> Is the fact that it's apparently not possible to switch the memory clock
> with 2 monitors attached a design error in the hardware? Unfortu
Hi Tian.
On Sat, Apr 11, 2020 at 10:49:30AM +0800, Tian Tao wrote:
> add the shutdown function to release the resource.
>
Why it the release of the memory required in the shutdown method?
The memory is allocated using devm_ioremap() which
will let device management handle the release of the reso
The binding for the advantech,idk-2121wr uses an example
where a ports {} node is used.
The panel-lvds binding failed to support a ports node,
which the following patch fixes.
This fix was part of a longer series, but we need this fix
in upstream before -rc2.
So pull this out of the larger series
Both port and ports names may be used in a panel-lvds binding
port - for a single port
ports - if there is more than one port in sub-nodes
Fixes the following warning:
advantech,idk-2121wr.example.dt.yaml: panel-lvds: 'port' is a required property
advantech,idk-2121wr.yaml needs several ports
25 matches
Mail list logo
