[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200102090554.GB29446@ravnborg.org>
Date: Thu, 2 Jan 2020 10:05:54 +0100
From: Sam Ravnborg <sam@...nborg.org>
To: Claudiu Beznea <claudiu.beznea@...rochip.com>, lee.jones@...aro.org
Cc: boris.brezillon@...tlin.com, airlied@...ux.ie,
nicolas.ferre@...rochip.com, alexandre.belloni@...tlin.com,
lee.jones@...aro.org, peda@...ntia.se,
dri-devel@...ts.freedesktop.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/6] fixes for atmel-hlcdc
Hi Lee.
How do de handle the two mfd related patches?
> I have few fixes for atmel-hlcdc driver in this series as well
> as two reverts.
> Revert "drm: atmel-hlcdc: enable sys_clk during initalization." is
> due to the fix in in patch 2/5.
>
> Thank you,
> Claudiu Beznea
>
> Changes in v3:
> - changes dev_err() message in patch 4/6
> - collect Acked-by tags
>
> Changes in v2:
> - introduce patch 3/6
> - use dev_err() inpatch 4/6
> - introduce patch 5/6 instead of reverting commit f6f7ad323461
> ("drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested")
>
> Claudiu Beznea (5):
> drm: atmel-hlcdc: use double rate for pixel clock only if supported
> drm: atmel-hlcdc: enable clock before configuring timing engine
> mfd: atmel-hlcdc: add struct device member to struct
> atmel_hlcdc_regmap
> mfd: atmel-hlcdc: return in case of error
Would it be OK to apply the to drm-misc-next, or shal they go in via
your mfd tree?
Sam
Powered by blists - more mailing lists