On Wed, Jul 15, 2020 at 05:05:49PM +0200, Daniel Vetter wrote: > Hi Anitha > > On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote: > > This is a new DRM driver for Intel's KeemBay SOC. > > The SoC couples an ARM Cortex A53 CPU with an Intel > > Movidius VPU. > > > > This driver is tested with the KMB EVM board which is the refernce baord > > for Keem Bay SOC. The SOC's display pipeline is as follows > > > > +--------------+ +---------+ +-----------------------+ > > |LCD controller| -> |Mipi DSI | -> |Mipi to HDMI Converter | > > +--------------+ +---------+ +-----------------------+ > > > > LCD controller and Mipi DSI transmitter are part of the SOC and > > mipi to HDMI converter is ADV7535 for KMB EVM board. > > > > The DRM driver is a basic KMS atomic modesetting display driver and > > has no 2D or 3D graphics.It calls into the ADV bridge driver at > > the connector level. > > > > Only 1080p resolution and single plane is supported at this time. > > The usecase is for debugging video and camera outputs. > > > > Device tree patches are under review here > > https://lore.kernel.org/linux-arm-kernel/20200708175020.194436-1-daniele.alessandrelli@xxxxxxxxxxxxxxx/T/ > > Cool, new driver, thanks a lot for submitting. > > > Changes since v1: > > - Removed redundant license text, updated license > > - Rearranged include blocks > > - renamed global vars and removed extern in c > > - Used upclassing for dev_private > > - Used drm_dev_init in drm device create (will be updated to use > > devm_drm_dev_alloc() in a separate patch later as kmb driver is currently > > developed on 5.4 kernel) > > drm moves fairly quickly, please develop the upstream submission on top of > linux-next or similar. We constantly add new helpers to simplify drivers, > and we expect new driver submissions to be up to date with all that. Seconded! > > Another thing: From your description it sounds like it's a very simple > driver, just a single plane/crtc, nothing fancy, plus adv bridge output. > Is the driver already using simple display pipeline helpers? I think that > would be an ideal fit and probably greatly simplifies the code. > > > - minor cleanups > > The patch series looks like it contains the entire development history, or > at least large chunks of it. That's useful for you, but for upstreaming > the main focues (especially for smaller drivers) is whether your driver > uses all the available helpers and integrations correctly. And for that > it's much easier if the history is cleaned up, and all intermediate steps > removed. And also agree on this point. The submission could be split up in a few patches where the split is file based. So only with the latest patch, containing Makefile + Kconfig,the driver i buildable. This would ease review as one looses focus when trying to review 1000+ lines in one mail. You will loose some of the internal history - but if important keep relevant parts in sensible comments. Sam _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
