Re: [PATCH 00/31] ARM: tegra: use common reset and DMA bindings
On 15.11.2013 22:53, Stephen Warren wrote: > From: Stephen Warren > > This series implements a common reset framework driver for Tegra, and > updates all relevant Tegra drivers to use it. It also removes the custom > DMA bindings and replaced them with the standard DMA DT bindings. > > Historically, the Tegra clock driver has exported a custom API for module > reset. This series removes that API, and transitions DT and drivers to > the new reset framework. > > The custom API used a "struct clk" to identify which module to reset, and > consequently some DT bindings and drivers required clocks to be provided > where they really needed just a reset identifier instead. Due to this > known deficiency, I have always considered most Tegra bindings to be > unstable. This series removes this excuse for instability, although I > still consider some Tegra bindings unstable due to the need to convert to > the common DMA bindings. > > Historically, Tegra DMA channels have been represented in DT using a > custom nvidia,dma-request-selector property. Now that standard DMA DT > bindings exist, convert all Tegra bindings, DTs, and drivers to use the > standard instead. > > This series makes a DT-ABI-incompatible change to: > - Require reset specifiers in DT where relevant. > - Require standard DMA specifiers. > - Remove clock specifiers from DT where they were only needed for reset. > - Remove legacy DMA specifier properties. > > I anticipate merging this whole series into the Tegra and arm-soc trees > as its own branch, due to internal dependencies. This branch will be > stable and can then be merged into any other subsystem trees should any > conflicts arise. > > This series depends on Peter's Tegra clock driver rework, available at > git://nv-tegra.nvidia.com/user/pdeschrijver/linux tegra-clk-tegra124-0 > (or whatever version of that gets included in 3.14) Overall, a good change. For host1x part: Acked-By: Terje Bergstrom This patch does not change the behavior, but we have in original code the problem that we don't flush the MC queue when resetting an engine. This can cause some memory writes to not hit memory. There was an earlier discussion on that, but we seem to have lost track of the issue. Terje ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: imx-drm: Fix modular build of DRM_IMX_IPUV3
On Tue, Nov 12, 2013 at 12:15:45PM -0500, Josh Boyer wrote:
> commit b8d181e408af (staging: drm/imx: add drm plane support) added a file
> to the make target for DRM_IMX_IPUV3 but didn't adjust the objs required
> to actually build that as a module. Kbuild got confused and this lead to
> link errors like:
>
> ERROR: "ipu_plane_disable" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
> ERROR: "ipu_plane_enable" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined!
>
> Additionally, it added a call to imx_drm_crtc_id which also fails with a
> link error as above. To fix this, we adjust the make target with the proper
> objs, which will change the name of the resulting .ko. We also add an
> EXPORT_SYMBOL_GPL for imx_drm_crtc_id.
>
> Signed-off-by: Josh Boyer
Acked-by: Sascha Hauer
Sascha
> ---
> drivers/staging/imx-drm/Makefile | 4 +++-
> drivers/staging/imx-drm/imx-drm-core.c | 1 +
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/imx-drm/Makefile
> b/drivers/staging/imx-drm/Makefile
> index 2c3a9e1..8742432 100644
> --- a/drivers/staging/imx-drm/Makefile
> +++ b/drivers/staging/imx-drm/Makefile
> @@ -8,4 +8,6 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
> obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
> obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
> obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += ipu-v3/
> -obj-$(CONFIG_DRM_IMX_IPUV3) += ipuv3-crtc.o ipuv3-plane.o
> +
> +imx-ipuv3-crtc-objs := ipuv3-crtc.o ipuv3-plane.o
> +obj-$(CONFIG_DRM_IMX_IPUV3) += imx-ipuv3-crtc.o
> diff --git a/drivers/staging/imx-drm/imx-drm-core.c
> b/drivers/staging/imx-drm/imx-drm-core.c
> index 4483d47..2b366d8 100644
> --- a/drivers/staging/imx-drm/imx-drm-core.c
> +++ b/drivers/staging/imx-drm/imx-drm-core.c
> @@ -72,6 +72,7 @@ int imx_drm_crtc_id(struct imx_drm_crtc *crtc)
> {
> return crtc->pipe;
> }
> +EXPORT_SYMBOL_GPL(imx_drm_crtc_id);
>
> static void imx_drm_driver_lastclose(struct drm_device *drm)
> {
> --
> 1.8.3.1
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: comedi: fix coding style issues in unioxx5.c
On 2013-11-17 03:42, Conrad Gomes wrote:
Hi,
No problem, I'll break this up and resend it.
In order to use dev_info type functions I was planning on assigning the
comedi device's struct device to the struct subdevice's class_dev as
follows in comedi_alloc_subdevices as it appears that is is not used(I
could be wrong):
diff --git a/drivers/staging/comedi/drivers.c
b/drivers/staging/comedi/drivers.c
index 8f02bf6..e4c44ae 100644
--- a/drivers/staging/comedi/drivers.c
+++ b/drivers/staging/comedi/drivers.c
@@ -90,6 +90,7 @@ int comedi_alloc_subdevices(struct comedi_device *dev,
int num_subdevices)
s->async_dma_dir = DMA_NONE;
spin_lock_init(&s->spin_lock);
s->minor = -1;
+ s->class_dev = dev->class_dev;
}
return 0;
}
The class_dev member is assigned by comedi_alloc_subdevice_minor(s)
(which will be called if the subdevice supports asynchronous comedi
commands) and is kept around for the call to comedi_free_subdevice_minor(s).
The struct comedi_subdevice has a pointer back to the struct
comedi_device. The class_dev member in the struct comedi_device can be
used as the device pointer parameter of dev_info() etc.
And adding a reference to the subdevice in the private data structure
unioxx5_subd_priv in order to substitute pr_info with dev_info. If this
is fine I'll remove all references of pr_info in the file:
diff --git a/drivers/staging/comedi/drivers/unioxx5.c
b/drivers/staging/comedi/drivers/unioxx5.c
index 2b1ece8..bb8f5a4 100644
--- a/drivers/staging/comedi/drivers/unioxx5.c
+++ b/drivers/staging/comedi/drivers/unioxx5.c
@@ -72,6 +72,7 @@ Devices: [Fastwel] UNIOxx-5 (unioxx5),
/* 'private' structure for each subdevice */
struct unioxx5_subd_priv {
+ struct comedi_subdevice *subdevice;
int usp_iobase;
/* 12 modules. each can be 70L or 73L */
unsigned char usp_module_type[12];
@@ -94,9 +95,10 @@ static int __unioxx5_define_chan_offset(int chan_num)
static void __unioxx5_digital_config(struct unioxx5_subd_priv *usp,
int mode)
{
int i, mask;
+ struct device *dev = usp->subdevice->class_dev;
mask = (mode == ALL_2_OUTPUT) ? 0xFF : 0x00;
- printk("COMEDI: mode = %d\n", mask);
+ dev_info(dev, "COMEDI: mode = %d\n", mask);
outb(1, usp->usp_iobase + 0);
It would be better to change those functions to pass the pointer to the
struct comedi_subdevice instead of the pointer to the struct
unioxx5_subd_priv.
A variable or parameter named 'dev' in the comedi drivers is usually of
type struct comedi_device for consistency.
The message passed to dev_info() wouldn't need the "COMEDI:" prefix -
it's redundant.
Also, this particular message should be a dev_dbg() at best, and
probably better not to have it at all!
For the sake of example, the above function could start as follows:
static void __unioxx5_digital_config(struct comedi_subdevice *s, int mode)
{
struct unioxx5_subd_priv *usp = s->private;
struct device *csdev = s->device->class_dev;
int i, mask;
mask = (mode == ALL_2_OUTPUT) ? 0xFF : 0x00;
dev_dbg(csdev, "mode = %d\n", mask);
--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH -v2 09/10] mfd: staging: Constify struct mfd_cell where possible
As of commit 03e361b25ee8dfb1fd9b890072c23c4aae01c6c7 ("mfd: Stop setting
refcounting pointers in original mfd_cell arrays"), the "cell" parameter of
mfd_add_devices() is "const" again. Hence make all cell data passed to
mfd_add_devices() const where possible.
Signed-off-by: Geert Uytterhoeven
Cc: Greg Kroah-Hartman
Cc: de...@driverdev.osuosl.org
---
v2: Split in groups
drivers/staging/nvec/nvec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 3066ee2e753b..27d74134f187 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -83,7 +83,7 @@ enum nvec_sleep_subcmds {
static struct nvec_chip *nvec_power_handle;
-static struct mfd_cell nvec_devices[] = {
+static const struct mfd_cell nvec_devices[] = {
{
.name = "nvec-kbd",
.id = 1,
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: staging: media: Use dev_err() instead of pr_err()
On Sun, Nov 17, 2013 at 10:03:21AM -0200, Mauro Carvalho Chehab wrote: > Em Fri, 15 Nov 2013 15:29:39 +0900 > Greg Kroah-Hartman escreveu: > > > On Thu, Nov 14, 2013 at 11:08:14AM -0200, Mauro Carvalho Chehab wrote: > > > Hi, > > > > > > I'm not sure how this patch got applied upstream: > > > > > > commit b6ea5ef80aa7fd6f4b18ff2e4174930e8772e812 > > > Author: Dulshani Gunawardhana > > > Date: Sun Oct 20 22:58:28 2013 +0530 > > > > > > staging:media: Use dev_dbg() instead of pr_debug() > > > > > > Use dev_dbg() instead of pr_debug() in go7007-usb.c. > > > > > > Signed-off-by: Dulshani Gunawardhana > > > > > > Reviewed-by: Josh Triplett > > > Signed-off-by: Greg Kroah-Hartman > > > > > > But, from the custody chain, it seems it was not C/C to linux-media ML, > > > doesn't have the driver maintainer's ack[1] and didn't went via my tree. > > > > It came in through my tree as part of the OPW intern application > > process. > > Ah, OK. > > I don't mind if you apply those directly, but what makes me a little > worried is that at least the final version of the patchset should be > c/c to driver/subsystem maintainers for their review and for them to > know that the patch will be merged via some other tree, as it might > be causing conflicts with their trees. > > > And yes, sorry, it's broken, I have some follow-on patches to fix this, > > but you are right, it should just be reverted for now, very sorry about > > that. > > No problem. > > > Do you want to do that, or should I? > > I prefer if you could do it, as I'm still waiting the merge from my tree, > and I don't want to cascade another pull request before the original > pull requests get handled. In any case, they won't conflict with this, > as I don't have any patch for this driver on my tree for 3.13. Ok, I'll do this after 3.13-rc1 is out, sorry for the problems. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
