Message ID | 1576672109-22707-1-git-send-email-claudiu.beznea@microchip.com (mailing list archive) |
---|---|
Headers | show |
Series | fixes for atmel-hlcdc | expand |
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
On Thu, 02 Jan 2020, Sam Ravnborg wrote: > 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? How are they related to the other patches? Do they have build-time dependencies on any of the other patches, or vice versa?
Hi Lee. > > > ("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? > > How are they related to the other patches? Do they have build-time > dependencies on any of the other patches, or vice versa? No build time dependencies. But from the description of "atmel-hlcdc: return in case of error": " For HLCDC timing engine configurations bit ATMEL_HLCDC_SIP of ATMEL_HLCDC_SR needs to be polled before applying new config. " I get that changing timing for the HLCDC may fail if these patches are not applied. So it is only to have updated hlcdc support in drm-misc-next for further testing. Sam
> > 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 > Revert "drm: atmel-hlcdc: enable sys_clk during initalization." > > Peter Rosin (1): > drm: atmel-hlcdc: prefer a lower pixel-clock than requested I have applied the drm patches to drm-misc-next now. Sam