linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sekhar Nori <nsekhar@ti.com>
To: Arnd Bergmann <arnd@arndb.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lad Prabhakar <prabhakar.csengg@gmail.com>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Mukesh Ojha <mojha@codeaurora.org>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Ioannis Valasakis <code@wizofe.uk>,
	Arushi Singhal <arushisinghal19971997@gmail.com>,
	<linux-media@vger.kernel.org>, <devel@driverdev.osuosl.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] staging: media/davinci_vpfe: fix pinmux setup compilation
Date: Mon, 22 Jul 2019 14:10:18 +0530	[thread overview]
Message-ID: <35b6ec33-f3d7-54ec-e9a0-3748ee9eb343@ti.com> (raw)
In-Reply-To: <20190722081243.2084226-1-arnd@arndb.de>

Hi Arnd,

On 22/07/19 1:42 PM, Arnd Bergmann wrote:
> The dm365_isif staging driver uses an odd method for configuring its
> pin muxing by calling directly into low-level davinci platform specific
> code, even when being compile-tested for other platforms.
> 
> As we want davinci to be part of a multi-platform kernel, this will
> cause a build failure when those headers are no longer exported even
> for davinci:
> 
> drivers/staging/media/davinci_vpfe/dm365_isif.c: In function 'vpfe_isif_init':
> drivers/staging/media/davinci_vpfe/dm365_isif.c:2031:2: error: implicit declaration of function 'davinci_cfg_reg'; did you mean 'omap_cfg_reg'? [-Werror=implicit-function-declaration]
>   davinci_cfg_reg(DM365_VIN_CAM_WEN);
>   ^~~~~~~~~~~~~~~
>   omap_cfg_reg
> drivers/staging/media/davinci_vpfe/dm365_isif.c:2031:18: error: 'DM365_VIN_CAM_WEN' undeclared (first use in this function); did you mean 'DM365_ISIF_MAX_CLDC'?
>   davinci_cfg_reg(DM365_VIN_CAM_WEN);
>                   ^~~~~~~~~~~~~~~~~
> 
> Digging further, it seems that the platform data structures defined
> in drivers/staging/media/davinci_vpfe/vpfe.h are an incompatible
> version of the same structures in include/media/davinci/vpfe_capture.h,
> which is the version that is used by the platform code, so the
> combination that exists in the mainline kernel cannot be used.
> 
> The platform code already has an abstraction for the pinmux,
> in the form of the dm365_isif_setup_pinmux() helper. If we want
> to ever get to use the staging driver again, this needs to be
> read from the platform data passed to this driver, or rewritten
> to use the pinmux framework.
> 
> For the moment, pretend we pass the helper function in the
> staging platform driver to get it to build cleanly. I could
> not figure out how the staging driver relates to the code
> in drivers/media/platform/davinci/, some clarification on that
> would be helpful to decide what the long-term plan on this
> should be to either remove the staging driver as obsolete or
> integrate it with the rest in a way that actually works.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

I looked at the history of updates on this driver over last 4 years.
None of them are towards fixing some issue found with the driver during
actual usage or for improving its design to move it out of staging.

I think no one is really using it or working on moving it out of
staging. Perhaps the right thing to do would be to delete it.

Thanks,
Sekhar

      reply	other threads:[~2019-07-22  8:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-22  8:12 [PATCH] staging: media/davinci_vpfe: fix pinmux setup compilation Arnd Bergmann
2019-07-22  8:40 ` Sekhar Nori [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=35b6ec33-f3d7-54ec-e9a0-3748ee9eb343@ti.com \
    --to=nsekhar@ti.com \
    --cc=arnd@arndb.de \
    --cc=arushisinghal19971997@gmail.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=code@wizofe.uk \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mojha@codeaurora.org \
    --cc=prabhakar.csengg@gmail.com \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).