truct drm_device *dev, unsigned
> long flags) break;
> }
>
> + drm_helper_disable_unused_functions(dev);
> priv->fbdev = drm_fbdev_cma_init(dev, bpp,
> dev->mode_config.num_crtc,
> dev->mode_config.nu
Hi Daniel,
On Monday 25 January 2016 08:29:38 Daniel Vetter wrote:
> On Mon, Jan 25, 2016 at 12:19:27AM +0200, Laurent Pinchart wrote:
> > On Friday 15 January 2016 11:17:30 Daniel Vetter wrote:
> >> On Fri, Jan 15, 2016 at 01:13:05AM +0200, Laurent Pinchart wrote:
> >&
Hi Daniel,
On Friday 15 January 2016 11:17:30 Daniel Vetter wrote:
> On Fri, Jan 15, 2016 at 01:13:05AM +0200, Laurent Pinchart wrote:
> > On Thursday 14 January 2016 16:24:56 Maxime Ripard wrote:
> >> The drm_fbdev_cma_init function always calls the
> >> drm_help
goto err_free_table;
> + }
> +
> + sg_set_page(>sgl[i], vm_page, chunk_len,
> + offset_in_page(sg_buf));
> + } else {
> + sg_set_buf(>sgl[i], sg_buf, chunk_len);
> +
Hi Sean,
On Thursday 23 Feb 2017 10:54:37 Sean Paul wrote:
> On Wed, Dec 07, 2016 at 11:48:55AM +0200, Laurent Pinchart wrote:
> > On Wednesday 07 Dec 2016 10:26:25 Chen-Yu Tsai wrote:
> >> On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard wrote:
> >>> On Thu, Nov 24,
> (v6) and yet again in this version by Laurent.
> >
> > - And finally the fact that we can't have several display engine in
> > parallel, if needs be. This has happened in the past already on
> > Allwinner SoCs, so it's definitely something we should conside
Hi Jean-François,
On Tuesday 29 Nov 2016 20:27:51 Jean-Francois Moine wrote:
> On Tue, 29 Nov 2016 20:46:22 +0200 Laurent Pinchart wrote:
> [snip]
>
> >> +Example:
> >> +
> >> + hdmi: hdmi@01ee {
> >> + compatible = "allwinner,s
Hi Jean-François,
On Tuesday 29 Nov 2016 21:04:55 Jean-Francois Moine wrote:
> On Tue, 29 Nov 2016 21:33 +0200 Laurent Pinchart wrote:
> >>> You need a third port for the HDMI encoder output, connected to an
> >>> HDMI connector DT node.
> >>
> >&g
d don't list min/max tolerances for the dotclock.
>
> The ones that do have the min/max the same as the recommended value.
> This may or may not be accurate. IIRC the one panel that had this
> that I did check didn't list min/max values in its datasheet.
>
> > I'm not sure how
Hi Jernej,
On Tuesday 29 Nov 2016 15:24:25 Jernej Skrabec wrote:
> Dne torek, 29. november 2016 23.56.31 UTC+1 je oseba Laurent Pinchart
> napisala:
> > On Tuesday 29 Nov 2016 14:47:20 Jernej Skrabec wrote:
> >> Dne torek, 29. november 2016 22.37.03 UTC+1 je oseba Maxim
Hi Jean-François,
On Wednesday 30 Nov 2016 09:12:08 Jean-Francois Moine wrote:
> On Tue, 29 Nov 2016 22:10:01 +0200 Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 21:04:55 Jean-Francois Moine wrote:
> >> On Tue, 29 Nov 2016 21:33 +0200 Laurent Pinchart wrote:
> >&g
Hi Jean-François,
On Wednesday 30 Nov 2016 10:27:57 Jean-Francois Moine wrote:
> On Wed, 30 Nov 2016 10:20:21 +0200 Laurent Pinchart wrote:
> >> Well, I don't see what this connector can be.
> >> May you give me a DT example?
> >
> > Sure.
> >
&g
hen it comes to drivers I mostly pay
attention to DT bindings, userspace APIs and modification to common code.
Driver code itself, as long as it's reasonably clean and doesn't impede
development of other drivers or impact system security in an adverse way, is
still important but maybe slightl
Hi Maxime,
On Thursday 01 Dec 2016 10:13:13 Maxime Ripard wrote:
> On Wed, Nov 30, 2016 at 12:12:55PM +0200, Laurent Pinchart wrote:
> >> More, it is not sure that the bridge/DW code would work with Allwinner's
> >> SoCs.
> >
> > If it doesn't work and can't be m
A generic DT binding RFC is available at
http://www.spinics.net/lists/devicetree/msg152414.html.
> But the current approach doesn't work and will require some DT
> modifications if that case happens again, which we can't do because of
> the DT ABI.
--
Regards,
Laurent Pinchart
--
You received this
On Thursday 01 Dec 2016 12:30:09 Jean-Francois Moine wrote:
> On Thu, 01 Dec 2016 12:41:20 +0200 Laurent Pinchart wrote:
> >>> If a DVI connector instead of a HDMI connector is soldered, how
> >>> should such a device tree be written?
> >>
> >> Use
ed on the board. Having a connector node in DT makes the
connector type available to the system, allowing the DRM driver to expose the
right connector type to userspace (it would be confusing for the user to
report DRM_MODE_CONNECTOR_HDMIA for a DVI connector).
> > How about solder a HDMI-to-VGA bridge on the bo
t; +
> + /* not used */
> + tcon1: lcd-controller@01c0d000 {
> + compatible = "allwinner,sun8i-h3-tcon";
> + reg = <0x01c0d000 0x400>;
> + clocks = < CLK_BUS_TCON1>,
> + < CLK_TCON0>; /* no
Hi Jean-François,
A brief update.
On Tuesday 29 Nov 2016 20:41:30 Laurent Pinchart wrote:
> On Monday 28 Nov 2016 19:02:39 Jean-Francois Moine wrote:
> > Signed-off-by: Jean-Francois Moine <moin...@free.fr>
> > ---
> >
> > .../bindings/display/su
gt;;
> + port@0 {/* video */
> + reg = <0>;
> + hdmi_tcon1: endpoint {
> + remote-endpoint = <_hdmi>;
> + };
> + };
> + port@1 {
that if you're pairing a panel
> with some display hardware, it's up to you to make sure that the panel's
> mode actually scans out successfully. Then, since compatible strings
> are cheap, you can use a new one if necessary to attach better modes to
> the panel for a particular clock driv
obviously need to be fixed if they are buggy in that regard. Such race
conditions are definitely something I keep an eye on when reviewing code.
> More complex devices are a whole different ballgame.
>
> > This is how DRM operates, and you sometimes end up in some very dumb
> > si
ted (there should definitely be so crash) I
don't see any drawback to that approach.
> This is how DRM operates, and you sometimes end up in some very dumb
> situations where you wait for say, the DSI controller to probe, while
> you only care about HDMI in your system.
>
> But
dw_hdmi *hdmi, unsigned short data,
> unsigned char addr);
> +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> +void *data);
> +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> +
>
> Signed-off-by: Jernej Skrabec <jernej.skra...@siol.net>
This does not break R-Car DU, so
Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletio
I2C write function is called dw_hdmi_phy_i2c_write(). If we want to be
conosistent we should either rename this one to dw_hdmi_phy_i2c_set_addr() or
rename them both to dw_hdmi_phy_gen2_i2c_write() and
dw_hdmi_phy_gen2_i2c_set_addr(). I think I'd prefer the former, and we could
even drop gen2 from dw_hdmi_phy_ge
dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> + bool force, bool disabled, bool rxsense);
> +void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
> +
> +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable);
> +void dw_hdmi_phy_gen2_txpwron(st
Hi Maxime,
On Thursday, 18 October 2018 15:18:19 EEST Maxime Ripard wrote:
> On Thu, Oct 18, 2018 at 02:31:01PM +0300, Laurent Pinchart wrote:
> > On Thursday, 18 October 2018 12:42:58 EEST Maxime Ripard wrote:
> >> On Thu, Oct 18, 2018 at 11:18:06AM +0200, Daniel Vetter wrote:
iv = 6;
> tcon->dclk_max_div = 127;
> rounded_rate = clk_round_rate(tcon->dclk, rate);
> - if (rounded_rate < rate)
> + if (rounded_rate < rate * 19 / 20 )
> return MODE_CLOCK_LOW;
>
> - if (rounded_rate > rate)
> +
ore.o analogix_dp_reg.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> +obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
This makes sense to me. I would have tried to keep the Kconfig and Makefile
entries alphabetically sorted, but that's not a big deal. With or without the
sorting,
Hi Icenowy,
On Thursday, 18 October 2018 13:00:05 EEST Icenowy Zheng wrote:
> 在 2018-10-18四的 11:53 +0300，Laurent Pinchart写道：
> > On Thursday, 18 October 2018 10:33:22 EEST Icenowy Zheng wrote:
> >> The ANX6345 is an ultra-low power DisplayPort/eDP transmitter
> >>
Hello,
On Thursday, 18 October 2018 12:42:58 EEST Maxime Ripard wrote:
> On Thu, Oct 18, 2018 at 11:18:06AM +0200, Daniel Vetter wrote:
> > On Thu, Oct 18, 2018 at 10:55 AM Laurent Pinchart wrote:
> >> On Thursday, 18 October 2018 10:33:27 EEST Icenowy Zheng wrote:
> &
Hi Yong,
Thank you for the patch.
On Tuesday, 30 October 2018 10:12:23 EET Yong Deng wrote:
> Add binding documentation for Allwinner V3s CSI.
>
> Acked-by: Maxime Ripard
> Acked-by: Sakari Ailus
> Reviewed-by: Rob Herring
> Signed-off-by: Yong Deng
Reviewed-by
resets = < RST_BUS_CSI>;
> > +
> > + port {
> > + /* Parallel bus endpoint */
> > + csi1_ep: endpoint {
> > + remote-endpoint = <_ep>;
> > + bus-width = <16>;
> > +
> > + /* If hsync-active
count = 1;
> break;
> default:
--
Regards,
Laurent Pinchart
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an em
Hi Maxime,
On Wednesday, 26 September 2018 13:35:47 EEST maxime.rip...@bootlin.com wrote:
> On Wed, Sep 26, 2018 at 01:19:34PM +0300, Laurent Pinchart wrote:
> > > +Endpoint node properties for CSI1
> > > +-
> >
> > Should you
le,
> > + .enable = chipone_enable,
> > + .pre_enable = chipone_pre_enable,
> > + .attach = chipone_attach,
> > + .detach = chipone_detach,
> > +};
> > +
> > +static int chipone_probe(struct mipi_dsi_device *dsi)
> > +{
> > + struc
.compatible = "starry,kr070pe2t",
> + .data = _kr070pe2t,
> }, {
> .compatible = "starry,kr122ea0sra",
> .data = _kr122ea0sra,
--
Regards,
Laurent Pinchart
--
You received this message because you are s
4
>
> struct sun6i_dsi {
> + struct drm_bridge bridge;
> struct drm_connectorconnector;
> struct drm_encoder encoder;
The drm_encoder should be dropped from this driver, the encoder should
be created by the main display driver.
> struct m
;
> static const struct component_ops sun6i_dsi_ops = {
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> index c863900ae3b4..370ecb356a63 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> +++ b/drivers/gpu/drm/sun4i/sun6i_mi
Hi Jagan,
On Wed, Mar 24, 2021 at 03:19:10PM +0530, Jagan Teki wrote:
> On Wed, Mar 24, 2021 at 3:09 PM Laurent Pinchart wrote:
> > On Wed, Mar 24, 2021 at 02:44:57PM +0530, Jagan Teki wrote:
> > > On Wed, Mar 24, 2021 at 8:18 AM Samuel Holland wrote:
> > > > On 3/2
Hi Jagan,
On Wed, Mar 24, 2021 at 02:44:57PM +0530, Jagan Teki wrote:
> On Wed, Mar 24, 2021 at 8:18 AM Samuel Holland wrote:
> > On 3/23/21 5:53 PM, Laurent Pinchart wrote:
> > > On Mon, Mar 22, 2021 at 07:31:49PM +0530, Jagan Teki wrote:
> > >
me will replace with bridge
> parameter once bridge supported.
>
> Signed-off-by: Jagan Teki
Looks good, there should be no functional change.
Reviewed-by: Laurent Pinchart
> ---
> Changes for v4, v3:
> - none
>
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 11 --
> > @@ -1013,16 +1047,46 @@ static int sun6i_dsi_attach(struct mipi_dsi_host
> > *host,
> > struct mipi_dsi_device *device)
> > {
> > struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
> > - struct drm_panel *panel = of_drm_find_panel(device->d
44 matches
Mail list logo
