Re: [PATCH 00/15] ARM: pxa: switch to DMA slave maps

2018-04-04 Thread Boris Brezillon
On Wed, 04 Apr 2018 21:49:26 +0200
Robert Jarzmik  wrote:

> Ulf Hansson  writes:
> 
> > On 2 April 2018 at 16:26, Robert Jarzmik  wrote:  
> >> Hi,
> >>
> >> This serie is aimed at removing the dmaengine slave compat use, and 
> >> transfer
> >> knowledge of the DMA requestors into architecture code.
> >> As this looks like a patch bomb, each maintainer expressing for his tree 
> >> either
> >> an Ack or "I want to take through my tree" will be spared in the next 
> >> iterations
> >> of this serie.  
> >
> > Perhaps an option is to send this hole series as PR for 3.17 rc1, that
> > would removed some churns and make this faster/easier? Well, if you
> > receive the needed acks of course.  
> For 3.17-rc1 it looks a bit optimistic with the review time ... If I have all

Especially since 3.17-rc1 has been released more than 3 years ago :-),
but I guess you meant 4.17-rc1.

> acks, I'll queue it into my pxa tree. If at least one maintainer withholds his
> ack, the end of the serie (phase 3) won't be applied until it is sorted out.
> 
> Cheers.
> 
> --
> Robert



Re: [PATCH 00/47] arch-removal: device drivers

2018-03-14 Thread Boris Brezillon
Hi Arnd,

On Wed, 14 Mar 2018 16:35:13 +0100
Arnd Bergmann <a...@arndb.de> wrote:

> Hi driver maintainers,
> 
> I just posted one series with the removal of eight architectures,
> see https://lkml.org/lkml/2018/3/14/505 for details, or
> https://lwn.net/Articles/748074/ for more background.
> 
> These are the device drivers that go along with them. I have already
> picked up the drivers for arch/metag/ into my tree, they were reviewed
> earlier.
> 
> Please let me know if you have any concerns with the patch, or if you
> prefer to pick up the patches in your respective trees.  I created
> the patches with 'git format-patch -D', so they will not apply without
> manually removing those files.
> 
> For anything else, I'd keep the removal patches in my asm-generic tree
> and will send a pull request for 4.17 along with the actual arch removal.
> 
>Arnd
> 
> Arnd Bergmann
>   edac: remove tile driver
>   net: tile: remove ethernet drivers
>   net: adi: remove blackfin ethernet drivers
>   net: 8390: remove m32r specific bits
>   net: remove cris etrax ethernet driver
>   net: smsc: remove m32r specific smc91x configuration
>   raid: remove tile specific raid6 implementation
>   rtc: remove tile driver
>   rtc: remove bfin driver
>   char: remove obsolete ds1302 rtc driver
>   char: remove tile-srom.c
>   char: remove blackfin OTP driver
>   pcmcia: remove m32r drivers
>   pcmcia: remove blackfin driver
>   ASoC: remove blackfin drivers
>   video/logo: remove obsolete logo files
>   fbdev: remove blackfin drivers
>   fbdev: s1d13xxxfb: remove m32r specific hacks
>   crypto: remove blackfin CRC driver
>   media: platform: remove blackfin capture driver
>   media: platform: remove m32r specific arv driver
>   cpufreq: remove blackfin driver
>   cpufreq: remove cris specific drivers
>   gpio: remove etraxfs driver
>   pinctrl: remove adi2/blackfin drivers
>   ata: remove bf54x driver
>   input: keyboard: remove bf54x driver
>   input: misc: remove blackfin rotary driver
>   mmc: remove bfin_sdh driver
>   can: remove bfin_can driver
>   watchdog: remove bfin_wdt driver
>   mtd: maps: remove bfin-async-flash driver
>   mtd: nand: remove bf5xx_nand driver

If you don't mind, I'd like to take the mtd patches through the MTD
tree. As you've probably noticed, nand code has been moved around and
it's easier for me to carry those 2 simple changes in my tree than
creating an immutable branch.

Let me know if this is a problem.

Regards,

Boris

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [PATCH v2] MAINTAINERS: mtd/nand: update Microchip nand entry

2018-01-12 Thread Boris Brezillon
On Thu, 11 Jan 2018 17:26:59 +0100
Nicolas Ferre  wrote:

> Update Wenyou Yang email address.
> Take advantage of this update to move this entry to the MICROCHIP / ATMEL
> location and add the DT binding documentation link.
> 
> Signed-off-by: Nicolas Ferre 
> Acked-by: Wenyou Yang 

Applied.

Thanks,

Boris

> ---
> v2: - patch agains 09ec417b0ea8 ("mtd: nand: samsung: Disable subpage
>   writes on E-die NAND") of 
>   http://git.infradead.org/linux-mtd.git/shortlog/refs/heads/nand/next
> - Ack by Wenyou added
> 
> 
> Hi,
> 
> v1 patch was part of a series because it was conflicting with the previous one
> named:
> "[PATCH 1/2] MAINTAINERS: linux-media: update Microchip ISI and ISC entries"
> Boris asked me to rebase it so that they are independent.
> So, if this first one goes upstream through another tree, conflicts will have
> to be resolved at one point.
> 
> Best regards,
>   Nicolas
> 
> 
>  MAINTAINERS | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index aa71ab52fd76..37ee5ae4bae2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2382,13 +2382,6 @@ F: 
> Documentation/devicetree/bindings/input/atmel,maxtouch.txt
>  F:   drivers/input/touchscreen/atmel_mxt_ts.c
>  F:   include/linux/platform_data/atmel_mxt_ts.h
>  
> -ATMEL NAND DRIVER
> -M:   Wenyou Yang 
> -M:   Josh Wu 
> -L:   linux-...@lists.infradead.org
> -S:   Supported
> -F:   drivers/mtd/nand/atmel/*
> -
>  ATMEL SAMA5D2 ADC DRIVER
>  M:   Ludovic Desroches 
>  L:   linux-...@vger.kernel.org
> @@ -9045,6 +9038,14 @@ F: drivers/media/platform/atmel/atmel-isc.c
>  F:   drivers/media/platform/atmel/atmel-isc-regs.h
>  F:   devicetree/bindings/media/atmel-isc.txt
>  
> +MICROCHIP / ATMEL NAND DRIVER
> +M:   Wenyou Yang 
> +M:   Josh Wu 
> +L:   linux-...@lists.infradead.org
> +S:   Supported
> +F:   drivers/mtd/nand/atmel/*
> +F:   Documentation/devicetree/bindings/mtd/atmel-nand.txt
> +
>  MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
>  M:   Woojung Huh 
>  M:   Microchip Linux Driver Support 



Re: [PATCH 06/15] mtd: make device_type const

2017-08-21 Thread Boris Brezillon
Le Sat, 19 Aug 2017 13:52:17 +0530,
Bhumika Goyal  a écrit :

> Make this const as it is only stored in the type field of a device
> structure, which is const.
> Done using Coccinelle.
> 

Applied to l2-mtd/master.

Thanks,

Boris

> Signed-off-by: Bhumika Goyal 
> ---
>  drivers/mtd/mtdcore.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index f872a99..e7ea842 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -340,7 +340,7 @@ static ssize_t mtd_bbtblocks_show(struct device *dev,
>  };
>  ATTRIBUTE_GROUPS(mtd);
>  
> -static struct device_type mtd_devtype = {
> +static const struct device_type mtd_devtype = {
>   .name   = "mtd",
>   .groups = mtd_groups,
>   .release= mtd_release,



Re: [PATCH 1/6] drm: Add writeback connector type

2017-05-05 Thread Boris Brezillon
On Fri, 25 Nov 2016 16:48:59 +
Brian Starkey  wrote:

> +/**
> + * drm_writeback_connector_init - Initialize a writeback connector and its 
> properties
> + * @dev: DRM device
> + * @wb_connector: Writeback connector to initialize
> + * @funcs: Connector funcs vtable
> + * @formats: Array of supported pixel formats for the writeback engine
> + * @n_formats: Length of the formats array
> + *
> + * This function creates the writeback-connector-specific properties if they
> + * have not been already created, initializes the connector as
> + * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the property
> + * values.
> + *
> + * Drivers should always use this function instead of drm_connector_init() to
> + * set up writeback connectors.
> + *
> + * Returns: 0 on success, or a negative error code
> + */
> +int drm_writeback_connector_init(struct drm_device *dev,
> +  struct drm_writeback_connector *wb_connector,
> +  const struct drm_connector_funcs *funcs,
> +  u32 *formats, int n_formats)

This should probably be 'const u32 *formats', since developers are
likely to define a this array with a 'static const' specifier in their
driver.


Re: [PATCH 1/6] drm: Add writeback connector type

2017-04-19 Thread Boris Brezillon
On Wed, 19 Apr 2017 10:51:23 +0100
Brian Starkey <brian.star...@arm.com> wrote:

> On Tue, Apr 18, 2017 at 09:57:17PM +0200, Boris Brezillon wrote:
> >Hi Brian,
> >
> >On Tue, 18 Apr 2017 18:34:43 +0100
> >Brian Starkey <brian.star...@arm.com> wrote:
> >  
> >> >> @@ -214,6 +214,19 @@ struct drm_connector_state {
> >> >> struct drm_encoder *best_encoder;
> >> >>
> >> >> struct drm_atomic_state *state;
> >> >> +
> >> >> +   /**
> >> >> +* @writeback_job: Writeback job for writeback connectors
> >> >> +*
> >> >> +* Holds the framebuffer for a writeback connector. As the 
> >> >> writeback
> >> >> +* completion may be asynchronous to the normal commit cycle, 
> >> >> the
> >> >> +* writeback job lifetime is managed separately from the normal 
> >> >> atomic
> >> >> +* state by this object.
> >> >> +*
> >> >> +* See also: drm_writeback_queue_job() and
> >> >> +* drm_writeback_signal_completion()
> >> >> +*/
> >> >> +   struct drm_writeback_job *writeback_job;  
> >> >
> >> >Maybe I'm wrong, but is feels weird to have the writeback_job field
> >> >directly embedded in drm_connector_state, while drm_writeback_connector
> >> >inherits from drm_connector.
> >> >
> >> >IMO, either you decide to directly put the drm_writeback_connector's
> >> >job_xxx fields in drm_connector and keep the drm_connector_state as is,
> >> >or you create a drm_writeback_connector_state which inherits from
> >> >drm_connector_state and embeds the writeback_job field.  
> >>
> >> I did spend a decent amount of time looking at tracking the writeback
> >> state along with the normal connector state. I couldn't come up with
> >> anything I liked.
> >>
> >> As the comment mentions, one of the problems is that you have to make
> >> sure the relevant parts of the connector_state stay around until the
> >> writeback is finished. That means you've got to block before
> >> "swap_state()" until the previous writeback is done, and that
> >> effectively limits your frame rate to refresh/2.
> >>
> >> The Mali-DP HW doesn't have that limitation - we can queue up a new
> >> commit while the current writeback is ongoing. For that reason I
> >> didn't want to impose such a limitation in the framework.
> >>
> >> In v1 I allowed that by making the Mali-DP driver hold its own
> >> references to the relevant bits of the state for as long as it needed
> >> them. In v3 I moved most of that code back to the core (in part
> >> because Gustavo didn't like me signalling the DRM-"owned" fence from
> >> my driver code directly). I think the new approach of "queue_job()"
> >> and "signal_job()" reduces the amount of tricky code in drivers, and
> >> is generally more clear (also familiar, when compared to vsync
> >> events).
> >>
> >> I'm certain there's other ways to do it (refcount atomic states?), but
> >> it seemed like a biggish overhaul to achieve what would basically be
> >> the same thing.
> >>
> >> I was expecting each driver supporting writeback to have its own
> >> different requirements around writeback lifetime/duration. For example
> >> I think VC4 specifically came up, in that its writeback could take
> >> several frames, whereas on Mali-DP we either finish within the frame
> >> or we fail.
> >>
> >> Letting the driver manage its writeback_job lifetime seemed like a
> >> reasonable way to handle all that, with the documentation stating the
> >> only behaviour which is guaranteed to work on all drivers:
> >>
> >>* Userspace should wait for this fence to signal before making 
> >> another
> >>* commit affecting any of the same CRTCs, Planes or Connectors.
> >>* **Failure to do so will result in undefined behaviour.**
> >>* For this reason it is strongly recommended that all userspace
> >>* applications making use of writeback connectors *always* retrieve 
> >> an
> >>* out-fence for the commit and use it appropriately.
> >>
> >>
> >>
> >> ... so all of that is why the _job 

Re: [PATCH 1/6] drm: Add writeback connector type

2017-04-18 Thread Boris Brezillon
Hi Brian,

On Tue, 18 Apr 2017 18:34:43 +0100
Brian Starkey  wrote:

> >> @@ -214,6 +214,19 @@ struct drm_connector_state {
> >>struct drm_encoder *best_encoder;
> >>
> >>struct drm_atomic_state *state;
> >> +
> >> +  /**
> >> +   * @writeback_job: Writeback job for writeback connectors
> >> +   *
> >> +   * Holds the framebuffer for a writeback connector. As the writeback
> >> +   * completion may be asynchronous to the normal commit cycle, the
> >> +   * writeback job lifetime is managed separately from the normal atomic
> >> +   * state by this object.
> >> +   *
> >> +   * See also: drm_writeback_queue_job() and
> >> +   * drm_writeback_signal_completion()
> >> +   */
> >> +  struct drm_writeback_job *writeback_job;  
> >
> >Maybe I'm wrong, but is feels weird to have the writeback_job field
> >directly embedded in drm_connector_state, while drm_writeback_connector
> >inherits from drm_connector.
> >
> >IMO, either you decide to directly put the drm_writeback_connector's
> >job_xxx fields in drm_connector and keep the drm_connector_state as is,
> >or you create a drm_writeback_connector_state which inherits from
> >drm_connector_state and embeds the writeback_job field.  
> 
> I did spend a decent amount of time looking at tracking the writeback
> state along with the normal connector state. I couldn't come up with
> anything I liked.
> 
> As the comment mentions, one of the problems is that you have to make
> sure the relevant parts of the connector_state stay around until the
> writeback is finished. That means you've got to block before
> "swap_state()" until the previous writeback is done, and that
> effectively limits your frame rate to refresh/2.
> 
> The Mali-DP HW doesn't have that limitation - we can queue up a new
> commit while the current writeback is ongoing. For that reason I
> didn't want to impose such a limitation in the framework.
> 
> In v1 I allowed that by making the Mali-DP driver hold its own
> references to the relevant bits of the state for as long as it needed
> them. In v3 I moved most of that code back to the core (in part
> because Gustavo didn't like me signalling the DRM-"owned" fence from
> my driver code directly). I think the new approach of "queue_job()"
> and "signal_job()" reduces the amount of tricky code in drivers, and
> is generally more clear (also familiar, when compared to vsync
> events).
> 
> I'm certain there's other ways to do it (refcount atomic states?), but
> it seemed like a biggish overhaul to achieve what would basically be
> the same thing.
> 
> I was expecting each driver supporting writeback to have its own
> different requirements around writeback lifetime/duration. For example
> I think VC4 specifically came up, in that its writeback could take
> several frames, whereas on Mali-DP we either finish within the frame
> or we fail.
> 
> Letting the driver manage its writeback_job lifetime seemed like a
> reasonable way to handle all that, with the documentation stating the
> only behaviour which is guaranteed to work on all drivers:
> 
>* Userspace should wait for this fence to signal before making another
>* commit affecting any of the same CRTCs, Planes or Connectors.
>* **Failure to do so will result in undefined behaviour.**
>* For this reason it is strongly recommended that all userspace
>* applications making use of writeback connectors *always* retrieve an
>* out-fence for the commit and use it appropriately.
> 
> 
> 
> ... so all of that is why the _job fields don't live in a *_state
> structure directly, and instead have to live in the separately-managed
> structure pointed to by ->writeback_job.
> 
> Now, I did look at creating drm_writeback_connector_state, but as it
> would only be holding the job pointer (see above) it didn't seem worth
> scattering around the
> 
> if (conn_state->connector->connector_type ==
> DRM_MODE_CONNECTOR_WRITEBACK)
> 
> checks everywhere before up-casting - {clear,reset,duplicate}_state(),
> prepare_signalling(), complete_signalling(), etc. It just touched a
> lot of code for the sake of an extra pointer field in each connector
> state.
> 
> I can easily revisit that part if you like.

I think there's a misunderstanding. I was just suggesting to be
consistent in the inheritance vs 'one object to handle everything'
approach.

I'm perfectly fine with embedding the writeback_job pointer directly in
drm_connector_state, but then it would IMO make more sense to do the
same for the drm_connector object (embed drm_writeback_connector fields
into drm_connector instead of making drm_writeback_connector inherit
from drm_connector).

Anyway, that's just a detail.

> 
> >
> >Anyway, wait for Daniel's feedback before doing this change.
> >  
> 
> Am I expecting some more feedback from Daniel?

No, I was just saying that before doing the changes I was suggesting,
you should wait for Daniel's opinion, because I might be wrong.

> 
> 

Re: [PATCH 2/6] drm: writeback: Add out-fences for writeback connectors

2017-04-14 Thread Boris Brezillon
On Fri, 25 Nov 2016 16:49:00 +
Brian Starkey  wrote:

> Add the OUT_FENCE_PTR property to writeback connectors, to enable
> userspace to get a fence which will signal once the writeback is
> complete. It is not allowed to request an out-fence without a
> framebuffer attached to the connector.
> 
> A timeline is added to drm_writeback_connector for use by the writeback
> out-fences.
> 
> In the case of a commit failure or DRM_MODE_ATOMIC_TEST_ONLY, the fence
> is set to -1.
> 
> Changes from v2:
>  - Rebase onto Gustavo Padovan's v9 explicit sync series
>  - Change out_fence_ptr type to s32 __user *

Don't know what happened, but I still see s32 __user * types in this
patch (I had to patch it to make in work on top of 4.11-rc1).


Re: [PATCH 1/6] drm: Add writeback connector type

2017-04-14 Thread Boris Brezillon
On Fri, 25 Nov 2016 16:48:59 +
Brian Starkey  wrote:


>  
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b5c6a8e..6bbd93f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -86,6 +86,7 @@ struct drm_conn_prop_enum_list {
>   { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
>   { DRM_MODE_CONNECTOR_DSI, "DSI" },
>   { DRM_MODE_CONNECTOR_DPI, "DPI" },
> + { DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },

Is there a reason we have a Writeback connector, but keep using a
Virtual encoder to connect it to the CRTC? Wouldn't it make more sense
to also add a Writeback encoder?

>  };
>  
>  void drm_connector_ida_init(void)
> @@ -235,7 +236,8 @@ int drm_connector_init(struct drm_device *dev,
>   list_add_tail(>head, >connector_list);
>   config->num_connector++;
>  
> - if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)
> + if ((connector_type != DRM_MODE_CONNECTOR_VIRTUAL) &&
> + (connector_type != DRM_MODE_CONNECTOR_WRITEBACK))

Nitpick: you don't need the extra parenthesis:

if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL &&
connector_type != DRM_MODE_CONNECTOR_WRITEBACK)

>   drm_object_attach_property(>base,
> config->edid_property,
> 0);



> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 34f9741..dc4910d6 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -214,6 +214,19 @@ struct drm_connector_state {
>   struct drm_encoder *best_encoder;
>  
>   struct drm_atomic_state *state;
> +
> + /**
> +  * @writeback_job: Writeback job for writeback connectors
> +  *
> +  * Holds the framebuffer for a writeback connector. As the writeback
> +  * completion may be asynchronous to the normal commit cycle, the
> +  * writeback job lifetime is managed separately from the normal atomic
> +  * state by this object.
> +  *
> +  * See also: drm_writeback_queue_job() and
> +  * drm_writeback_signal_completion()
> +  */
> + struct drm_writeback_job *writeback_job;

Maybe I'm wrong, but is feels weird to have the writeback_job field
directly embedded in drm_connector_state, while drm_writeback_connector
inherits from drm_connector.

IMO, either you decide to directly put the drm_writeback_connector's
job_xxx fields in drm_connector and keep the drm_connector_state as is,
or you create a drm_writeback_connector_state which inherits from
drm_connector_state and embeds the writeback_job field.

Anyway, wait for Daniel's feedback before doing this change.

>  };
>  
>  /**
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index bf9991b2..3d3d07f 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -634,6 +634,20 @@ struct drm_mode_config {
>*/
>   struct drm_property *suggested_y_property;
>  
> + /**
> +  * @writeback_fb_id_property: Property for writeback connectors, storing
> +  * the ID of the output framebuffer.
> +  * See also: drm_writeback_connector_init()
> +  */
> + struct drm_property *writeback_fb_id_property;
> + /**
> +  * @writeback_pixel_formats_property: Property for writeback connectors,
> +  * storing an array of the supported pixel formats for the writeback
> +  * engine (read-only).
> +  * See also: drm_writeback_connector_init()
> +  */
> + struct drm_property *writeback_pixel_formats_property;
> +
>   /* dumb ioctl parameters */
>   uint32_t preferred_depth, prefer_shadow;
>  
> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> new file mode 100644
> index 000..6b2ac45
> --- /dev/null
> +++ b/include/drm/drm_writeback.h
> @@ -0,0 +1,78 @@
> +/*
> + * (C) COPYRIGHT 2016 ARM Limited. All rights reserved.
> + * Author: Brian Starkey 
> + *
> + * This program is free software and is provided to you under the terms of 
> the
> + * GNU General Public License version 2 as published by the Free Software
> + * Foundation, and any use by you of this program is subject to the terms
> + * of such GNU licence.
> + */
> +
> +#ifndef __DRM_WRITEBACK_H__
> +#define __DRM_WRITEBACK_H__
> +#include 
> +#include 
> +
> +struct drm_writeback_connector {
> + struct drm_connector base;

AFAIU, a writeback connector will always require an 'dummy' encoder to
make the DRM framework happy (AFAIK, a connector is always connected to
a CRTC through an encoder).

Wouldn't it make more sense to have a drm_encoder object embedded in
drm_writeback_connector so that people don't have to declare an extra
structure containing both the drm_writeback_connector connector and a
drm_encoder? Is there a good reason to keep them separate?

> +
> + /**
> +  * 

Re: [PATCH 6/6] drm: mali-dp: Add writeback connector

2017-04-14 Thread Boris Brezillon
On Fri, 25 Nov 2016 16:49:04 +
Brian Starkey  wrote:

> +static int
> +malidp_mw_encoder_atomic_check(struct drm_encoder *encoder,
> +struct drm_crtc_state *crtc_state,
> +struct drm_connector_state *conn_state)
> +{
> + struct malidp_mw_connector_state *mw_state = to_mw_state(conn_state);
> + struct malidp_drm *malidp = encoder->dev->dev_private;
> + struct drm_framebuffer *fb;
> + int i, n_planes;
> +
> + if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
> + return 0;
> +
> + fb = conn_state->writeback_job->fb;
> + if ((fb->width != crtc_state->mode.hdisplay) ||
> + (fb->height != crtc_state->mode.vdisplay)) {
> + DRM_DEBUG_KMS("Invalid framebuffer size %ux%u\n",
> + fb->width, fb->height);
> + return -EINVAL;
> + }

These checks look pretty generic to me. Shouldn't we have a default
helper doing that?

> +
> + mw_state->format =
> + malidp_hw_get_format_id(>dev->map, SE_MEMWRITE,
> + fb->pixel_format);
> + if (mw_state->format == MALIDP_INVALID_FORMAT_ID) {

Same goes here. By adding a format_types table similar to what is
exposed in drm_plane [1], we could do this check in the core. The only
thing left to the driver is the 4CC -> driver-specific-id conversion.

> + struct drm_format_name_buf format_name;
> +
> + DRM_DEBUG_KMS("Invalid pixel format %s\n",
> +   drm_get_format_name(fb->pixel_format, 
> _name));
> + return -EINVAL;
> + }
> +
> + n_planes = drm_format_num_planes(fb->pixel_format);
> + for (i = 0; i < n_planes; i++) {
> + struct drm_gem_cma_object *obj = drm_fb_cma_get_gem_obj(fb, i);
> + if (!malidp_hw_pitch_valid(malidp->dev, fb->pitches[i])) {
> + DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
> +   fb->pitches[i], i);
> + return -EINVAL;
> + }
> + mw_state->pitches[i] = fb->pitches[i];
> + mw_state->addrs[i] = obj->paddr + fb->offsets[i];
> + }
> + mw_state->n_planes = n_planes;
> +
> + return 0;
> +}


[1]http://lxr.free-electrons.com/source/include/drm/drm_plane.h#L482


Re: [RFC PATCH v3 0/6] Introduce writeback connectors

2017-04-14 Thread Boris Brezillon
Hi Brian,

On Fri, 25 Nov 2016 16:48:58 +
Brian Starkey  wrote:

> Hi,
> 
> This is v3 of my series introducing a new connector type:
>  DRM_MODE_CONNECTOR_WRITEBACK
> See v1 and v2 here: [1] [2]
> 
> Writeback connectors are used to expose the memory writeback engines
> found in some display controllers, which can write a CRTC's
> composition result to a memory buffer.
> This is useful e.g. for testing, screen-recording, screenshots,
> wireless display, display cloning, memory-to-memory composition.
> 
> Writeback connectors are given a WRITEBACK_FB_ID property (which acts
> slightly differently to FB_ID, so gets a new name), as well as
> a PIXEL_FORMATS blob to list the supported writeback formats, and
> OUT_FENCE_PTR to be used for out-fences.
> 
> The changes since v2 are in the commit messages of each commit.
> 
> The main differences are:
>  - Subclass drm_connector as drm_writeback_connector
>  - Slight relaxation of core checks, to allow
>(connector->crtc && !connector->fb)
>  - Dropped PIXEL_FORMATS_SIZE, which was redundant
>  - Reworked the event interface, drivers don't need to deal with the
>fence directly
>  - Re-ordered the commits to introduce writeback out-fences up-front.
> 
> I've kept RFC on this series because the event reporting (introduction
> of drm_writeback_job) is probably up for debate.
> 
> v4 will be accompanied by igt tests.

I plan to add writeback support to the VC4 driver and wanted to know if
anything has changed since this v3 (IOW, do you have a v4 + igt tests
ready)?

> 
> As always, I look forward to any comments.

I'll try to review these patches. Keep in mind that I didn't follow the
initial discussions and might suggest things or ask questions that have
already been answered in previous versions of this series or on IRC.

Regards,

Boris


Re: [PATCH v4 1/2] [media] atmel-isc: add the Image Sensor Controller code

2016-06-08 Thread Boris Brezillon
clk_name = "isc-ispck";

Hm, that's a bit weird, but I guess you have no other choice, since
this clock is only used internally.

> +
> + init.parent_names   = parent_names;
> + init.num_parents= num_parents;
> + init.name   = clk_name;
> + init.ops= _clk_ops;
> + init.flags  = CLK_SET_RATE_GATE | CLK_SET_PARENT_GATE;
> +
> + isc_clk = >isc_clks[id];
> + isc_clk->hw.init= 
> + isc_clk->regmap = regmap;
> + isc_clk->lock   = >clk_lock;
> + isc_clk->id = id;
> + isc_clk->isc= isc;
> +
> + isc_clk->clk = clk_register(NULL, _clk->hw);

clk_register(isc->dev, _clk->hw);

> + if (IS_ERR(isc_clk->clk)) {
> + dev_err(isc->dev, "%s: clock register fail\n", clk_name);
> + ret = PTR_ERR(isc_clk->clk);
> + goto free_parent_names;
> + } else if (id == ISC_MCK)
> + of_clk_add_provider(np, of_clk_src_simple_get, isc_clk->clk);
> +
> +free_parent_names:
> + kfree(parent_names);
> + return ret;
> +}
> +
> +static int isc_clk_init(struct isc_device *isc)
> +{
> + unsigned int i;
> + int ret;
> +
> + for (i = 0; i < ARRAY_SIZE(isc->isc_clks); i++)
> + isc->isc_clks[i].clk = ERR_PTR(-EINVAL);
> +
> + spin_lock_init(>clk_lock);
> +
> + for (i = 0; i < 2; i++) {
> + ret = isc_clk_register(isc, i);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void isc_clk_cleanup(struct isc_device *isc)
> +{
> + unsigned int i;
> +
> + of_clk_del_provider(isc->dev->of_node);
> +
> + for (i = 0; i < ARRAY_SIZE(isc->isc_clks); i++) {
> + struct isc_clk *isc_clk = >isc_clks[i];
> +
> + if (!IS_ERR(isc_clk->clk))
> + clk_unregister(isc_clk->clk);
> + }
> +}
> +
> +static int isc_queue_setup(struct vb2_queue *vq,
> +unsigned int *nbuffers, unsigned int *nplanes,
> +unsigned int sizes[], void *alloc_ctxs[])

Try to align parameters to the open parenthesis.

> +{
> + struct isc_device *isc = vb2_get_drv_priv(vq);
> + unsigned int size = isc->fmt.fmt.pix.sizeimage;
> +
> + alloc_ctxs[0] = isc->alloc_ctx;
> +
> + if (*nplanes)
> + return sizes[0] < size ? -EINVAL : 0;
> +
> + *nplanes = 1;
> + sizes[0] = size;
> +
> + return 0;
> +}
> +
> +static int isc_buffer_prepare(struct vb2_buffer *vb)
> +{
> + struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
> + struct isc_device *isc = vb2_get_drv_priv(vb->vb2_queue);
> + unsigned long size = isc->fmt.fmt.pix.sizeimage;
> +
> + if (vb2_plane_size(vb, 0) < size) {
> + v4l2_err(>v4l2_dev, "buffer too small (%lu < %lu)\n",
> +  vb2_plane_size(vb, 0), size);
> + return -EINVAL;
> + }
> +
> + vb2_set_plane_payload(vb, 0, size);
> +
> + vbuf->field = isc->fmt.fmt.pix.field;
> +
> + return 0;
> +}
> +
> +static inline void isc_start_dma(struct regmap *regmap,
> +  struct isc_buffer *frm, u32 dview)
> +{
> + dma_addr_t addr;
> +
> + addr = vb2_dma_contig_plane_dma_addr(>vb.vb2_buf, 0);
> +
> + regmap_write(regmap, ISC_DCTRL, dview | ISC_DCTRL_IE_IS);
> + regmap_write(regmap, ISC_DAD0, addr);
> + regmap_update_bits(regmap, ISC_CTRLEN,
> +ISC_CTRLEN_CAPTURE_MASK, ISC_CTRLEN_CAPTURE);
> +}
> +
> +static inline bool sensor_is_preferred(const struct isc_format *isc_fmt)
> +{
> + if ((sensor_preferred && isc_fmt->sd_support) ||
> + !isc_fmt->isc_support)
> + return true;
> + else
> + return false;
> +}
> +
> +static void isc_set_pipeline(struct regmap *regmap, u32 pipeline)
> +{
> + const struct reg_mask *reg = _regs[0];
> + u32 val;
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(pipeline_regs); i++) {
> + if (pipeline & BIT(i))
> + val = reg->mask;
> + else
> + val = 0;
> +
> + regmap_update_bits(regmap, reg->reg, reg->mask, val);

regmap_field_update_bits();

> +
> + reg++;
> + }
> +}

It's a long driver, so I'll leave the remaining bits for someone else,
but I guess you got the idea on the different aspects I pointed out,
and you'll be able to adjust the rest of the code accordingly ;).

Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/4] mm: add is_highmem_addr() helper

2016-04-04 Thread Boris Brezillon
On Mon, 4 Apr 2016 13:44:11 +0530
Vignesh R <vigne...@ti.com> wrote:

> Hi,
> 
> On 03/31/2016 05:59 PM, Boris Brezillon wrote:
> > Add an helper to check if a virtual address is in the highmem region.
> > 
> > Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> > ---
> >  include/linux/highmem.h | 13 +
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/include/linux/highmem.h b/include/linux/highmem.h
> > index bb3f329..13dff37 100644
> > --- a/include/linux/highmem.h
> > +++ b/include/linux/highmem.h
> > @@ -41,6 +41,14 @@ void kmap_flush_unused(void);
> >  
> >  struct page *kmap_to_page(void *addr);
> >  
> > +static inline bool is_highmem_addr(const void *x)
> > +{
> > +   unsigned long vaddr = (unsigned long)x;
> > +
> > +   return vaddr >=  PKMAP_BASE &&
> > +  vaddr < ((PKMAP_BASE + LAST_PKMAP) * PAGE_SIZE);
> 
> 
> Shouldn't this be:
>   vaddr < (PKMAP_BASE + (LAST_PKMAP * PAGE_SIZE)) ?

Oops, yes indeed.

Anyway, given Russell's feedback I don't think I'm gonna follow up on
this series.

Sorry.

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/4] scatterlist: add sg_alloc_table_from_buf() helper

2016-03-31 Thread Boris Brezillon
Hi Russell,

On Thu, 31 Mar 2016 15:14:13 +0100
Russell King - ARM Linux <li...@arm.linux.org.uk> wrote:

> On Thu, Mar 31, 2016 at 02:29:42PM +0200, Boris Brezillon wrote:
> > sg_alloc_table_from_buf() provides an easy solution to create an sg_table
> > from a virtual address pointer. This function takes care of dealing with
> > vmallocated buffers, buffer alignment, or DMA engine limitations (maximum
> > DMA transfer size).
> 
> Please note that the DMA API does not take account of coherency of memory
> regions other than non-high/lowmem - there are specific extensions to
> deal with this.

Ok, you said 'non-high/lowmem', this means vmalloced and kmapped buffers
already fall in this case, right?

Could you tell me more about those specific extensions?

> 
> What this means is that having an API that takes any virtual address
> pointer, converts it to a scatterlist which is then DMA mapped, is
> unsafe.

Which means some implementations already get this wrong (see
spi_map_buf(), and I'm pretty sure it's not the only one).

> 
> It'll be okay for PIPT and non-aliasing VIPT cache architectures, but
> for other cache architectures this will hide this problem and make
> review harder.
> 

Ok, you lost me. I'll have to do my homework and try to understand what
this means :).

Thanks for your valuable inputs.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 4/4] mtd: provide helper to prepare buffers for DMA operations

2016-03-31 Thread Boris Brezillon
Some NAND controller drivers are making use of DMA to transfer data from
the controller to the buffer passed by the MTD user.
Provide a generic mtd_map/unmap_buf() implementation to avoid open coded
(and sometime erroneous) implementations.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/mtdcore.c   | 66 +
 include/linux/mtd/mtd.h | 25 +++
 2 files changed, 91 insertions(+)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 3096251..4c20f33 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1253,6 +1253,72 @@ void *mtd_kmalloc_up_to(const struct mtd_info *mtd, 
size_t *size)
 }
 EXPORT_SYMBOL_GPL(mtd_kmalloc_up_to);
 
+#ifdef CONFIG_HAS_DMA
+/**
+ * mtd_map_buf - create an SG table and prepare it for DMA operations
+ *
+ * @mtd: mtd device description object pointer
+ * @dev: device handling the DMA operation
+ * @buf: buf used to create the SG table
+ * @len: length of buf
+ * @constraints: optional constraints to take into account when creating
+ *  the SG table. Can be NULL if no specific constraints
+ *  are required.
+ * @dir: direction of the DMA operation
+ *
+ * This function should be used when an MTD driver wants to do DMA operations
+ * on a buffer passed by the MTD layer. This functions takes care of
+ * vmallocated buffer constraints, and return and sg_table that you can safely
+ * use.
+ */
+int mtd_map_buf(struct mtd_info *mtd, struct device *dev,
+   struct sg_table *sgt, const void *buf, size_t len,
+   const struct sg_constraints *constraints,
+   enum dma_data_direction dir)
+{
+   int ret;
+
+   ret = sg_alloc_table_from_buf(sgt, buf, len, constraints, GFP_KERNEL);
+   if (ret)
+   return ret;
+
+   ret = dma_map_sg(dev, sgt->sgl, sgt->nents, dir);
+   if (!ret)
+   ret = -ENOMEM;
+
+   if (ret < 0) {
+   sg_free_table(sgt);
+   return ret;
+   }
+
+   sgt->nents = ret;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(mtd_map_buf);
+
+/**
+ * mtd_unmap_buf - unmap an SG table and release its resources
+ *
+ * @mtd: mtd device description object pointer
+ * @dev: device handling the DMA operation
+ * @sgt: SG table
+ * @dir: direction of the DMA operation
+ *
+ * This function unmaps a previously mapped SG table and release SG table
+ * resources. Should be called when your DMA operation is done.
+ */
+void mtd_unmap_buf(struct mtd_info *mtd, struct device *dev,
+  struct sg_table *sgt, enum dma_data_direction dir)
+{
+   if (sgt->orig_nents) {
+   dma_unmap_sg(dev, sgt->sgl, sgt->orig_nents, dir);
+   sg_free_table(sgt);
+   }
+}
+EXPORT_SYMBOL_GPL(mtd_unmap_buf);
+#endif /* !CONFIG_HAS_DMA */
+
 #ifdef CONFIG_PROC_FS
 
 /**/
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 7712721..15cff85 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -410,6 +411,30 @@ extern void register_mtd_user (struct mtd_notifier *new);
 extern int unregister_mtd_user (struct mtd_notifier *old);
 void *mtd_kmalloc_up_to(const struct mtd_info *mtd, size_t *size);
 
+#ifdef CONFIG_HAS_DMA
+int mtd_map_buf(struct mtd_info *mtd, struct device *dev,
+   struct sg_table *sgt, const void *buf, size_t len,
+   const struct sg_constraints *constraints,
+   enum dma_data_direction dir);
+void mtd_unmap_buf(struct mtd_info *mtd, struct device *dev,
+  struct sg_table *sgt, enum dma_data_direction dir);
+#else
+static inline int mtd_map_buf(struct mtd_info *mtd, struct device *dev,
+ struct sg_table *sgt, const void *buf,
+ size_t len,
+ const struct sg_constraints *constraints
+ enum dma_data_direction dir)
+{
+   return -ENOTSUPP;
+}
+
+static void mtd_unmap_buf(struct mtd_info *mtd, struct device *dev,
+ struct sg_table *sgt, enum dma_data_direction dir)
+{
+   return -ENOTSUPP;
+}
+#endif
+
 void mtd_erase_callback(struct erase_info *instr);
 
 static inline int mtd_is_bitflip(int err) {
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/4] spi: use sg_alloc_table_from_buf()

2016-03-31 Thread Boris Brezillon
Replace custom implementation of sg_alloc_table_from_buf() by a call to
sg_alloc_table_from_buf().

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/spi/spi.c | 45 +
 1 file changed, 5 insertions(+), 40 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index de2f2f9..eed461d 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -705,49 +705,14 @@ static int spi_map_buf(struct spi_master *master, struct 
device *dev,
   struct sg_table *sgt, void *buf, size_t len,
   enum dma_data_direction dir)
 {
-   const bool vmalloced_buf = is_vmalloc_addr(buf);
-   unsigned int max_seg_size = dma_get_max_seg_size(dev);
-   int desc_len;
-   int sgs;
-   struct page *vm_page;
-   void *sg_buf;
-   size_t min;
-   int i, ret;
-
-   if (vmalloced_buf) {
-   desc_len = min_t(int, max_seg_size, PAGE_SIZE);
-   sgs = DIV_ROUND_UP(len + offset_in_page(buf), desc_len);
-   } else {
-   desc_len = min_t(int, max_seg_size, master->max_dma_len);
-   sgs = DIV_ROUND_UP(len, desc_len);
-   }
+   struct sg_constraints constraints = { };
+   int ret;
 
-   ret = sg_alloc_table(sgt, sgs, GFP_KERNEL);
-   if (ret != 0)
+   constraints.max_segment_size = dma_get_max_seg_size(dev);
+   ret = sg_alloc_table_from_buf(sgt, buf, len, , GFP_KERNEL);
+   if (ret)
return ret;
 
-   for (i = 0; i < sgs; i++) {
-
-   if (vmalloced_buf) {
-   min = min_t(size_t,
-   len, desc_len - offset_in_page(buf));
-   vm_page = vmalloc_to_page(buf);
-   if (!vm_page) {
-   sg_free_table(sgt);
-   return -ENOMEM;
-   }
-   sg_set_page(>sgl[i], vm_page,
-   min, offset_in_page(buf));
-   } else {
-   min = min_t(size_t, len, desc_len);
-   sg_buf = buf;
-   sg_set_buf(>sgl[i], sg_buf, min);
-   }
-
-   buf += min;
-   len -= min;
-   }
-
ret = dma_map_sg(dev, sgt->sgl, sgt->nents, dir);
if (!ret)
ret = -ENOMEM;
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/4] scatterlist: add sg_alloc_table_from_buf() helper

2016-03-31 Thread Boris Brezillon
sg_alloc_table_from_buf() provides an easy solution to create an sg_table
from a virtual address pointer. This function takes care of dealing with
vmallocated buffers, buffer alignment, or DMA engine limitations (maximum
DMA transfer size).

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 include/linux/scatterlist.h |  24 ++
 lib/scatterlist.c   | 183 
 2 files changed, 207 insertions(+)

diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 556ec1e..18d1091 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -41,6 +41,27 @@ struct sg_table {
unsigned int orig_nents;/* original size of list */
 };
 
+/**
+ * struct sg_constraints - SG constraints structure
+ *
+ * @max_segment_size: maximum segment length. Each SG entry has to be smaller
+ *   than this value. Zero means no constraint.
+ * @required_alignment: minimum alignment. Is used for both size and pointer
+ * alignment. If this constraint is not met, the function
+ * should return -EINVAL.
+ * @preferred_alignment: preferred alignment. Mainly used to optimize
+ *  throughput when the DMA engine performs better when
+ *  doing aligned accesses.
+ *
+ * This structure is here to help sg_alloc_table_from_buf() create the optimal
+ * SG list based on DMA engine constraints.
+ */
+struct sg_constraints {
+   size_t max_segment_size;
+   size_t required_alignment;
+   size_t preferred_alignment;
+};
+
 /*
  * Notes on SG table design.
  *
@@ -265,6 +286,9 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
unsigned long offset, unsigned long size,
gfp_t gfp_mask);
+int sg_alloc_table_from_buf(struct sg_table *sgt, const void *buf, size_t len,
+   const struct sg_constraints *constraints,
+   gfp_t gfp_mask);
 
 size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void *buf,
  size_t buflen, off_t skip, bool to_buffer);
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 004fc70..9c9746e 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -433,6 +433,189 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
 }
 EXPORT_SYMBOL(sg_alloc_table_from_pages);
 
+static size_t sg_buf_chunk_len(const void *buf, size_t len,
+  const struct sg_constraints *cons)
+{
+   size_t chunk_len = len;
+
+   if (cons->max_segment_size)
+   chunk_len = min_t(size_t, chunk_len, cons->max_segment_size);
+
+   if (is_vmalloc_addr(buf)) {
+   unsigned long offset_in_page = offset_in_page(buf);
+   size_t contig_len = PAGE_SIZE - offset_in_page;
+   unsigned long phys = vmalloc_to_pfn(buf) - offset_in_page;
+   const void *contig_ptr = buf + contig_len;
+
+   /*
+* Vmalloced buffer might be composed of several physically
+* contiguous pages. Avoid extra scattergather entries in
+* this case.
+*/
+   while (contig_len < chunk_len) {
+   if (phys + PAGE_SIZE != vmalloc_to_pfn(contig_ptr))
+   break;
+
+   contig_len += PAGE_SIZE;
+   contig_ptr += PAGE_SIZE;
+   phys += PAGE_SIZE;
+   }
+
+   chunk_len = min_t(size_t, chunk_len, contig_len);
+   }
+
+   if (!IS_ALIGNED((unsigned long)buf, cons->preferred_alignment)) {
+   const void *aligned_buf = PTR_ALIGN(buf,
+   cons->preferred_alignment);
+   size_t unaligned_len = (unsigned long)(aligned_buf - buf);
+
+   chunk_len = min_t(size_t, chunk_len, unaligned_len);
+   } else if (chunk_len > cons->preferred_alignment) {
+   chunk_len &= ~(cons->preferred_alignment - 1);
+   }
+
+   return chunk_len;
+}
+
+#define sg_for_each_chunk_in_buf(buf, len, chunk_len, constraints) \
+   for (chunk_len = sg_buf_chunk_len(buf, len, constraints);   \
+len;   \
+len -= chunk_len, buf += chunk_len,\
+chunk_len = sg_buf_chunk_len(buf, len, constraints))
+
+static int sg_check_constraints(struct sg_constraints *cons,
+   const void *buf, size_t len)
+{
+   /*
+* We only accept buffers coming from the lowmem, vmalloc and
+* highmem regions.
+*/
+   if (!virt_addr_valid(buf) && !is_vmalloc_addr(buf) &&
+   !is_highmem_addr(buf))
+   return -EINVAL;
+
+   i

[PATCH 0/4] scatterlist: sg_table from virtual pointer

2016-03-31 Thread Boris Brezillon
Hello,

This series has been extracted from another series [1] adding support
for DMA operations in a NAND driver.

The reason I decided to post those patches separately is because they
are touching core stuff, and I'd like to have feedback on these specific
aspects.

The idea is to provide a generic function creating an sg_table from
a virtual pointer and a length. This operation is complicated by
the different memory regions exposed in kernel space. For example,
you have the lowmem region, which guarantees that buffers are
physically contiguous, while the vmalloc region does not.

sg_alloc_table_from_buf() detects in which memory region your buffer
reside, and takes the appropriate precautions when creating the
sg_table. This function also takes an extract parameter, allowing
one to specify extra constraints, like the maximum DMA segment size,
the required and the preferred alignment.

Patch 1 and 2 are implementing sg_alloc_table_from_buf() (patch 1
is needed to properly detect buffers residing in the highmem/kmap
area).

Patch 3 is making use of sg_alloc_table_from_buf() in the spi_map_buf()
function (hopefully, other subsystems/drivers will be able to easily
switch to this function too).

Patch 4 is implementing what I really need: generic functions
to map/unmap a virtual buffer passed through mtd->_read/_write().

I'm not exactly a DMA or MM experts, so that would be great to have
feedbacks on this approach. That's why I added so many people in Cc
even if they're not directly impacted by those patches. Let me know if
you want me to drop/add people from/to the recipient list.

Thanks.

Best Regards,

Boris

[1]http://www.spinics.net/lists/arm-kernel/msg493552.html

Boris Brezillon (4):
  mm: add is_highmem_addr() helper
  scatterlist: add sg_alloc_table_from_buf() helper
  spi: use sg_alloc_table_from_buf()
  mtd: provide helper to prepare buffers for DMA operations

 drivers/mtd/mtdcore.c   |  66 
 drivers/spi/spi.c   |  45 ++-
 include/linux/highmem.h |  13 
 include/linux/mtd/mtd.h |  25 ++
 include/linux/scatterlist.h |  24 ++
 lib/scatterlist.c   | 183 
 6 files changed, 316 insertions(+), 40 deletions(-)

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/4] mm: add is_highmem_addr() helper

2016-03-31 Thread Boris Brezillon
Add an helper to check if a virtual address is in the highmem region.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 include/linux/highmem.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index bb3f329..13dff37 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -41,6 +41,14 @@ void kmap_flush_unused(void);
 
 struct page *kmap_to_page(void *addr);
 
+static inline bool is_highmem_addr(const void *x)
+{
+   unsigned long vaddr = (unsigned long)x;
+
+   return vaddr >=  PKMAP_BASE &&
+  vaddr < ((PKMAP_BASE + LAST_PKMAP) * PAGE_SIZE);
+}
+
 #else /* CONFIG_HIGHMEM */
 
 static inline unsigned int nr_free_highpages(void) { return 0; }
@@ -50,6 +58,11 @@ static inline struct page *kmap_to_page(void *addr)
return virt_to_page(addr);
 }
 
+static inline bool is_highmem_addr(const void *x)
+{
+   return false;
+}
+
 #define totalhigh_pages 0UL
 
 #ifndef ARCH_HAS_KMAP
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [v2,4/7] scatterlist: add sg_alloc_table_from_buf() helper

2016-03-31 Thread Boris Brezillon
Hi Vignesh,

On Thu, 31 Mar 2016 10:26:59 +0530
Vignesh R <vigne...@ti.com> wrote:

> Hi,
> 
> On 03/30/2016 09:09 PM, Boris BREZILLON wrote:
> 
> [...]
> 
> > +int sg_alloc_table_from_buf(struct sg_table *sgt, const void *buf, size_t 
> > len,
> > +   const struct sg_constraints *constraints,
> > +   gfp_t gfp_mask)
> > +{
> > +   struct sg_constraints cons = { };
> > +   size_t remaining, chunk_len;
> > +   const void *sg_buf;
> > +   int i, ret;
> > +
> > +   if (constraints)
> > +   cons = *constraints;
> > +
> > +   ret = sg_check_constraints(, buf, len);
> > +   if (ret)
> > +   return ret;
> > +
> > +   sg_buf = buf;
> > +   remaining = len;
> > +   i = 0;
> > +   sg_for_each_chunk_in_buf(sg_buf, remaining, chunk_len, )
> > +   i++;
> > +
> > +   ret = sg_alloc_table(sgt, i, gfp_mask);
> > +   if (ret)
> > +   return ret;
> > +
> > +   sg_buf = buf;
> > +   remaining = len;
> > +   i = 0;
> > +   sg_for_each_chunk_in_buf(sg_buf, remaining, chunk_len, ) {
> > +   if (is_vmalloc_addr(sg_buf)) {
> > +   struct page *vm_page;
> > +
> > +   vm_page = vmalloc_to_page(sg_buf);
> > +   if (!vm_page) {
> > +   ret = -ENOMEM;
> > +   goto err_free_table;
> > +   }
> > +
> > +   sg_set_page(>sgl[i], vm_page, chunk_len,
> > +   offset_in_page(sg_buf));
> > +   } else {
> > +   sg_set_buf(>sgl[i], sg_buf, chunk_len);
> > +   }
> > +
> 
> If the buf address is in PKMAP_BASE - PAGE_OFFSET-1 region (I have
> observed that JFFS2 FS provides buffers in above region to MTD layer),
> if CONFIG_DEBUG_SG is set then sg_set_buf() will throw a BUG_ON() as
> virt_addr_is_valid() will return false. Is there a sane way to handle
> buffers of PKMAP_BASE region with sg_*  APIs?
> Or, is the function sg_alloc_table_from_buf() not to be used with such
> buffers?

It should be usable with kmapped buffers too: I'll provide a new version
to support that.
That makes me realize I'm not checking the virtual address consistency
in sg_check_constraints().

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 4/7] scatterlist: add sg_alloc_table_from_buf() helper

2016-03-30 Thread Boris Brezillon
On Wed, 30 Mar 2016 09:51:43 -0700
Mark Brown <broo...@kernel.org> wrote:

> On Wed, Mar 30, 2016 at 05:39:51PM +0200, Boris Brezillon wrote:
> > sg_alloc_table_from_buf() provides an easy solution to create an sg_table
> > from a virtual address pointer. This function takes care of dealing with
> > vmallocated buffers, buffer alignment, or DMA engine limitations (maximum
> > DMA transfer size).
> 
> This seems nice.  Should we also have a further helper on top of this
> which will get constraints from a dmaengine, it seems like it'd be a
> common need?

Yep, we could create a wrapper extracting dma_slave caps info,
converting it to sg_constraints and calling sg_alloc_table_from_buf().
But let's try to get this function accepted first, and I'll send another
patch providing this wrapper.

BTW, do you see other things that should be added in sg_constraints?

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 7/7] mtd: nand: sunxi: update DT bindings

2016-03-30 Thread Boris Brezillon
Document dmas and dma-names properties.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Acked-by: Rob Herring <r...@kernel.org>
---
 Documentation/devicetree/bindings/mtd/sunxi-nand.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt 
b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
index 086d6f4..6fdf8f6 100644
--- a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
@@ -11,6 +11,10 @@ Required properties:
 * "ahb" : AHB gating clock
 * "mod" : nand controller clock
 
+Optional properties:
+- dmas : shall reference DMA channel associated to the NAND controller.
+- dma-names : shall be "rxtx".
+
 Optional children nodes:
 Children nodes represent the available nand chips.
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 0/7] mtd: nand: sunxi: add support for DMA operations

2016-03-30 Thread Boris Brezillon
Hello,

This patch series aims at adding support for DMA assisted operations to
the sunxi_nand driver.

The first 3 patches are just reworks in the existing driver preparing
things for DMA ->read/write_page() operations. Those ones are mainly
re-arranging existing functions, and moving some code into dedicated
functions so we can reuse them when adding the read/write_page()
implementation.

Patch 4 is an attempt to generalize some logic that are duplicated in a
lot of places. It provides a generic solution to create an SG table
from a buffer (passed by virtual address) and its length.
This generic implementation tries to take all possible constraints into
account, like:
- vmallocated buffers
- alignement requirement/preference
- maximum DMA transfer length

I may have missed other things (is there a need for a minimum DMA
transfer constraint?), so don't hesitate to point problems or missing
elements in this implementation.
Note that other subsystems doing the same kind of thing (like SPI of V4L)
could use this implementation. This is why I've put the SPI and V4L
maintainers in Cc.

Patch 5 is providing functions to map/unmap buffers for DMA operations
at the MTD level. This will hopefully limit the number of open-coded
implementations we're currently seeing in a lot of NAND drivers.
Of course, it's making use of sg_alloc_table_from_buf(), introduced in
patch 4.

Patch 6 and 7 are patching the sunxi NAND driver and its DT binding doc
to add DMA support.

I'm particularly interested in getting feedbacks on patch 4 and 5.
Is there a reason nobody ever tried to create such generic functions
(at the scatterlist and MTD levels), and if there are, could you detail
them?

Thanks,

Boris

Side note: patches touching the sunxi NAND driver are depending on
this series [1].

[1]https://lkml.org/lkml/2016/3/7/444

Changes since v1:
- reworked sg_alloc_table_from_buf() to avoid splitting contiguous
  vmalloced area
- fixed a bug in the read_dma()
- fixed dma_direction flag in write_dma()

Boris Brezillon (7):
  mtd: nand: sunxi: move some ECC related operations to their own
functions
  mtd: nand: sunxi: make OOB retrieval optional
  mtd: nand: sunxi: make cur_off parameter optional in extra oob helpers
  scatterlist: add sg_alloc_table_from_buf() helper
  mtd: provide helper to prepare buffers for DMA operations
  mtd: nand: sunxi: add support for DMA assisted operations
  mtd: nand: sunxi: update DT bindings

 .../devicetree/bindings/mtd/sunxi-nand.txt |   4 +
 drivers/mtd/mtdcore.c  |  66 +++
 drivers/mtd/nand/sunxi_nand.c  | 505 ++---
 include/linux/mtd/mtd.h|  25 +
 include/linux/scatterlist.h|  24 +
 lib/scatterlist.c  | 161 +++
 6 files changed, 720 insertions(+), 65 deletions(-)

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 4/7] scatterlist: add sg_alloc_table_from_buf() helper

2016-03-30 Thread Boris Brezillon
sg_alloc_table_from_buf() provides an easy solution to create an sg_table
from a virtual address pointer. This function takes care of dealing with
vmallocated buffers, buffer alignment, or DMA engine limitations (maximum
DMA transfer size).

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 include/linux/scatterlist.h |  24 +++
 lib/scatterlist.c   | 161 
 2 files changed, 185 insertions(+)

diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 556ec1e..4a75362 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -41,6 +41,27 @@ struct sg_table {
unsigned int orig_nents;/* original size of list */
 };
 
+/**
+ * struct sg_constraints - SG constraints structure
+ *
+ * @max_chunk_len: maximum chunk buffer length. Each SG entry has to be smaller
+ *than this value. Zero means no constraint.
+ * @required_alignment: minimum alignment. Is used for both size and pointer
+ * alignment. If this constraint is not met, the function
+ * should return -EINVAL.
+ * @preferred_alignment: preferred alignment. Mainly used to optimize
+ *  throughput when the DMA engine performs better when
+ *  doing aligned accesses.
+ *
+ * This structure is here to help sg_alloc_table_from_buf() create the optimal
+ * SG list based on DMA engine constraints.
+ */
+struct sg_constraints {
+   size_t max_chunk_len;
+   size_t required_alignment;
+   size_t preferred_alignment;
+};
+
 /*
  * Notes on SG table design.
  *
@@ -265,6 +286,9 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
unsigned long offset, unsigned long size,
gfp_t gfp_mask);
+int sg_alloc_table_from_buf(struct sg_table *sgt, const void *buf, size_t len,
+   const struct sg_constraints *constraints,
+   gfp_t gfp_mask);
 
 size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void *buf,
  size_t buflen, off_t skip, bool to_buffer);
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 004fc70..94776ff 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -433,6 +433,167 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
 }
 EXPORT_SYMBOL(sg_alloc_table_from_pages);
 
+static size_t sg_buf_chunk_len(const void *buf, size_t len,
+  const struct sg_constraints *cons)
+{
+   size_t chunk_len = len;
+
+   if (cons->max_chunk_len)
+   chunk_len = min_t(size_t, chunk_len, cons->max_chunk_len);
+
+   if (is_vmalloc_addr(buf)) {
+   unsigned long offset_in_page = offset_in_page(buf);
+   size_t contig_len = PAGE_SIZE - offset_in_page;
+   unsigned long phys = vmalloc_to_pfn(buf) - offset_in_page;
+   const void *contig_ptr = buf + contig_len;
+
+   /*
+* Vmalloced buffer might be composed of several physically
+* contiguous pages. Avoid extra scattergather entries in
+* this case.
+*/
+   while (contig_len < chunk_len) {
+   if (phys + PAGE_SIZE != vmalloc_to_pfn(contig_ptr))
+   break;
+
+   contig_len += PAGE_SIZE;
+   contig_ptr += PAGE_SIZE;
+   phys += PAGE_SIZE;
+   }
+
+   chunk_len = min_t(size_t, chunk_len, contig_len);
+   }
+
+   if (!IS_ALIGNED((unsigned long)buf, cons->preferred_alignment)) {
+   const void *aligned_buf = PTR_ALIGN(buf,
+   cons->preferred_alignment);
+   size_t unaligned_len = (unsigned long)(aligned_buf - buf);
+
+   chunk_len = min_t(size_t, chunk_len, unaligned_len);
+   } else if (chunk_len > cons->preferred_alignment) {
+   chunk_len &= ~(cons->preferred_alignment - 1);
+   }
+
+   return chunk_len;
+}
+
+#define sg_for_each_chunk_in_buf(buf, len, chunk_len, constraints) \
+   for (chunk_len = sg_buf_chunk_len(buf, len, constraints);   \
+len;   \
+len -= chunk_len, buf += chunk_len,\
+chunk_len = sg_buf_chunk_len(buf, len, constraints))
+
+static int sg_check_constraints(struct sg_constraints *cons,
+   const void *buf, size_t len)
+{
+   if (!cons->required_alignment)
+   cons->required_alignment = 1;
+
+   if (!cons->preferred_alignment)
+   cons->preferred_alignment = cons->required_alignment;
+
+   /* Test if buf and len are properly aligned. */
+   if (!IS_ALI

[PATCH v2 5/7] mtd: provide helper to prepare buffers for DMA operations

2016-03-30 Thread Boris Brezillon
Some NAND controller drivers are making use of DMA to transfer data from
the controller to the buffer passed by the MTD user.
Provide a generic mtd_map/unmap_buf() implementation to avoid open coded
(and sometime erroneous) implementations.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/mtdcore.c   | 66 +
 include/linux/mtd/mtd.h | 25 +++
 2 files changed, 91 insertions(+)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 3096251..3c368f0 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1253,6 +1253,72 @@ void *mtd_kmalloc_up_to(const struct mtd_info *mtd, 
size_t *size)
 }
 EXPORT_SYMBOL_GPL(mtd_kmalloc_up_to);
 
+#ifdef CONFIG_HAS_DMA
+/**
+ * mtd_map_buf - create an SG table and prepare it for DMA operations
+ *
+ * @mtd: mtd device description object pointer
+ * @dev: device handling the DMA operation
+ * @buf: buf used to create the SG table
+ * @len: length of buf
+ * @constraints: optional constraints to take into account when creating
+ *  the SG table. Can be NULL if no specific constraints
+ *  are required.
+ * @dir: direction of the DMA operation
+ *
+ * This function should be used when an MTD driver wants to do DMA operations
+ * on a buffer passed by the MTD layer. This functions takes care of
+ * vmallocated buffer constraints, and return and sg_table that you can safely
+ * use.
+ */
+int mtd_map_buf(struct mtd_info *mtd, struct device *dev,
+   struct sg_table *sgt, const void *buf, size_t len,
+   const struct sg_constraints *constraints,
+   enum dma_data_direction dir)
+{
+   int ret;
+
+   ret = sg_alloc_table_from_buf(sgt, buf, len, constraints, GFP_KERNEL);
+   if (ret)
+   return ret;
+
+   ret = dma_map_sg(dev, sgt->sgl, sgt->nents, dir);
+   if (!ret)
+   ret = -ENOMEM;
+
+   if (ret < 0) {
+   sg_free_table(sgt);
+   return ret;
+   }
+
+   sgt->nents = ret;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(mtd_map_buf);
+
+/**
+ * mtd_map_buf - unmap an SG table and release its resources
+ *
+ * @mtd: mtd device description object pointer
+ * @dev: device handling the DMA operation
+ * @sgt: SG table
+ * @dir: direction of the DMA operation
+ *
+ * This function unmaps a previously mapped SG table and release SG table
+ * resources. Should be called when your DMA operation is done.
+ */
+void mtd_unmap_buf(struct mtd_info *mtd, struct device *dev,
+  struct sg_table *sgt, enum dma_data_direction dir)
+{
+   if (sgt->orig_nents) {
+   dma_unmap_sg(dev, sgt->sgl, sgt->orig_nents, dir);
+   sg_free_table(sgt);
+   }
+}
+EXPORT_SYMBOL_GPL(mtd_unmap_buf);
+#endif /* !CONFIG_HAS_DMA */
+
 #ifdef CONFIG_PROC_FS
 
 /**/
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 7712721..15cff85 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -410,6 +411,30 @@ extern void register_mtd_user (struct mtd_notifier *new);
 extern int unregister_mtd_user (struct mtd_notifier *old);
 void *mtd_kmalloc_up_to(const struct mtd_info *mtd, size_t *size);
 
+#ifdef CONFIG_HAS_DMA
+int mtd_map_buf(struct mtd_info *mtd, struct device *dev,
+   struct sg_table *sgt, const void *buf, size_t len,
+   const struct sg_constraints *constraints,
+   enum dma_data_direction dir);
+void mtd_unmap_buf(struct mtd_info *mtd, struct device *dev,
+  struct sg_table *sgt, enum dma_data_direction dir);
+#else
+static inline int mtd_map_buf(struct mtd_info *mtd, struct device *dev,
+ struct sg_table *sgt, const void *buf,
+ size_t len,
+ const struct sg_constraints *constraints
+ enum dma_data_direction dir)
+{
+   return -ENOTSUPP;
+}
+
+static void mtd_unmap_buf(struct mtd_info *mtd, struct device *dev,
+ struct sg_table *sgt, enum dma_data_direction dir)
+{
+   return -ENOTSUPP;
+}
+#endif
+
 void mtd_erase_callback(struct erase_info *instr);
 
 static inline int mtd_is_bitflip(int err) {
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 6/7] mtd: nand: sunxi: add support for DMA assisted operations

2016-03-30 Thread Boris Brezillon
The sunxi NAND controller is able to pipeline ECC operations only when
operated in DMA mode, which improves a lot NAND throughput while keeping
CPU usage low.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand.c | 324 +-
 1 file changed, 320 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 6d6b166..1029f28 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -154,6 +154,7 @@
 
 /* define bit use in NFC_ECC_ST */
 #define NFC_ECC_ERR(x) BIT(x)
+#define NFC_ECC_ERR_MSKGENMASK(15, 0)
 #define NFC_ECC_PAT_FOUND(x)   BIT(x + 16)
 #define NFC_ECC_ERR_CNT(b, x)  (((x) >> (((b) % 4) * 8)) & 0xff)
 
@@ -277,6 +278,7 @@ struct sunxi_nfc {
unsigned long clk_rate;
struct list_head chips;
struct completion complete;
+   struct dma_chan *dmac;
 };
 
 static inline struct sunxi_nfc *to_sunxi_nfc(struct nand_hw_control *ctrl)
@@ -369,6 +371,68 @@ static int sunxi_nfc_rst(struct sunxi_nfc *nfc)
return ret;
 }
 
+static int sunxi_nfc_dma_op_prepare(struct mtd_info *mtd, const void *buf,
+   int chunksize, int nchunks,
+   enum dma_data_direction ddir,
+   struct sg_table *sgt)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   struct dma_async_tx_descriptor *dmad;
+   enum dma_transfer_direction tdir;
+   dma_cookie_t dmat;
+   int ret;
+
+   if (ddir == DMA_FROM_DEVICE)
+   tdir = DMA_DEV_TO_MEM;
+   else
+   tdir = DMA_MEM_TO_DEV;
+
+   ret = mtd_map_buf(mtd, nfc->dev, sgt, buf, nchunks * chunksize,
+ NULL, ddir);
+   if (ret)
+   return ret;
+
+   dmad = dmaengine_prep_slave_sg(nfc->dmac, sgt->sgl, sgt->nents,
+  tdir, DMA_CTRL_ACK);
+   if (IS_ERR(dmad)) {
+   ret = PTR_ERR(dmad);
+   goto err_unmap_buf;
+   }
+
+   writel(readl(nfc->regs + NFC_REG_CTL) | NFC_RAM_METHOD,
+  nfc->regs + NFC_REG_CTL);
+   writel(nchunks, nfc->regs + NFC_REG_SECTOR_NUM);
+   writel(chunksize, nfc->regs + NFC_REG_CNT);
+   dmat = dmaengine_submit(dmad);
+
+   ret = dma_submit_error(dmat);
+   if (ret)
+   goto err_clr_dma_flag;
+
+   return 0;
+
+err_clr_dma_flag:
+   writel(readl(nfc->regs + NFC_REG_CTL) & ~NFC_RAM_METHOD,
+  nfc->regs + NFC_REG_CTL);
+
+err_unmap_buf:
+   mtd_unmap_buf(mtd, nfc->dev, sgt, ddir);
+   return ret;
+}
+
+static void sunxi_nfc_dma_op_cleanup(struct mtd_info *mtd,
+enum dma_data_direction ddir,
+struct sg_table *sgt)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+
+   mtd_unmap_buf(mtd, nfc->dev, sgt, ddir);
+   writel(readl(nfc->regs + NFC_REG_CTL) & ~NFC_RAM_METHOD,
+  nfc->regs + NFC_REG_CTL);
+}
+
 static int sunxi_nfc_dev_ready(struct mtd_info *mtd)
 {
struct nand_chip *nand = mtd_to_nand(mtd);
@@ -970,6 +1034,128 @@ static void sunxi_nfc_hw_ecc_read_extra_oob(struct 
mtd_info *mtd,
*cur_off = mtd->oobsize + mtd->writesize;
 }
 
+static int sunxi_nfc_hw_ecc_read_chunks_dma(struct mtd_info *mtd, uint8_t *buf,
+   int oob_required, int page,
+   int nchunks)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   bool randomized = nand->options & NAND_NEED_SCRAMBLING;
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   struct nand_ecc_ctrl *ecc = >ecc;
+   unsigned int max_bitflips = 0;
+   int ret, i, raw_mode = 0;
+   struct sg_table sgt;
+   u32 status;
+
+   ret = sunxi_nfc_wait_cmd_fifo_empty(nfc);
+   if (ret)
+   return ret;
+
+   ret = sunxi_nfc_dma_op_prepare(mtd, buf, ecc->size, nchunks,
+  DMA_FROM_DEVICE, );
+   if (ret)
+   return ret;
+
+   sunxi_nfc_hw_ecc_enable(mtd);
+   sunxi_nfc_randomizer_config(mtd, page, false);
+   sunxi_nfc_randomizer_enable(mtd);
+
+   writel((NAND_CMD_RNDOUTSTART << 16) | (NAND_CMD_RNDOUT << 8) |
+  NAND_CMD_READSTART, nfc->regs + NFC_REG_RCMD_SET);
+
+   dma_async_issue_pending(nfc->dmac);
+
+   writel(NFC_PAGE_OP | NFC_DATA_SWAP_METHOD | NFC_DATA_TRANS,
+  nfc->regs + NFC_REG_CMD);
+
+   ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, true, 0);
+   if (ret)
+   dm

[PATCH v2 3/7] mtd: nand: sunxi: make cur_off parameter optional in extra oob helpers

2016-03-30 Thread Boris Brezillon
Allow for NULL cur_offs values when the caller does not know where the
NAND page register pointer point to.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 3e7b919..6d6b166 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -956,7 +956,7 @@ static void sunxi_nfc_hw_ecc_read_extra_oob(struct mtd_info 
*mtd,
if (len <= 0)
return;
 
-   if (*cur_off != offset)
+   if (!cur_off || *cur_off != offset)
nand->cmdfunc(mtd, NAND_CMD_RNDOUT,
  offset + mtd->writesize, -1);
 
@@ -966,7 +966,8 @@ static void sunxi_nfc_hw_ecc_read_extra_oob(struct mtd_info 
*mtd,
sunxi_nfc_randomizer_read_buf(mtd, oob + offset, len,
  false, page);
 
-   *cur_off = mtd->oobsize + mtd->writesize;
+   if (cur_off)
+   *cur_off = mtd->oobsize + mtd->writesize;
 }
 
 static int sunxi_nfc_hw_ecc_write_chunk(struct mtd_info *mtd,
@@ -1021,13 +1022,14 @@ static void sunxi_nfc_hw_ecc_write_extra_oob(struct 
mtd_info *mtd,
if (len <= 0)
return;
 
-   if (*cur_off != offset)
+   if (!cur_off || *cur_off != offset)
nand->cmdfunc(mtd, NAND_CMD_RNDIN,
  offset + mtd->writesize, -1);
 
sunxi_nfc_randomizer_write_buf(mtd, oob + offset, len, false, page);
 
-   *cur_off = mtd->oobsize + mtd->writesize;
+   if (cur_off)
+   *cur_off = mtd->oobsize + mtd->writesize;
 }
 
 static int sunxi_nfc_hw_ecc_read_page(struct mtd_info *mtd,
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 2/7] mtd: nand: sunxi: make OOB retrieval optional

2016-03-30 Thread Boris Brezillon
sunxi_nfc_hw_ecc_read_chunk() always retrieves the ECC and protected free
bytes, no matter if the user really asked for it or not. This can take a
non negligible amount of time, especially on NAND chips exposing large OOB
areas (> 1KB). Make it optional.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index f6ea0fb..3e7b919 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -867,7 +867,7 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
   u8 *oob, int oob_off,
   int *cur_off,
   unsigned int *max_bitflips,
-  bool bbm, int page)
+  bool bbm, bool oob_required, int page)
 {
struct nand_chip *nand = mtd_to_nand(mtd);
struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
@@ -899,7 +899,7 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
 
*cur_off = oob_off + ecc->bytes + 4;
 
-   ret = sunxi_nfc_hw_ecc_correct(mtd, data, oob, 0,
+   ret = sunxi_nfc_hw_ecc_correct(mtd, data, oob_required ? oob : NULL, 0,
   readl(nfc->regs + NFC_REG_ECC_ST),
   );
if (erased)
@@ -929,12 +929,14 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info 
*mtd,
} else {
memcpy_fromio(data, nfc->regs + NFC_RAM0_BASE, ecc->size);
 
-   nand->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_off, -1);
-   sunxi_nfc_randomizer_read_buf(mtd, oob, ecc->bytes + 4,
- true, page);
+   if (oob_required) {
+   nand->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_off, -1);
+   sunxi_nfc_randomizer_read_buf(mtd, oob, ecc->bytes + 4,
+ true, page);
 
-   sunxi_nfc_hw_ecc_get_prot_oob_bytes(mtd, oob, 0,
-   bbm, page);
+   sunxi_nfc_hw_ecc_get_prot_oob_bytes(mtd, oob, 0,
+   bbm, page);
+   }
}
 
sunxi_nfc_hw_ecc_update_stats(mtd, max_bitflips, ret);
@@ -1048,7 +1050,7 @@ static int sunxi_nfc_hw_ecc_read_page(struct mtd_info 
*mtd,
ret = sunxi_nfc_hw_ecc_read_chunk(mtd, data, data_off, oob,
  oob_off + mtd->writesize,
  _off, _bitflips,
- !i, page);
+ !i, oob_required, page);
if (ret < 0)
return ret;
else if (ret)
@@ -1086,8 +1088,8 @@ static int sunxi_nfc_hw_ecc_read_subpage(struct mtd_info 
*mtd,
ret = sunxi_nfc_hw_ecc_read_chunk(mtd, data, data_off,
  oob,
  oob_off + mtd->writesize,
- _off, _bitflips,
- !i, page);
+ _off, _bitflips, !i,
+ false, page);
if (ret < 0)
return ret;
}
@@ -1149,7 +1151,9 @@ static int sunxi_nfc_hw_syndrome_ecc_read_page(struct 
mtd_info *mtd,
 
ret = sunxi_nfc_hw_ecc_read_chunk(mtd, data, data_off, oob,
  oob_off, _off,
- _bitflips, !i, page);
+ _bitflips, !i,
+ oob_required,
+ page);
if (ret < 0)
return ret;
else if (ret)
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 1/7] mtd: nand: sunxi: move some ECC related operations to their own functions

2016-03-30 Thread Boris Brezillon
In order to support DMA operations in a clean way we need to extract some
of the logic coded in sunxi_nfc_hw_ecc_read/write_page() into their own
function.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand.c | 163 --
 1 file changed, 108 insertions(+), 55 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index a71905c..f6ea0fb 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -776,6 +776,92 @@ static inline void sunxi_nfc_user_data_to_buf(u32 
user_data, u8 *buf)
buf[3] = user_data >> 24;
 }
 
+static inline u32 sunxi_nfc_buf_to_user_data(const u8 *buf)
+{
+   return buf[0] | (buf[1] << 8) | (buf[2] << 16) | (buf[3] << 24);
+}
+
+static void sunxi_nfc_hw_ecc_get_prot_oob_bytes(struct mtd_info *mtd, u8 *oob,
+   int step, bool bbm, int page)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+
+   sunxi_nfc_user_data_to_buf(readl(nfc->regs + NFC_REG_USER_DATA(step)),
+  oob);
+
+   /* De-randomize the Bad Block Marker. */
+   if (bbm && (nand->options & NAND_NEED_SCRAMBLING))
+   sunxi_nfc_randomize_bbm(mtd, page, oob);
+}
+
+static void sunxi_nfc_hw_ecc_set_prot_oob_bytes(struct mtd_info *mtd,
+   const u8 *oob, int step,
+   bool bbm, int page)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   u8 user_data[4];
+
+   /* Randomize the Bad Block Marker. */
+   if (bbm && (nand->options & NAND_NEED_SCRAMBLING)) {
+   memcpy(user_data, oob, sizeof(user_data));
+   sunxi_nfc_randomize_bbm(mtd, page, user_data);
+   oob = user_data;
+   }
+
+   writel(sunxi_nfc_buf_to_user_data(oob),
+  nfc->regs + NFC_REG_USER_DATA(step));
+}
+
+static void sunxi_nfc_hw_ecc_update_stats(struct mtd_info *mtd,
+ unsigned int *max_bitflips, int ret)
+{
+   if (ret < 0) {
+   mtd->ecc_stats.failed++;
+   } else {
+   mtd->ecc_stats.corrected += ret;
+   *max_bitflips = max_t(unsigned int, *max_bitflips, ret);
+   }
+}
+
+static int sunxi_nfc_hw_ecc_correct(struct mtd_info *mtd, u8 *data, u8 *oob,
+   int step, u32 status, bool *erased)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   struct nand_ecc_ctrl *ecc = >ecc;
+   u32 tmp;
+
+   *erased = false;
+
+   if (status & NFC_ECC_ERR(step))
+   return -EBADMSG;
+
+   if (status & NFC_ECC_PAT_FOUND(step)) {
+   u8 pattern;
+
+   if (unlikely(!(readl(nfc->regs + NFC_REG_PAT_ID) & 0x1))) {
+   pattern = 0x0;
+   } else {
+   pattern = 0xff;
+   *erased = true;
+   }
+
+   if (data)
+   memset(data, pattern, ecc->size);
+
+   if (oob)
+   memset(oob, pattern, ecc->bytes + 4);
+
+   return 0;
+   }
+
+   tmp = readl(nfc->regs + NFC_REG_ECC_ERR_CNT(step));
+
+   return NFC_ECC_ERR_CNT(step, tmp);
+}
+
 static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
   u8 *data, int data_off,
   u8 *oob, int oob_off,
@@ -787,7 +873,7 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
struct nand_ecc_ctrl *ecc = >ecc;
int raw_mode = 0;
-   u32 status;
+   bool erased;
int ret;
 
if (*cur_off != data_off)
@@ -813,27 +899,13 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info 
*mtd,
 
*cur_off = oob_off + ecc->bytes + 4;
 
-   status = readl(nfc->regs + NFC_REG_ECC_ST);
-   if (status & NFC_ECC_PAT_FOUND(0)) {
-   u8 pattern = 0xff;
-
-   if (unlikely(!(readl(nfc->regs + NFC_REG_PAT_ID) & 0x1)))
-   pattern = 0x0;
-
-   memset(data, pattern, ecc->size);
-   memset(oob, pattern, ecc->bytes + 4);
-
+   ret = sunxi_nfc_hw_ecc_correct(mtd, data, oob, 0,
+  readl(nfc->regs + NFC_REG_ECC_ST),
+  );
+   if (erased)
return 1;
-   }
-
-   ret = NFC_ECC_ERR_CNT(0, readl(nfc->regs + NFC_RE

Re: [PATCH 4/7] scatterlist: add sg_alloc_table_from_buf() helper

2016-03-21 Thread Boris Brezillon
On Tue,  8 Mar 2016 12:15:12 +0100
Boris Brezillon <boris.brezil...@free-electrons.com> wrote:

> sg_alloc_table_from_buf() provides an easy solution to create an sg_table
> from a virtual address pointer. This function takes care of dealing with
> vmallocated buffers, buffer alignment, or DMA engine limitations (maximum
> DMA transfer size).
> 
> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> ---
>  include/linux/scatterlist.h |  24 
>  lib/scatterlist.c   | 142 
> 
>  2 files changed, 166 insertions(+)
> 
> diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
> index 556ec1e..4a75362 100644
> --- a/include/linux/scatterlist.h
> +++ b/include/linux/scatterlist.h
> @@ -41,6 +41,27 @@ struct sg_table {
>   unsigned int orig_nents;/* original size of list */
>  };
>  
> +/**
> + * struct sg_constraints - SG constraints structure
> + *
> + * @max_chunk_len: maximum chunk buffer length. Each SG entry has to be 
> smaller
> + *  than this value. Zero means no constraint.
> + * @required_alignment: minimum alignment. Is used for both size and pointer
> + *   alignment. If this constraint is not met, the function
> + *   should return -EINVAL.
> + * @preferred_alignment: preferred alignment. Mainly used to optimize
> + *throughput when the DMA engine performs better when
> + *doing aligned accesses.
> + *
> + * This structure is here to help sg_alloc_table_from_buf() create the 
> optimal
> + * SG list based on DMA engine constraints.
> + */
> +struct sg_constraints {
> + size_t max_chunk_len;
> + size_t required_alignment;
> + size_t preferred_alignment;
> +};
> +

Hm, we seem to have another case in NAND controller drivers. Some
drivers do not support scattergather accesses and have to provide a
single physically contiguous memory region to transfer the whole
NAND page.

Could we add a ->max_entries field to the sg_contraints struct to allow
those drivers to use the generic mtd_map_buf() function, and fallback
to a bounce buffer approach (or PIO access approach) when
sg_alloc_table_from_buf() fails to fulfill this constraint.

We could also define another 'non-sg' function to do the 'physically
contiguous' check, but in any case, I'd like to avoid letting each
driver code its own checking function.

What do you think?

>  /*
>   * Notes on SG table design.
>   *
> @@ -265,6 +286,9 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
>   struct page **pages, unsigned int n_pages,
>   unsigned long offset, unsigned long size,
>   gfp_t gfp_mask);
> +int sg_alloc_table_from_buf(struct sg_table *sgt, const void *buf, size_t 
> len,
> + const struct sg_constraints *constraints,
> + gfp_t gfp_mask);
>  
>  size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void *buf,
> size_t buflen, off_t skip, bool to_buffer);
> diff --git a/lib/scatterlist.c b/lib/scatterlist.c
> index bafa993..706b583 100644
> --- a/lib/scatterlist.c
> +++ b/lib/scatterlist.c
> @@ -433,6 +433,148 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
>  }
>  EXPORT_SYMBOL(sg_alloc_table_from_pages);
>  
> +static size_t sg_buf_chunk_len(const void *buf, size_t len,
> +const struct sg_constraints *cons)
> +{
> + size_t chunk_len = len;
> +
> + if (cons->max_chunk_len)
> + chunk_len = min_t(size_t, chunk_len, cons->max_chunk_len);
> +
> + if (is_vmalloc_addr(buf))
> + chunk_len = min_t(size_t, chunk_len,
> +   PAGE_SIZE - offset_in_page(buf));
> +
> + if (!IS_ALIGNED((unsigned long)buf, cons->preferred_alignment)) {
> + const void *aligned_buf = PTR_ALIGN(buf,
> + cons->preferred_alignment);
> + size_t unaligned_len = (unsigned long)(aligned_buf - buf);
> +
> + chunk_len = min_t(size_t, chunk_len, unaligned_len);
> + } else if (chunk_len > cons->preferred_alignment) {
> + chunk_len &= ~(cons->preferred_alignment - 1);
> + }
> +
> + return chunk_len;
> +}
> +
> +#define sg_for_each_chunk_in_buf(buf, len, chunk_len, constraints)   \
> + for (chunk_len = sg_buf_chunk_len(buf, len, constraints);   \
> +  len;   \
> +  len -= chunk_len, buf += chunk_len,\
> +  chunk_len = sg_buf_chunk_len(buf, len, constraints))
> +

Re: [PATCH 6/7] mtd: nand: sunxi: add support for DMA assisted operations

2016-03-19 Thread Boris Brezillon
On Tue,  8 Mar 2016 12:15:14 +0100
Boris Brezillon <boris.brezil...@free-electrons.com> wrote:

> The sunxi NAND controller is able to pipeline ECC operations only when
> operated in DMA mode, which improves a lot NAND throughput while keeping
> CPU usage low.
> 
> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> ---
>  drivers/mtd/nand/sunxi_nand.c | 301 
> +-
>  1 file changed, 297 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> index 07c3af7..7ba285e 100644
> --- a/drivers/mtd/nand/sunxi_nand.c
> +++ b/drivers/mtd/nand/sunxi_nand.c

[...]

> +static int sunxi_nfc_hw_ecc_write_page_dma(struct mtd_info *mtd,
> +struct nand_chip *chip,
> +const u8 *buf,
> +int oob_required,
> +int page)
> +{
> + struct nand_chip *nand = mtd_to_nand(mtd);
> + struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
> + struct nand_ecc_ctrl *ecc = >ecc;
> + struct sg_table sgt;
> + int ret, i;
> +
> + ret = sunxi_nfc_wait_cmd_fifo_empty(nfc);
> + if (ret)
> + return ret;
> +
> + ret = sunxi_nfc_dma_op_prepare(mtd, buf, ecc->size, ecc->steps,
> +DMA_TO_DEVICE, );
> + if (ret)
> + goto pio_fallback;
> +
> + for (i = 0; i < ecc->steps; i++) {
> + const u8 *oob = nand->oob_poi + (i * (ecc->bytes + 4));
> +
> + sunxi_nfc_hw_ecc_set_prot_oob_bytes(mtd, oob, i, !i, page);
> + }
> +
> + sunxi_nfc_hw_ecc_enable(mtd);
> + sunxi_nfc_randomizer_config(mtd, page, false);
> + sunxi_nfc_randomizer_enable(mtd);
> +
> + writel((NAND_CMD_RNDIN << 8) | NAND_CMD_PAGEPROG,
> +nfc->regs + NFC_REG_RCMD_SET);
> +
> + dma_async_issue_pending(nfc->dmac);
> +
> + writel(NFC_PAGE_OP | NFC_DATA_SWAP_METHOD |
> +NFC_DATA_TRANS | NFC_ACCESS_DIR,
> +nfc->regs + NFC_REG_CMD);
> +
> + ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, true, 0);
> + if (ret)
> + dmaengine_terminate_all(nfc->dmac);
> +
> + sunxi_nfc_randomizer_disable(mtd);
> + sunxi_nfc_hw_ecc_disable(mtd);
> +
> + sunxi_nfc_dma_op_cleanup(mtd, DMA_FROM_DEVICE, );

Should be DMA_TO_DEVICE here ^

> +
> + if (ret)
> + return ret;
> +
> + if (oob_required || (chip->options & NAND_NEED_SCRAMBLING))
> + /* TODO: use DMA to transfer extra OOB bytes ? */
> +     sunxi_nfc_hw_ecc_write_extra_oob(mtd, chip->oob_poi,
> +  NULL, page);
> +
> + return 0;
> +
> +pio_fallback:
> + return sunxi_nfc_hw_ecc_write_page(mtd, chip, buf, oob_required, page);
> +}




-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/7] scatterlist: add sg_alloc_table_from_buf() helper

2016-03-08 Thread Boris Brezillon
Hi Laurent,

On Tue, 08 Mar 2016 18:51:49 +0200
Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote:

> Hi Boris,
> 
> Thank you for the patch.
> 
> On Tuesday 08 March 2016 12:15:12 Boris Brezillon wrote:
> > sg_alloc_table_from_buf() provides an easy solution to create an sg_table
> > from a virtual address pointer. This function takes care of dealing with
> > vmallocated buffers, buffer alignment, or DMA engine limitations (maximum
> > DMA transfer size).
> > 
> > Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> > ---
> >  include/linux/scatterlist.h |  24 
> >  lib/scatterlist.c   | 142 +
> >  2 files changed, 166 insertions(+)
> > 
> > diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
> > index 556ec1e..4a75362 100644
> > --- a/include/linux/scatterlist.h
> > +++ b/include/linux/scatterlist.h
> > @@ -41,6 +41,27 @@ struct sg_table {
> > unsigned int orig_nents;/* original size of list */
> >  };
> > 
> > +/**
> > + * struct sg_constraints - SG constraints structure
> > + *
> > + * @max_chunk_len: maximum chunk buffer length. Each SG entry has to be
> > smaller
> > + *than this value. Zero means no constraint.
> > + * @required_alignment: minimum alignment. Is used for both size and
> > pointer
> > + * alignment. If this constraint is not met, the function
> > + * should return -EINVAL.
> > + * @preferred_alignment: preferred alignment. Mainly used to optimize
> > + *  throughput when the DMA engine performs better when
> > + *  doing aligned accesses.
> > + *
> > + * This structure is here to help sg_alloc_table_from_buf() create the
> > optimal
> > + * SG list based on DMA engine constraints.
> > + */
> > +struct sg_constraints {
> > +   size_t max_chunk_len;
> > +   size_t required_alignment;
> > +   size_t preferred_alignment;
> > +};
> > +
> >  /*
> >   * Notes on SG table design.
> >   *
> > @@ -265,6 +286,9 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
> > struct page **pages, unsigned int n_pages,
> > unsigned long offset, unsigned long size,
> > gfp_t gfp_mask);
> > +int sg_alloc_table_from_buf(struct sg_table *sgt, const void *buf, size_t
> > len,
> > +   const struct sg_constraints *constraints,
> > +   gfp_t gfp_mask);
> > 
> >  size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void
> > *buf, size_t buflen, off_t skip, bool to_buffer);
> > diff --git a/lib/scatterlist.c b/lib/scatterlist.c
> > index bafa993..706b583 100644
> > --- a/lib/scatterlist.c
> > +++ b/lib/scatterlist.c
> > @@ -433,6 +433,148 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
> >  }
> >  EXPORT_SYMBOL(sg_alloc_table_from_pages);
> > 
> > +static size_t sg_buf_chunk_len(const void *buf, size_t len,
> > +  const struct sg_constraints *cons)
> > +{
> > +   size_t chunk_len = len;
> > +
> > +   if (cons->max_chunk_len)
> > +   chunk_len = min_t(size_t, chunk_len, cons->max_chunk_len);
> > +
> > +   if (is_vmalloc_addr(buf))
> > +   chunk_len = min_t(size_t, chunk_len,
> > + PAGE_SIZE - offset_in_page(buf));
> 
> This will lead to page-sized scatter-gather entries even for pages of the 
> vmalloc memory that happen to be physically contiguous. That works, but I 
> wonder whether we'd want to be more efficient.

Hm, I thought dma_map_sg() was taking care of merging pĥysically
contiguous memory regions, but maybe I'm wrong. Anyway, that's
definitely something I can add at this level.

> 
> > +   if (!IS_ALIGNED((unsigned long)buf, cons->preferred_alignment)) {
> > +   const void *aligned_buf = PTR_ALIGN(buf,
> > +   cons->preferred_alignment);
> > +   size_t unaligned_len = (unsigned long)(aligned_buf - buf);
> > +
> > +   chunk_len = min_t(size_t, chunk_len, unaligned_len);
> > +   } else if (chunk_len > cons->preferred_alignment) {
> > +   chunk_len &= ~(cons->preferred_alignment - 1);
> > +   }
> > +
> > +   return chunk_len;
> > +}
> > +
> > +#define sg_for_each_chunk_in_buf(buf, len, chunk_len, constraints) \
> > +   for (chunk_len = sg_buf_chunk_len(buf, len, constraints);   \

Re: [PATCH 5/7] mtd: provide helper to prepare buffers for DMA operations

2016-03-08 Thread Boris Brezillon
On Tue, 8 Mar 2016 19:48:53 +0530
Vinod Koul <vinod.k...@intel.com> wrote:

> On Tue, Mar 08, 2016 at 12:15:13PM +0100, Boris Brezillon wrote:
> >  
> > +#ifdef CONFIG_HAS_DMA
> 
> Shouldn't this be CONFIG_DMA_ENGINE as you are preparing these descriptors
> for DMA transfer?
> 

Nope, scatterlist users are not necessarily using a dmaengine, some IPs
are directly embedding a dedicated DMA engine, which has no driver in
drivers/dma/.

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/7] mtd: nand: sunxi: add support for DMA operations

2016-03-08 Thread Boris Brezillon
Hello,

This patch series aims at adding support for DMA assisted operations to
the sunxi_nand driver.

The first 3 patches are just reworks in the existing driver preparing
things for DMA ->read/write_page() operations. Those ones are mainly
re-arranging existing functions, and moving some code into dedicated
functions so we can reuse them when adding the read/write_page()
implementation.

Patch 4 is an attempt to generalize some logic that are duplicated in a
lot of places. It provides a generic solution to create an SG table
from a buffer (passed by virtual address) and its length.
This generic implementation tries to take all possible constraints into
account, like:
- vmallocated buffers
- alignement requirement/preference
- maximum DMA transfer length

I may have missed other things (is there a need for a minimum DMA
transfer constraint?), so don't hesitate to point problems or missing
elements in this implementation.
Note that other subsystems doing the same kind of thing (like SPI of V4L)
could use this implementation. This is why I've put the SPI and V4L
maintainers in Cc.

Patch 5 is providing functions to map/unmap buffers for DMA operations
at the MTD level. This will hopefully limit the number of open-coded
implementations we're currently seeing in a lot of NAND drivers.
Of course, it's making use of sg_alloc_table_from_buf(), introduced in
patch 4.

Patch 6 and 7 are patching the sunxi NAND driver and its DT binding doc
to add DMA support.

I'm particularly interested in getting feedbacks on patch 4 and 5.
Is there a reason nobody ever tried to create such generic functions
(at the scatterlist and MTD levels), and if there are, could you detail
them?

Thanks,

Boris

Side note: patches touching the sunxi NAND driver are depending on
a series posted yesterday [1].

[1]https://lkml.org/lkml/2016/3/7/444

Boris Brezillon (7):
  mtd: nand: sunxi: move some ECC related operations to their own
functions
  mtd: nand: sunxi: make OOB retrieval optional
  mtd: nand: sunxi: make cur_off parameter optional in extra oob helpers
  scatterlist: add sg_alloc_table_from_buf() helper
  mtd: provide helper to prepare buffers for DMA operations
  mtd: nand: sunxi: add support for DMA assisted operations
  mtd: nand: sunxi: update DT bindings

 .../devicetree/bindings/mtd/sunxi-nand.txt |   4 +
 drivers/mtd/mtdcore.c  |  66 +++
 drivers/mtd/nand/sunxi_nand.c  | 483 ++---
 include/linux/mtd/mtd.h|  25 ++
 include/linux/scatterlist.h|  24 +
 lib/scatterlist.c  | 142 ++
 6 files changed, 679 insertions(+), 65 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 4/7] scatterlist: add sg_alloc_table_from_buf() helper

2016-03-08 Thread Boris Brezillon
sg_alloc_table_from_buf() provides an easy solution to create an sg_table
from a virtual address pointer. This function takes care of dealing with
vmallocated buffers, buffer alignment, or DMA engine limitations (maximum
DMA transfer size).

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 include/linux/scatterlist.h |  24 
 lib/scatterlist.c   | 142 
 2 files changed, 166 insertions(+)

diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 556ec1e..4a75362 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -41,6 +41,27 @@ struct sg_table {
unsigned int orig_nents;/* original size of list */
 };
 
+/**
+ * struct sg_constraints - SG constraints structure
+ *
+ * @max_chunk_len: maximum chunk buffer length. Each SG entry has to be smaller
+ *than this value. Zero means no constraint.
+ * @required_alignment: minimum alignment. Is used for both size and pointer
+ * alignment. If this constraint is not met, the function
+ * should return -EINVAL.
+ * @preferred_alignment: preferred alignment. Mainly used to optimize
+ *  throughput when the DMA engine performs better when
+ *  doing aligned accesses.
+ *
+ * This structure is here to help sg_alloc_table_from_buf() create the optimal
+ * SG list based on DMA engine constraints.
+ */
+struct sg_constraints {
+   size_t max_chunk_len;
+   size_t required_alignment;
+   size_t preferred_alignment;
+};
+
 /*
  * Notes on SG table design.
  *
@@ -265,6 +286,9 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
unsigned long offset, unsigned long size,
gfp_t gfp_mask);
+int sg_alloc_table_from_buf(struct sg_table *sgt, const void *buf, size_t len,
+   const struct sg_constraints *constraints,
+   gfp_t gfp_mask);
 
 size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void *buf,
  size_t buflen, off_t skip, bool to_buffer);
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index bafa993..706b583 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -433,6 +433,148 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
 }
 EXPORT_SYMBOL(sg_alloc_table_from_pages);
 
+static size_t sg_buf_chunk_len(const void *buf, size_t len,
+  const struct sg_constraints *cons)
+{
+   size_t chunk_len = len;
+
+   if (cons->max_chunk_len)
+   chunk_len = min_t(size_t, chunk_len, cons->max_chunk_len);
+
+   if (is_vmalloc_addr(buf))
+   chunk_len = min_t(size_t, chunk_len,
+ PAGE_SIZE - offset_in_page(buf));
+
+   if (!IS_ALIGNED((unsigned long)buf, cons->preferred_alignment)) {
+   const void *aligned_buf = PTR_ALIGN(buf,
+   cons->preferred_alignment);
+   size_t unaligned_len = (unsigned long)(aligned_buf - buf);
+
+   chunk_len = min_t(size_t, chunk_len, unaligned_len);
+   } else if (chunk_len > cons->preferred_alignment) {
+   chunk_len &= ~(cons->preferred_alignment - 1);
+   }
+
+   return chunk_len;
+}
+
+#define sg_for_each_chunk_in_buf(buf, len, chunk_len, constraints) \
+   for (chunk_len = sg_buf_chunk_len(buf, len, constraints);   \
+len;   \
+len -= chunk_len, buf += chunk_len,\
+chunk_len = sg_buf_chunk_len(buf, len, constraints))
+
+static int sg_check_constraints(struct sg_constraints *cons,
+   const void *buf, size_t len)
+{
+   if (!cons->required_alignment)
+   cons->required_alignment = 1;
+
+   if (!cons->preferred_alignment)
+   cons->preferred_alignment = cons->required_alignment;
+
+   /* Test if buf and len are properly aligned. */
+   if (!IS_ALIGNED((unsigned long)buf, cons->required_alignment) ||
+   !IS_ALIGNED(len, cons->required_alignment))
+   return -EINVAL;
+
+   /*
+* if the buffer has been vmallocated and required_alignment is
+* more than PAGE_SIZE we cannot guarantee it.
+*/
+   if (is_vmalloc_addr(buf) && cons->required_alignment > PAGE_SIZE)
+   return -EINVAL;
+
+   /*
+* max_chunk_len has to be aligned to required_alignment to
+* guarantee that all buffer chunks are aligned correctly.
+*/
+   if (!IS_ALIGNED(cons->max_chunk_len, cons->required_alignment))
+   return -EINVAL;
+
+   /*
+* preferred_alignment has to be aligned

[PATCH 7/7] mtd: nand: sunxi: update DT bindings

2016-03-08 Thread Boris Brezillon
Document dmas and dma-names properties.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 Documentation/devicetree/bindings/mtd/sunxi-nand.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt 
b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
index 086d6f4..6fdf8f6 100644
--- a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
@@ -11,6 +11,10 @@ Required properties:
 * "ahb" : AHB gating clock
 * "mod" : nand controller clock
 
+Optional properties:
+- dmas : shall reference DMA channel associated to the NAND controller.
+- dma-names : shall be "rxtx".
+
 Optional children nodes:
 Children nodes represent the available nand chips.
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 6/7] mtd: nand: sunxi: add support for DMA assisted operations

2016-03-08 Thread Boris Brezillon
The sunxi NAND controller is able to pipeline ECC operations only when
operated in DMA mode, which improves a lot NAND throughput while keeping
CPU usage low.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand.c | 301 +-
 1 file changed, 297 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 07c3af7..7ba285e 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -277,6 +277,7 @@ struct sunxi_nfc {
unsigned long clk_rate;
struct list_head chips;
struct completion complete;
+   struct dma_chan *dmac;
 };
 
 static inline struct sunxi_nfc *to_sunxi_nfc(struct nand_hw_control *ctrl)
@@ -369,6 +370,68 @@ static int sunxi_nfc_rst(struct sunxi_nfc *nfc)
return ret;
 }
 
+static int sunxi_nfc_dma_op_prepare(struct mtd_info *mtd, const void *buf,
+   int chunksize, int nchunks,
+   enum dma_data_direction ddir,
+   struct sg_table *sgt)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   struct dma_async_tx_descriptor *dmad;
+   enum dma_transfer_direction tdir;
+   dma_cookie_t dmat;
+   int ret;
+
+   if (ddir == DMA_FROM_DEVICE)
+   tdir = DMA_DEV_TO_MEM;
+   else
+   tdir = DMA_MEM_TO_DEV;
+
+   ret = mtd_map_buf(mtd, nfc->dev, sgt, buf, nchunks * chunksize,
+ NULL, ddir);
+   if (ret)
+   return ret;
+
+   dmad = dmaengine_prep_slave_sg(nfc->dmac, sgt->sgl, sgt->nents,
+  tdir, DMA_CTRL_ACK);
+   if (IS_ERR(dmad)) {
+   ret = PTR_ERR(dmad);
+   goto err_unmap_buf;
+   }
+
+   writel(readl(nfc->regs + NFC_REG_CTL) | NFC_RAM_METHOD,
+  nfc->regs + NFC_REG_CTL);
+   writel(nchunks, nfc->regs + NFC_REG_SECTOR_NUM);
+   writel(chunksize, nfc->regs + NFC_REG_CNT);
+   dmat = dmaengine_submit(dmad);
+
+   ret = dma_submit_error(dmat);
+   if (ret)
+   goto err_clr_dma_flag;
+
+   return 0;
+
+err_clr_dma_flag:
+   writel(readl(nfc->regs + NFC_REG_CTL) & ~NFC_RAM_METHOD,
+  nfc->regs + NFC_REG_CTL);
+
+err_unmap_buf:
+   mtd_unmap_buf(mtd, nfc->dev, sgt, ddir);
+   return ret;
+}
+
+static void sunxi_nfc_dma_op_cleanup(struct mtd_info *mtd,
+enum dma_data_direction ddir,
+struct sg_table *sgt)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+
+   mtd_unmap_buf(mtd, nfc->dev, sgt, ddir);
+   writel(readl(nfc->regs + NFC_REG_CTL) & ~NFC_RAM_METHOD,
+  nfc->regs + NFC_REG_CTL);
+}
+
 static int sunxi_nfc_dev_ready(struct mtd_info *mtd)
 {
struct nand_chip *nand = mtd_to_nand(mtd);
@@ -971,6 +1034,106 @@ static void sunxi_nfc_hw_ecc_read_extra_oob(struct 
mtd_info *mtd,
*cur_off = mtd->oobsize + mtd->writesize;
 }
 
+static int sunxi_nfc_hw_ecc_read_chunks_dma(struct mtd_info *mtd, uint8_t *buf,
+   int oob_required, int page,
+   int nchunks)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   struct nand_ecc_ctrl *ecc = >ecc;
+   unsigned int max_bitflips = 0;
+   int ret, i, raw_mode = 0;
+   struct sg_table sgt;
+
+   ret = sunxi_nfc_wait_cmd_fifo_empty(nfc);
+   if (ret)
+   return ret;
+
+   ret = sunxi_nfc_dma_op_prepare(mtd, buf, ecc->size, nchunks,
+  DMA_FROM_DEVICE, );
+   if (ret)
+   return ret;
+
+   sunxi_nfc_hw_ecc_enable(mtd);
+   sunxi_nfc_randomizer_config(mtd, page, false);
+   sunxi_nfc_randomizer_enable(mtd);
+
+   writel((NAND_CMD_RNDOUTSTART << 16) | (NAND_CMD_RNDOUT << 8) |
+  NAND_CMD_READSTART, nfc->regs + NFC_REG_RCMD_SET);
+
+   dma_async_issue_pending(nfc->dmac);
+
+   writel(NFC_PAGE_OP | NFC_DATA_SWAP_METHOD | NFC_DATA_TRANS,
+  nfc->regs + NFC_REG_CMD);
+
+   ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, true, 0);
+   if (ret)
+   dmaengine_terminate_all(nfc->dmac);
+
+   sunxi_nfc_randomizer_disable(mtd);
+   sunxi_nfc_hw_ecc_disable(mtd);
+
+   sunxi_nfc_dma_op_cleanup(mtd, DMA_FROM_DEVICE, );
+
+   if (ret)
+   return ret;
+
+   for (i = 0; i < nchunks; i++) {
+   int data_off = i * ecc->size;
+   int oob_off = i * (ec

[PATCH 1/7] mtd: nand: sunxi: move some ECC related operations to their own functions

2016-03-08 Thread Boris Brezillon
In order to support DMA operations in a clean way we need to extract some
of the logic coded in sunxi_nfc_hw_ecc_read/write_page() into their own
function.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand.c | 163 --
 1 file changed, 108 insertions(+), 55 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 0616f3b..90c121d 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -776,6 +776,94 @@ static inline void sunxi_nfc_user_data_to_buf(u32 
user_data, u8 *buf)
buf[3] = user_data >> 24;
 }
 
+static inline u32 sunxi_nfc_buf_to_user_data(const u8 *buf)
+{
+   return buf[0] | (buf[1] << 8) | (buf[2] << 16) | (buf[3] << 24);
+}
+
+static void sunxi_nfc_hw_ecc_get_prot_oob_bytes(struct mtd_info *mtd, u8 *oob,
+   int step, bool bbm, int page)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+
+   sunxi_nfc_user_data_to_buf(readl(nfc->regs + NFC_REG_USER_DATA(step)),
+  oob);
+
+   /* De-randomize the Bad Block Marker. */
+   if (bbm && (nand->options & NAND_NEED_SCRAMBLING))
+   sunxi_nfc_randomize_bbm(mtd, page, oob);
+}
+
+static void sunxi_nfc_hw_ecc_set_prot_oob_bytes(struct mtd_info *mtd,
+   const u8 *oob, int step,
+   bool bbm, int page)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   u8 user_data[4];
+
+   /* Randomize the Bad Block Marker. */
+   if (bbm && (nand->options & NAND_NEED_SCRAMBLING)) {
+   memcpy(user_data, oob, sizeof(user_data));
+   sunxi_nfc_randomize_bbm(mtd, page, user_data);
+   oob = user_data;
+   }
+
+   writel(sunxi_nfc_buf_to_user_data(oob),
+  nfc->regs + NFC_REG_USER_DATA(step));
+}
+
+static void sunxi_nfc_hw_ecc_update_stats(struct mtd_info *mtd,
+ unsigned int *max_bitflips, int ret)
+{
+   if (ret < 0) {
+   mtd->ecc_stats.failed++;
+   } else {
+   mtd->ecc_stats.corrected += ret;
+   *max_bitflips = max_t(unsigned int, *max_bitflips, ret);
+   }
+}
+
+static int sunxi_nfc_hw_ecc_correct(struct mtd_info *mtd, u8 *data, u8 *oob,
+   int step, bool *erased)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   struct nand_ecc_ctrl *ecc = >ecc;
+   u32 status, tmp;
+
+   *erased = false;
+
+   status = readl(nfc->regs + NFC_REG_ECC_ST);
+
+   if (status & NFC_ECC_ERR(step))
+   return -EBADMSG;
+
+   if (status & NFC_ECC_PAT_FOUND(step)) {
+   u8 pattern;
+
+   if (unlikely(!(readl(nfc->regs + NFC_REG_PAT_ID) & 0x1))) {
+   pattern = 0x0;
+   } else {
+   pattern = 0xff;
+   *erased = true;
+   }
+
+   if (data)
+   memset(data, pattern, ecc->size);
+
+   if (oob)
+   memset(oob, pattern, ecc->bytes + 4);
+
+   return 0;
+   }
+
+   tmp = readl(nfc->regs + NFC_REG_ECC_ERR_CNT(step));
+
+   return NFC_ECC_ERR_CNT(step, tmp);
+}
+
 static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
   u8 *data, int data_off,
   u8 *oob, int oob_off,
@@ -787,7 +875,7 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
struct nand_ecc_ctrl *ecc = >ecc;
int raw_mode = 0;
-   u32 status;
+   bool erased;
int ret;
 
if (*cur_off != data_off)
@@ -813,27 +901,11 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info 
*mtd,
 
*cur_off = oob_off + ecc->bytes + 4;
 
-   status = readl(nfc->regs + NFC_REG_ECC_ST);
-   if (status & NFC_ECC_PAT_FOUND(0)) {
-   u8 pattern = 0xff;
-
-   if (unlikely(!(readl(nfc->regs + NFC_REG_PAT_ID) & 0x1)))
-   pattern = 0x0;
-
-   memset(data, pattern, ecc->size);
-   memset(oob, pattern, ecc->bytes + 4);
-
+   ret = sunxi_nfc_hw_ecc_correct(mtd, data, oob, 0, );
+   if (erased)
return 1;
-   }
-
-   ret = NFC_ECC_ERR_CNT(0, readl(nfc->regs + NFC_REG_ECC_ERR_CNT(0)));
-
-   memcpy_fromio(data, nfc->regs + NFC_RAM0_BAS

[PATCH 2/7] mtd: nand: sunxi: make OOB retrieval optional

2016-03-08 Thread Boris Brezillon
sunxi_nfc_hw_ecc_read_chunk() always retrieves the ECC and protected free
bytes, no matter if the user really asked for it or not. This can take a
non negligible amount of time, especially on NAND chips exposing large OOB
areas (> 1KB). Make it optional.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand.c | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 90c121d..7b3ae72 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -869,7 +869,7 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
   u8 *oob, int oob_off,
   int *cur_off,
   unsigned int *max_bitflips,
-  bool bbm, int page)
+  bool bbm, bool oob_required, int page)
 {
struct nand_chip *nand = mtd_to_nand(mtd);
struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
@@ -901,7 +901,8 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
 
*cur_off = oob_off + ecc->bytes + 4;
 
-   ret = sunxi_nfc_hw_ecc_correct(mtd, data, oob, 0, );
+   ret = sunxi_nfc_hw_ecc_correct(mtd, data, oob_required ? oob : NULL, 0,
+  );
if (erased)
return 1;
 
@@ -929,12 +930,14 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info 
*mtd,
} else {
memcpy_fromio(data, nfc->regs + NFC_RAM0_BASE, ecc->size);
 
-   nand->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_off, -1);
-   sunxi_nfc_randomizer_read_buf(mtd, oob, ecc->bytes + 4,
- true, page);
+   if (oob_required) {
+   nand->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_off, -1);
+   sunxi_nfc_randomizer_read_buf(mtd, oob, ecc->bytes + 4,
+ true, page);
 
-   sunxi_nfc_hw_ecc_get_prot_oob_bytes(mtd, oob, 0,
-   bbm, page);
+   sunxi_nfc_hw_ecc_get_prot_oob_bytes(mtd, oob, 0,
+   bbm, page);
+   }
}
 
sunxi_nfc_hw_ecc_update_stats(mtd, max_bitflips, ret);
@@ -1048,7 +1051,7 @@ static int sunxi_nfc_hw_ecc_read_page(struct mtd_info 
*mtd,
ret = sunxi_nfc_hw_ecc_read_chunk(mtd, data, data_off, oob,
  oob_off + mtd->writesize,
  _off, _bitflips,
- !i, page);
+ !i, oob_required, page);
if (ret < 0)
return ret;
else if (ret)
@@ -1086,8 +1089,8 @@ static int sunxi_nfc_hw_ecc_read_subpage(struct mtd_info 
*mtd,
ret = sunxi_nfc_hw_ecc_read_chunk(mtd, data, data_off,
  oob,
  oob_off + mtd->writesize,
- _off, _bitflips,
- !i, page);
+ _off, _bitflips, !i,
+ false, page);
if (ret < 0)
return ret;
}
@@ -1149,7 +1152,9 @@ static int sunxi_nfc_hw_syndrome_ecc_read_page(struct 
mtd_info *mtd,
 
ret = sunxi_nfc_hw_ecc_read_chunk(mtd, data, data_off, oob,
  oob_off, _off,
- _bitflips, !i, page);
+ _bitflips, !i,
+ oob_required,
+ page);
if (ret < 0)
return ret;
else if (ret)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/7] mtd: nand: sunxi: make cur_off parameter optional in extra oob helpers

2016-03-08 Thread Boris Brezillon
Allow for NULL cur_offs values when the caller does not know where the
NAND page register pointer point to.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 7b3ae72..07c3af7 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -957,7 +957,7 @@ static void sunxi_nfc_hw_ecc_read_extra_oob(struct mtd_info 
*mtd,
if (len <= 0)
return;
 
-   if (*cur_off != offset)
+   if (!cur_off || *cur_off != offset)
nand->cmdfunc(mtd, NAND_CMD_RNDOUT,
  offset + mtd->writesize, -1);
 
@@ -967,7 +967,8 @@ static void sunxi_nfc_hw_ecc_read_extra_oob(struct mtd_info 
*mtd,
sunxi_nfc_randomizer_read_buf(mtd, oob + offset, len,
  false, page);
 
-   *cur_off = mtd->oobsize + mtd->writesize;
+   if (cur_off)
+   *cur_off = mtd->oobsize + mtd->writesize;
 }
 
 static int sunxi_nfc_hw_ecc_write_chunk(struct mtd_info *mtd,
@@ -1022,13 +1023,14 @@ static void sunxi_nfc_hw_ecc_write_extra_oob(struct 
mtd_info *mtd,
if (len <= 0)
return;
 
-   if (*cur_off != offset)
+   if (!cur_off || *cur_off != offset)
nand->cmdfunc(mtd, NAND_CMD_RNDIN,
  offset + mtd->writesize, -1);
 
sunxi_nfc_randomizer_write_buf(mtd, oob + offset, len, false, page);
 
-   *cur_off = mtd->oobsize + mtd->writesize;
+   if (cur_off)
+   *cur_off = mtd->oobsize + mtd->writesize;
 }
 
 static int sunxi_nfc_hw_ecc_read_page(struct mtd_info *mtd,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] clk: change clk_ops' -round_rate() prototype

2015-06-05 Thread Boris Brezillon
Hi Jon,

On Fri, 5 Jun 2015 09:46:09 +0100
Jon Hunter jonath...@nvidia.com wrote:

 
 On 05/06/15 00:02, Paul Walmsley wrote:
  Hi folks
  
  just a brief comment on this one:
  
  On Thu, 30 Apr 2015, Boris Brezillon wrote:
  
  Clock rates are stored in an unsigned long field, but -round_rate()
  (which returns a rounded rate from a requested one) returns a long
  value (errors are reported using negative error codes), which can lead
  to long overflow if the clock rate exceed 2Ghz.
 
  Change -round_rate() prototype to return 0 or an error code, and pass the
  requested rate as a pointer so that it can be adjusted depending on
  hardware capabilities.
  
  ...
  
  diff --git a/Documentation/clk.txt b/Documentation/clk.txt
  index 0e4f90a..fca8b7a 100644
  --- a/Documentation/clk.txt
  +++ b/Documentation/clk.txt
  @@ -68,8 +68,8 @@ the operations defined in clk.h:
 int (*is_enabled)(struct clk_hw *hw);
 unsigned long   (*recalc_rate)(struct clk_hw *hw,
 unsigned long parent_rate);
  -  long(*round_rate)(struct clk_hw *hw,
  -  unsigned long rate,
  +  int (*round_rate)(struct clk_hw *hw,
  +  unsigned long *rate,
 unsigned long *parent_rate);
 long(*determine_rate)(struct clk_hw *hw,
 unsigned long rate,
  
  I'd suggest that we should probably go straight to 64-bit rates.  There 
  are already plenty of clock sources that can generate rates higher than 
  4GiHz.
 
 An alternative would be to introduce to a frequency base the default
 could be Hz (for backwards compatibility), but for CPUs we probably only
 care about MHz (or may be kHz) and so 32-bits would still suffice. Even
 if CPUs cared about Hz they could still use Hz, but in that case they
 probably don't care about GHz. Obviously, we don't want to break DT
 compatibility but may be the frequency base could be defined in DT and
 if it is missing then Hz is assumed. Just a thought ...

Yes, but is it really worth the additional complexity. You'll have to
add the unit information anyway, so using an unsigned long for the
value and another field for the unit (an enum ?) is just like using a
64 bit integer.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] clk: change clk_ops' -round_rate() prototype

2015-06-05 Thread Boris Brezillon
Hi Paul,

On Thu, 4 Jun 2015 23:02:25 + (UTC)
Paul Walmsley p...@pwsan.com wrote:

 Hi folks
 
 just a brief comment on this one:
 
 On Thu, 30 Apr 2015, Boris Brezillon wrote:
 
  Clock rates are stored in an unsigned long field, but -round_rate()
  (which returns a rounded rate from a requested one) returns a long
  value (errors are reported using negative error codes), which can lead
  to long overflow if the clock rate exceed 2Ghz.
  
  Change -round_rate() prototype to return 0 or an error code, and pass the
  requested rate as a pointer so that it can be adjusted depending on
  hardware capabilities.
 
 ...
 
  diff --git a/Documentation/clk.txt b/Documentation/clk.txt
  index 0e4f90a..fca8b7a 100644
  --- a/Documentation/clk.txt
  +++ b/Documentation/clk.txt
  @@ -68,8 +68,8 @@ the operations defined in clk.h:
  int (*is_enabled)(struct clk_hw *hw);
  unsigned long   (*recalc_rate)(struct clk_hw *hw,
  unsigned long parent_rate);
  -   long(*round_rate)(struct clk_hw *hw,
  -   unsigned long rate,
  +   int (*round_rate)(struct clk_hw *hw,
  +   unsigned long *rate,
  unsigned long *parent_rate);
  long(*determine_rate)(struct clk_hw *hw,
  unsigned long rate,
 
 I'd suggest that we should probably go straight to 64-bit rates.  There 
 are already plenty of clock sources that can generate rates higher than 
 4GiHz.

Yep, that was something I was considering too. If Stephen agrees I'll
change that in the next version.
BTW, you're referring to the second version of this patch, but things
have changed a bit: Stephen recommended to only modify the
-determine_rate() prototype and pass a structure instead of a list of
arguments.
Here is the last version of this series [1].

Best Regards,

Boris

[1]http://patchwork.linux-mips.org/patch/10092/

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] clk: change clk_ops' -round_rate() prototype

2015-05-15 Thread Boris Brezillon
Hi Stephen,

Adding Mikko in the loop (after all, he was the one complaining about
this signed long limitation in the first place, and I forgot to add
him in the Cc list :-/).

Mikko, are you okay with the approach proposed by Stephen (adding a
new method) ?

On Thu, 7 May 2015 09:37:02 +0200
Boris Brezillon boris.brezil...@free-electrons.com wrote:

 Hi Stephen,
 
 On Wed, 6 May 2015 23:39:53 -0700
 Stephen Boyd sb...@codeaurora.org wrote:
 
  On 04/30, Boris Brezillon wrote:
   Clock rates are stored in an unsigned long field, but -round_rate()
   (which returns a rounded rate from a requested one) returns a long
   value (errors are reported using negative error codes), which can lead
   to long overflow if the clock rate exceed 2Ghz.
   
   Change -round_rate() prototype to return 0 or an error code, and pass the
   requested rate as a pointer so that it can be adjusted depending on
   hardware capabilities.
   
   Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
   Tested-by: Heiko Stuebner he...@sntech.de
   Tested-by: Mikko Perttunen mikko.perttu...@kapsi.fi
   Reviewed-by: Heiko Stuebner he...@sntech.de
  
  This patch is fairly invasive, and it probably doesn't even
  matter for most of these clock providers to be able to round a
  rate above 2GHz.
 
 Fair enough.
 
  I've been trying to remove the .round_rate op
  from the framework by encouraging new features via the
  .determine_rate op.
 
 Oh, I wasn't aware of that (BTW, that's a good thing).
 Maybe this should be clearly stated (both in the struct clk_ops
 kerneldoc header and in Documentation/clk.txt).
 
  Sadly, we still have to do a flag day and
  change all the .determine_rate ops when we want to add things.
 
 Yes, but the number of clk drivers implementing -determine_rate() is
 still quite limited compared to those implementing -round_rate().
 
  
  What if we changed determine_rate ops to take a struct
  clk_determine_info (or some better named structure) instead of
  the current list of arguments that it currently takes? Then when
  we want to make these sorts of framework wide changes we can just
  throw a new member into that structure and be done.
 
 I really like this idea, especially since I was wondering if we could
 pass other 'clk rate requirements' like the rounding policy (down,
 closest, up), or the maximum clk inaccuracy.
 
  
  It doesn't solve the unsigned long to int return value problem
  though. We can solve that by gradually introducing a new op and
  handling another case in the rounding path. If we can come up
  with some good name for that new op like .decide_rate or
  something then it makes things nicer in the long run. I like the
  name .determine_rate though :/

Okay, if you want a new method, how about this one:

struct clk_adjust_rate_req {
/* fields filled by the caller */
unsigned long rate; /* rate is updated by the clk driver */
unsigned long min;
unsigned long max;

/* fields filled by the clk driver */
struct clk_hw *best_parent;
unsigned long best_parent_rate;

/*
 * new fields I'd like to add at some point:
 * unsigned long max_inaccuracy;
 * something about the power consumption constraints :-)
 */
};

int (*adjust_rate)(struct clk_hw *hw, struct clk_adjust_rate_req *req);

 
 Why not changing the -determine_rate() prototype. As said above, the
 number of clk drivers implementing this function is still quite
 limited, and I guess we can have an ack for all of them.
 
  
  The benefit of all this is that we don't have to worry about
  finding the random clk providers that get added into other
  subsystems and fixing them up. If drivers actually care about
  this problem then they'll be fixed to use the proper op. FYI,
  last time we updated the function signature of .determine_rate we
  broke a couple drivers along the way.
  
 
 Hm, IMHO, adding a new op is not a good thing. I agree that it eases
 the transition, but ITOH you'll have to live with old/deprecated ops in
 your clk_ops structure with people introducing new drivers still using
 the old ops (see the number of clk drivers implementing -round_rate()
 instead of -determine_rate()).
 
 Best Regards,
 
 Boris
 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] clk: change clk_ops' -round_rate() prototype

2015-05-07 Thread Boris Brezillon
Hi Stephen,

On Wed, 6 May 2015 23:39:53 -0700
Stephen Boyd sb...@codeaurora.org wrote:

 On 04/30, Boris Brezillon wrote:
  Clock rates are stored in an unsigned long field, but -round_rate()
  (which returns a rounded rate from a requested one) returns a long
  value (errors are reported using negative error codes), which can lead
  to long overflow if the clock rate exceed 2Ghz.
  
  Change -round_rate() prototype to return 0 or an error code, and pass the
  requested rate as a pointer so that it can be adjusted depending on
  hardware capabilities.
  
  Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
  Tested-by: Heiko Stuebner he...@sntech.de
  Tested-by: Mikko Perttunen mikko.perttu...@kapsi.fi
  Reviewed-by: Heiko Stuebner he...@sntech.de
 
 This patch is fairly invasive, and it probably doesn't even
 matter for most of these clock providers to be able to round a
 rate above 2GHz.

Fair enough.

 I've been trying to remove the .round_rate op
 from the framework by encouraging new features via the
 .determine_rate op.

Oh, I wasn't aware of that (BTW, that's a good thing).
Maybe this should be clearly stated (both in the struct clk_ops
kerneldoc header and in Documentation/clk.txt).

 Sadly, we still have to do a flag day and
 change all the .determine_rate ops when we want to add things.

Yes, but the number of clk drivers implementing -determine_rate() is
still quite limited compared to those implementing -round_rate().

 
 What if we changed determine_rate ops to take a struct
 clk_determine_info (or some better named structure) instead of
 the current list of arguments that it currently takes? Then when
 we want to make these sorts of framework wide changes we can just
 throw a new member into that structure and be done.

I really like this idea, especially since I was wondering if we could
pass other 'clk rate requirements' like the rounding policy (down,
closest, up), or the maximum clk inaccuracy.

 
 It doesn't solve the unsigned long to int return value problem
 though. We can solve that by gradually introducing a new op and
 handling another case in the rounding path. If we can come up
 with some good name for that new op like .decide_rate or
 something then it makes things nicer in the long run. I like the
 name .determine_rate though :/

Why not changing the -determine_rate() prototype. As said above, the
number of clk drivers implementing this function is still quite
limited, and I guess we can have an ack for all of them.

 
 The benefit of all this is that we don't have to worry about
 finding the random clk providers that get added into other
 subsystems and fixing them up. If drivers actually care about
 this problem then they'll be fixed to use the proper op. FYI,
 last time we updated the function signature of .determine_rate we
 broke a couple drivers along the way.
 

Hm, IMHO, adding a new op is not a good thing. I agree that it eases
the transition, but ITOH you'll have to live with old/deprecated ops in
your clk_ops structure with people introducing new drivers still using
the old ops (see the number of clk drivers implementing -round_rate()
instead of -determine_rate()).

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 0/2] clk: adapt -round_rate()/-determine_rate() prototypes

2015-04-30 Thread Boris Brezillon
Hello,

As previously discussed in this thread [1], this series is changing
clk_ops' -round_rate()/-determine_rate() prototypes to avoid long
overflows when the returned rate is exceeding 2Ghz.

Most of those changes have been compile-tested, but none of them have
been tested on real hardware (the changes are quite simple though).

Best Regards,

Boris

[1]https://lkml.org/lkml/2015/4/14/528

Changes since v1:
- fix an 'uninitialized variable' bug reported by Heiko
- rebased on clk-next

CC: Jonathan Corbet cor...@lwn.net
CC: Shawn Guo shawn@linaro.org
CC: ascha Hauer ker...@pengutronix.de
CC: David Brown dav...@codeaurora.org
CC: Daniel Walker dwal...@fifo99.com
CC: Bryan Huntsman bry...@codeaurora.org
CC: Tony Lindgren t...@atomide.com
CC: Paul Walmsley p...@pwsan.com
CC: Liviu Dudau liviu.du...@arm.com
CC: Sudeep Holla sudeep.ho...@arm.com
CC: Lorenzo Pieralisi lorenzo.pieral...@arm.com
CC: Ralf Baechle r...@linux-mips.org
CC: Max Filippov jcmvb...@gmail.com
CC: Heiko Stuebner he...@sntech.de
CC: Sylwester Nawrocki s.nawro...@samsung.com 
CC: Tomasz Figa tomasz.f...@gmail.com
CC: Barry Song bao...@kernel.org
CC: Viresh Kumar viresh.li...@gmail.com
CC: Emilio L??pez emi...@elopez.com.ar
CC: Maxime Ripard maxime.rip...@free-electrons.com
CC: Peter De Schrijver pdeschrij...@nvidia.com
CC: Prashant Gaikwad pgaik...@nvidia.com
CC: Stephen Warren swar...@wwwdotorg.org
CC: Thierry Reding thierry.red...@gmail.com
CC: Alexandre Courbot gnu...@gmail.com
CC: Tero Kristo t-kri...@ti.com
CC: Ulf Hansson ulf.hans...@linaro.org
CC: Michal Simek michal.si...@xilinx.com
CC: Philipp Zabel p.za...@pengutronix.de
CC: linux-...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: linux-arm-ker...@lists.infradead.org
CC: linux-arm-...@vger.kernel.org
CC: linux-o...@vger.kernel.org
CC: linux-m...@linux-mips.org
CC: patc...@opensource.wolfsonmicro.com
CC: linux-rockc...@lists.infradead.org
CC: linux-samsung-...@vger.kernel.org
CC: spear-de...@list.st.com
CC: linux-te...@vger.kernel.org
CC: dri-de...@lists.freedesktop.org
CC: linux-media@vger.kernel.org
CC: rtc-li...@googlegroups.com

Boris Brezillon (2):
  clk: change clk_ops' -round_rate() prototype
  clk: change clk_ops' -determine_rate() prototype

 Documentation/clk.txt|  8 +--
 arch/arm/mach-imx/clk-busy.c |  2 +-
 arch/arm/mach-imx/clk-cpu.c  | 12 +++-
 arch/arm/mach-imx/clk-fixup-div.c|  2 +-
 arch/arm/mach-imx/clk-pfd.c  | 11 ++--
 arch/arm/mach-imx/clk-pllv2.c|  8 ++-
 arch/arm/mach-imx/clk-pllv3.c| 46 +++--
 arch/arm/mach-msm/clock-pcom.c   |  4 +-
 arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 13 ++--
 arch/arm/mach-omap2/clkt_clksel.c|  6 +-
 arch/arm/mach-omap2/clkt_dpll.c  | 21 +++---
 arch/arm/mach-omap2/clock.h  |  4 +-
 arch/arm/mach-omap2/dpll3xxx.c   | 45 -
 arch/arm/mach-omap2/dpll44xx.c   | 44 +++--
 arch/arm/mach-vexpress/spc.c | 11 +++-
 arch/mips/alchemy/common/clock.c | 76 ++
 drivers/clk/at91/clk-h32mx.c | 24 ---
 drivers/clk/at91/clk-peripheral.c| 31 +
 drivers/clk/at91/clk-pll.c   | 14 ++--
 drivers/clk/at91/clk-plldiv.c| 22 ---
 drivers/clk/at91/clk-programmable.c  | 28 
 drivers/clk/at91/clk-smd.c   | 24 ---
 drivers/clk/at91/clk-usb.c   | 42 ++--
 drivers/clk/bcm/clk-kona.c   | 24 ---
 drivers/clk/clk-axi-clkgen.c |  5 +-
 drivers/clk/clk-cdce706.c| 46 ++---
 drivers/clk/clk-composite.c  | 27 
 drivers/clk/clk-divider.c| 16 +++--
 drivers/clk/clk-fixed-factor.c   |  7 +-
 drivers/clk/clk-fractional-divider.c | 16 +++--
 drivers/clk/clk-highbank.c   | 18 +++---
 drivers/clk/clk-si5351.c | 96 ++--
 drivers/clk/clk-si570.c  | 14 ++--
 drivers/clk/clk-u300.c   | 65 ++-
 drivers/clk/clk-vt8500.c | 27 
 drivers/clk/clk-wm831x.c | 11 ++--
 drivers/clk/clk-xgene.c  | 11 ++--
 drivers/clk/clk.c| 72 +++--
 drivers/clk/hisilicon/clk-hi3620.c   | 22 +++
 drivers/clk/mmp/clk-frac.c   | 14 ++--
 drivers/clk/mmp/clk-mix.c| 17 ++---
 drivers/clk/mvebu/clk-corediv.c  |  7 +-
 drivers/clk/mvebu/clk-cpu.c  |  9 +--
 drivers/clk/mxs/clk-div.c|  4 +-
 drivers/clk/mxs/clk-frac.c   | 11 ++--
 drivers/clk/mxs/clk-ref.c| 11 ++--
 drivers/clk/qcom/clk-pll.c   | 12

[PATCH v2 1/2] clk: change clk_ops' -round_rate() prototype

2015-04-30 Thread Boris Brezillon
Clock rates are stored in an unsigned long field, but -round_rate()
(which returns a rounded rate from a requested one) returns a long
value (errors are reported using negative error codes), which can lead
to long overflow if the clock rate exceed 2Ghz.

Change -round_rate() prototype to return 0 or an error code, and pass the
requested rate as a pointer so that it can be adjusted depending on
hardware capabilities.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Tested-by: Heiko Stuebner he...@sntech.de
Tested-by: Mikko Perttunen mikko.perttu...@kapsi.fi
Reviewed-by: Heiko Stuebner he...@sntech.de
---
CC: Jonathan Corbet cor...@lwn.net
CC: Shawn Guo shawn@linaro.org
CC: ascha Hauer ker...@pengutronix.de
CC: David Brown dav...@codeaurora.org
CC: Daniel Walker dwal...@fifo99.com
CC: Bryan Huntsman bry...@codeaurora.org
CC: Tony Lindgren t...@atomide.com
CC: Paul Walmsley p...@pwsan.com
CC: Liviu Dudau liviu.du...@arm.com
CC: Sudeep Holla sudeep.ho...@arm.com
CC: Lorenzo Pieralisi lorenzo.pieral...@arm.com
CC: Ralf Baechle r...@linux-mips.org
CC: Max Filippov jcmvb...@gmail.com
CC: Heiko Stuebner he...@sntech.de
CC: Sylwester Nawrocki s.nawro...@samsung.com 
CC: Tomasz Figa tomasz.f...@gmail.com
CC: Barry Song bao...@kernel.org
CC: Viresh Kumar viresh.li...@gmail.com
CC: Emilio L??pez emi...@elopez.com.ar
CC: Maxime Ripard maxime.rip...@free-electrons.com
CC: Peter De Schrijver pdeschrij...@nvidia.com
CC: Prashant Gaikwad pgaik...@nvidia.com
CC: Stephen Warren swar...@wwwdotorg.org
CC: Thierry Reding thierry.red...@gmail.com
CC: Alexandre Courbot gnu...@gmail.com
CC: Tero Kristo t-kri...@ti.com
CC: Ulf Hansson ulf.hans...@linaro.org
CC: Michal Simek michal.si...@xilinx.com
CC: Philipp Zabel p.za...@pengutronix.de
CC: linux-...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: linux-arm-ker...@lists.infradead.org
CC: linux-arm-...@vger.kernel.org
CC: linux-o...@vger.kernel.org
CC: linux-m...@linux-mips.org
CC: patc...@opensource.wolfsonmicro.com
CC: linux-rockc...@lists.infradead.org
CC: linux-samsung-...@vger.kernel.org
CC: spear-de...@list.st.com
CC: linux-te...@vger.kernel.org
CC: dri-de...@lists.freedesktop.org
CC: linux-media@vger.kernel.org
CC: rtc-li...@googlegroups.com

 Documentation/clk.txt|  4 +-
 arch/arm/mach-imx/clk-busy.c |  2 +-
 arch/arm/mach-imx/clk-cpu.c  | 12 +++-
 arch/arm/mach-imx/clk-fixup-div.c|  2 +-
 arch/arm/mach-imx/clk-pfd.c  | 11 ++--
 arch/arm/mach-imx/clk-pllv2.c|  8 ++-
 arch/arm/mach-imx/clk-pllv3.c| 46 +++--
 arch/arm/mach-msm/clock-pcom.c   |  4 +-
 arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 13 ++--
 arch/arm/mach-omap2/clkt_clksel.c|  6 +-
 arch/arm/mach-omap2/clkt_dpll.c  | 21 +++---
 arch/arm/mach-omap2/clock.h  |  4 +-
 arch/arm/mach-omap2/dpll3xxx.c   | 27 +---
 arch/arm/mach-omap2/dpll44xx.c   | 26 +---
 arch/arm/mach-vexpress/spc.c | 11 +++-
 arch/mips/alchemy/common/clock.c | 13 ++--
 drivers/clk/at91/clk-h32mx.c | 24 ---
 drivers/clk/at91/clk-peripheral.c| 31 +
 drivers/clk/at91/clk-pll.c   | 14 ++--
 drivers/clk/at91/clk-plldiv.c| 22 ---
 drivers/clk/at91/clk-smd.c   | 24 ---
 drivers/clk/at91/clk-usb.c   | 16 +++--
 drivers/clk/clk-axi-clkgen.c |  5 +-
 drivers/clk/clk-cdce706.c| 46 ++---
 drivers/clk/clk-composite.c  | 23 ---
 drivers/clk/clk-divider.c| 16 +++--
 drivers/clk/clk-fixed-factor.c   |  7 +-
 drivers/clk/clk-fractional-divider.c | 16 +++--
 drivers/clk/clk-highbank.c   | 18 +++---
 drivers/clk/clk-si5351.c | 96 ++--
 drivers/clk/clk-si570.c  | 14 ++--
 drivers/clk/clk-u300.c   | 65 ++-
 drivers/clk/clk-vt8500.c | 27 
 drivers/clk/clk-wm831x.c | 11 ++--
 drivers/clk/clk-xgene.c  | 11 ++--
 drivers/clk/clk.c| 14 ++--
 drivers/clk/mmp/clk-frac.c   | 14 ++--
 drivers/clk/mvebu/clk-corediv.c  |  7 +-
 drivers/clk/mvebu/clk-cpu.c  |  9 +--
 drivers/clk/mxs/clk-div.c|  4 +-
 drivers/clk/mxs/clk-frac.c   | 11 ++--
 drivers/clk/mxs/clk-ref.c| 11 ++--
 drivers/clk/qcom/clk-regmap-divider.c|  4 +-
 drivers/clk/rockchip/clk-pll.c   | 13 ++--
 drivers/clk/samsung/clk-pll.c| 13 ++--
 drivers/clk/shmobile/clk-div6.c  |  7 +-
 drivers/clk/shmobile/clk-rcar-gen2.c |  9 +--
 drivers/clk/sirf/clk-common.c| 18

Re: [PATCH 1/2] clk: change clk_ops' -round_rate() prototype

2015-04-19 Thread Boris Brezillon
Hi Heiko,

On Sun, 19 Apr 2015 14:13:04 +0200
Heiko Stübner he...@sntech.de wrote:

 Hi Boris,
 
 Am Freitag, 17. April 2015, 09:29:28 schrieb Boris Brezillon:
  Clock rates are stored in an unsigned long field, but -round_rate()
  (which returns a rounded rate from a requested one) returns a long
  value (errors are reported using negative error codes), which can lead
  to long overflow if the clock rate exceed 2Ghz.
  
  Change -round_rate() prototype to return 0 or an error code, and pass the
  requested rate as a pointer so that it can be adjusted depending on
  hardware capabilities.
  
  Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
  ---
 
 On a rk3288-veyron-pinky with the fix described below:
 Tested-by: Heiko Stuebner he...@sntech.de
 
 
  diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
  index fa5a00e..1462ddc 100644
  --- a/drivers/clk/clk.c
  +++ b/drivers/clk/clk.c
  @@ -1640,8 +1643,10 @@ static struct clk_core *clk_calc_new_rates(struct
  clk_core *clk, parent_hw);
  parent = parent_hw ? parent_hw-core : NULL;
  } else if (clk-ops-round_rate) {
  -   new_rate = clk-ops-round_rate(clk-hw, rate,
  -   best_parent_rate);
  +   if (clk-ops-round_rate(clk-hw, new_rate,
  +best_parent_rate))
  +   return NULL;
  +
  if (new_rate  min_rate || new_rate  max_rate)
  return NULL;
  } else if (!parent || !(clk-flags  CLK_SET_RATE_PARENT)) {
 
 This is using new_rate uninitialized when calling into the round_rate
 callback. Which in turn pushed my PLLs up to 2.2GHz :-)

Indeed, thanks for the fix.

[...]

 
 
 And as I've stumbled onto this recently too, the clock-maintainership has
 expanded to Stephen Boyd and linux-...@vger.kernel.org .

Noted. I'll add Stephen and the new linux-clk ML in the recipient list
next time.

Best Regards,

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/2] clk: change clk_ops' -round_rate() prototype

2015-04-17 Thread Boris Brezillon
Clock rates are stored in an unsigned long field, but -round_rate()
(which returns a rounded rate from a requested one) returns a long
value (errors are reported using negative error codes), which can lead
to long overflow if the clock rate exceed 2Ghz.

Change -round_rate() prototype to return 0 or an error code, and pass the
requested rate as a pointer so that it can be adjusted depending on
hardware capabilities.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
CC: Jonathan Corbet cor...@lwn.net
CC: Shawn Guo shawn@linaro.org
CC: ascha Hauer ker...@pengutronix.de
CC: David Brown dav...@codeaurora.org
CC: Daniel Walker dwal...@fifo99.com
CC: Bryan Huntsman bry...@codeaurora.org
CC: Tony Lindgren t...@atomide.com
CC: Paul Walmsley p...@pwsan.com
CC: Liviu Dudau liviu.du...@arm.com
CC: Sudeep Holla sudeep.ho...@arm.com
CC: Lorenzo Pieralisi lorenzo.pieral...@arm.com
CC: Ralf Baechle r...@linux-mips.org
CC: Max Filippov jcmvb...@gmail.com
CC: Heiko Stuebner he...@sntech.de
CC: Sylwester Nawrocki s.nawro...@samsung.com 
CC: Tomasz Figa tomasz.f...@gmail.com
CC: Barry Song bao...@kernel.org
CC: Viresh Kumar viresh.li...@gmail.com
CC: Emilio López emi...@elopez.com.ar
CC: Maxime Ripard maxime.rip...@free-electrons.com
CC: Peter De Schrijver pdeschrij...@nvidia.com
CC: Prashant Gaikwad pgaik...@nvidia.com
CC: Stephen Warren swar...@wwwdotorg.org
CC: Thierry Reding thierry.red...@gmail.com
CC: Alexandre Courbot gnu...@gmail.com
CC: Tero Kristo t-kri...@ti.com
CC: Ulf Hansson ulf.hans...@linaro.org
CC: Michal Simek michal.si...@xilinx.com
CC: Philipp Zabel p.za...@pengutronix.de
CC: linux-...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: linux-arm-ker...@lists.infradead.org
CC: linux-arm-...@vger.kernel.org
CC: linux-o...@vger.kernel.org
CC: linux-m...@linux-mips.org
CC: patc...@opensource.wolfsonmicro.com
CC: linux-rockc...@lists.infradead.org
CC: linux-samsung-...@vger.kernel.org
CC: spear-de...@list.st.com
CC: linux-te...@vger.kernel.org
CC: dri-de...@lists.freedesktop.org
CC: linux-media@vger.kernel.org
CC: rtc-li...@googlegroups.com

 Documentation/clk.txt|  4 +-
 arch/arm/mach-imx/clk-busy.c |  2 +-
 arch/arm/mach-imx/clk-cpu.c  | 12 +++-
 arch/arm/mach-imx/clk-fixup-div.c|  2 +-
 arch/arm/mach-imx/clk-pfd.c  | 11 ++--
 arch/arm/mach-imx/clk-pllv2.c|  8 ++-
 arch/arm/mach-imx/clk-pllv3.c| 46 +++--
 arch/arm/mach-msm/clock-pcom.c   |  4 +-
 arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 13 ++--
 arch/arm/mach-omap2/clkt_clksel.c|  6 +-
 arch/arm/mach-omap2/clkt_dpll.c  | 21 +++---
 arch/arm/mach-omap2/clock.h  |  4 +-
 arch/arm/mach-omap2/dpll3xxx.c   | 27 +---
 arch/arm/mach-omap2/dpll44xx.c   | 26 +---
 arch/arm/mach-vexpress/spc.c | 11 +++-
 arch/mips/alchemy/common/clock.c | 13 ++--
 drivers/clk/at91/clk-h32mx.c | 24 ---
 drivers/clk/at91/clk-peripheral.c| 31 +
 drivers/clk/at91/clk-pll.c   | 14 ++--
 drivers/clk/at91/clk-plldiv.c| 22 ---
 drivers/clk/at91/clk-smd.c   | 24 ---
 drivers/clk/at91/clk-usb.c   | 34 ++
 drivers/clk/clk-axi-clkgen.c |  5 +-
 drivers/clk/clk-cdce706.c| 46 ++---
 drivers/clk/clk-composite.c  | 23 ---
 drivers/clk/clk-divider.c| 16 +++--
 drivers/clk/clk-fixed-factor.c   |  7 +-
 drivers/clk/clk-fractional-divider.c | 16 +++--
 drivers/clk/clk-highbank.c   | 18 +++---
 drivers/clk/clk-si5351.c | 96 ++--
 drivers/clk/clk-si570.c  | 14 ++--
 drivers/clk/clk-u300.c   | 65 ++-
 drivers/clk/clk-vt8500.c | 27 
 drivers/clk/clk-wm831x.c | 11 ++--
 drivers/clk/clk-xgene.c  | 11 ++--
 drivers/clk/clk.c| 15 +++--
 drivers/clk/mmp/clk-frac.c   | 14 ++--
 drivers/clk/mvebu/clk-corediv.c  |  7 +-
 drivers/clk/mvebu/clk-cpu.c  |  9 +--
 drivers/clk/mxs/clk-div.c|  4 +-
 drivers/clk/mxs/clk-frac.c   | 11 ++--
 drivers/clk/mxs/clk-ref.c| 11 ++--
 drivers/clk/qcom/clk-regmap-divider.c|  4 +-
 drivers/clk/rockchip/clk-pll.c   | 13 ++--
 drivers/clk/samsung/clk-pll.c| 13 ++--
 drivers/clk/shmobile/clk-div6.c  |  7 +-
 drivers/clk/shmobile/clk-rcar-gen2.c |  9 +--
 drivers/clk/sirf/clk-common.c| 18 +++---
 drivers/clk/spear/clk-aux-synth.c| 10 ++-
 drivers/clk/spear/clk-frac-synth.c   | 10 ++-
 drivers/clk/spear/clk

Re: [RESEND PATCH v2] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats

2015-02-02 Thread Boris Brezillon
Hi Mauro,

On Mon, 02 Feb 2015 12:57:55 -0200
Mauro Carvalho Chehab m.che...@samsung.com wrote:

 Em Tue,  6 Jan 2015 12:43:35 +0100
 Boris Brezillon boris.brezil...@free-electrons.com escreveu:
 
  Add RGB444_1X12 and RGB565_1X16 format definitions and update the
  documentation.
  
  Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
  Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
  Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
  ---
  Hi Mauro, Sakari,
  
  This patch has been rejected as 'Not Applicable'.
  Is there anyting wrong in it ?
 
 I was expecting that this patch would be merged together with the
 remaining series, via the DRM tree. That's basically why I gave
 my ack:
   https://lkml.org/lkml/2014/11/3/661
 
 HINT: when a subsystem maintainer gives an ack, that likely means that
 he expects that the patch will be applied via some other tree.

My bad, I thought this would go into the media tree since this single
patch is not exactly related to a DRM feature (except the fact that I
was planning to use it in my DRM driver).
Actually, I didn't send it to the DRM maintainer or dri-devel ML in the
first place :-(.
Can you reconsider taking it in the media tree ?
I you can't, I'll ask Dave (just added him in Cc) to take it into the
DRM tree.

Thanks.

Best Regards,

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/3] Add BGR888_1X24 and GBR888_1X24 media bus formats

2015-02-02 Thread Boris Brezillon
Hi Philip,

On Mon, 02 Feb 2015 16:34:42 +0100
Philipp Zabel p.za...@pengutronix.de wrote:

 Am Montag, den 02.02.2015, 13:24 -0200 schrieb Mauro Carvalho Chehab:
  Em Mon, 02 Feb 2015 16:21:00 +0100
  Philipp Zabel p.za...@pengutronix.de escreveu:
  
   Am Montag, den 02.02.2015, 16:08 +0100 schrieb Hans Verkuil:
On 12/03/2014 02:53 PM, Philipp Zabel wrote:
 This patch adds two more 24-bit RGB formats. BGR888 is more or less 
 common,
 GBR888 is used on the internal connection between the IPU display 
 interface
 and the TVE (VGA DAC) on i.MX53 SoCs.
 
 Signed-off-by: Philipp Zabel p.za...@pengutronix.de
 Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

This three-part patch series doesn't apply. Is it on top of another 
patch
series?
   
   It is on top of Add RGB444_1X12 and RGB565_1X16 media bus formats and
   Add LVDS RGB media bus formats.
   
Anyway, it can't be merged unless it is actually used in a driver.
   
   I'd like to use these in the imx-drm driver, so this is kind of a
   chicken and egg situation. Shall I submit a patch that uses the defines
   to dri-devel and reference it here?
  
  Submit the full patch series with the imx-drm driver, mentioning at the
  V4L2 patch that it will be applied via the DRM tree. We'll review
  and give our ack for it to be applied via DRM tree.
 
 I'll do that, thanks.

Don't know if you plan to keep the dependency on my RGB444 and RGB565
addition, but if you do, I guess you don't want to wait for my
atmel-hlcdc changes, so the best solution is to include my patch in
your series ;-).

Best Regards,

Boris
-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[RESEND PATCH v2] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats

2015-01-06 Thread Boris Brezillon
Add RGB444_1X12 and RGB565_1X16 format definitions and update the
documentation.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
Hi Mauro, Sakari,

This patch has been rejected as 'Not Applicable'.
Is there anyting wrong in it ?

Best Regards,

Boris

 Documentation/DocBook/media/v4l/subdev-formats.xml | 40 ++
 include/uapi/linux/media-bus-format.h  |  4 ++-
 2 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index c5ea868..be57efa 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -192,6 +192,24 @@ see xref linkend=colorspaces /./entry
/row
  /thead
  tbody valign=top
+   row id=MEDIA-BUS-FMT-RGB444-1X12
+ entryMEDIA_BUS_FMT_RGB444_1X12/entry
+ entry0x100d/entry
+ entry/entry
+ dash-ent-20;
+ entryrsubscript3/subscript/entry
+ entryrsubscript2/subscript/entry
+ entryrsubscript1/subscript/entry
+ entryrsubscript0/subscript/entry
+ entrygsubscript3/subscript/entry
+ entrygsubscript2/subscript/entry
+ entrygsubscript1/subscript/entry
+ entrygsubscript0/subscript/entry
+ entrybsubscript3/subscript/entry
+ entrybsubscript2/subscript/entry
+ entrybsubscript1/subscript/entry
+ entrybsubscript0/subscript/entry
+   /row
row id=MEDIA-BUS-FMT-RGB444-2X8-PADHI-BE
  entryMEDIA_BUS_FMT_RGB444_2X8_PADHI_BE/entry
  entry0x1001/entry
@@ -304,6 +322,28 @@ see xref linkend=colorspaces /./entry
  entrygsubscript4/subscript/entry
  entrygsubscript3/subscript/entry
/row
+   row id=MEDIA-BUS-FMT-RGB565-1X16
+ entryMEDIA_BUS_FMT_RGB565_1X16/entry
+ entry0x100d/entry
+ entry/entry
+ dash-ent-16;
+ entryrsubscript4/subscript/entry
+ entryrsubscript3/subscript/entry
+ entryrsubscript2/subscript/entry
+ entryrsubscript1/subscript/entry
+ entryrsubscript0/subscript/entry
+ entrygsubscript5/subscript/entry
+ entrygsubscript4/subscript/entry
+ entrygsubscript3/subscript/entry
+ entrygsubscript2/subscript/entry
+ entrygsubscript1/subscript/entry
+ entrygsubscript0/subscript/entry
+ entrybsubscript4/subscript/entry
+ entrybsubscript3/subscript/entry
+ entrybsubscript2/subscript/entry
+ entrybsubscript1/subscript/entry
+ entrybsubscript0/subscript/entry
+   /row
row id=MEDIA-BUS-FMT-BGR565-2X8-BE
  entryMEDIA_BUS_FMT_BGR565_2X8_BE/entry
  entry0x1005/entry
diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 23b4090..37091c6 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -33,11 +33,13 @@
 
 #define MEDIA_BUS_FMT_FIXED0x0001
 
-/* RGB - next is   0x100e */
+/* RGB - next is   0x1010 */
+#define MEDIA_BUS_FMT_RGB444_1X12  0x100e
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE  0x1003
 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE  0x1004
+#define MEDIA_BUS_FMT_RGB565_1X16  0x100f
 #define MEDIA_BUS_FMT_BGR565_2X8_BE0x1005
 #define MEDIA_BUS_FMT_BGR565_2X8_LE0x1006
 #define MEDIA_BUS_FMT_RGB565_2X8_BE0x1007
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats

2014-12-29 Thread Boris Brezillon
Hello Mauro,

Last week I received a notification informing me that this patch was
Not Applicable.
Could you give more details on why you think this should not go through
the media-tree (or am I misunderstanding the meaning of Not
Applicable) ?

I really need this patch for the atmel HLCDC DRM driver, moreover this
patch from Philip [1] depends on mine.

Regards,

Boris

[1]http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/85952

On Sun, 16 Nov 2014 09:24:38 +0100
Boris Brezillon boris.brezil...@free-electrons.com wrote:

 Add RGB444_1X12 and RGB565_1X16 format definitions and update the
 documentation.
 
 Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
 Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
 ---
 Changes since v1:
 - keep BPP and bits per sample ordering
 
  Documentation/DocBook/media/v4l/subdev-formats.xml | 40 
 ++
  include/uapi/linux/media-bus-format.h  |  4 ++-
  2 files changed, 43 insertions(+), 1 deletion(-)
 
 diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
 b/Documentation/DocBook/media/v4l/subdev-formats.xml
 index 18730b9..0d6f731 100644
 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml
 +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
 @@ -176,6 +176,24 @@
   /row
 /thead
 tbody valign=top
 + row id=MEDIA-BUS-FMT-RGB444-1X12
 +   entryMEDIA_BUS_FMT_RGB444_1X12/entry
 +   entry0x100d/entry
 +   entry/entry
 +   dash-ent-20;
 +   entryrsubscript3/subscript/entry
 +   entryrsubscript2/subscript/entry
 +   entryrsubscript1/subscript/entry
 +   entryrsubscript0/subscript/entry
 +   entrygsubscript3/subscript/entry
 +   entrygsubscript2/subscript/entry
 +   entrygsubscript1/subscript/entry
 +   entrygsubscript0/subscript/entry
 +   entrybsubscript3/subscript/entry
 +   entrybsubscript2/subscript/entry
 +   entrybsubscript1/subscript/entry
 +   entrybsubscript0/subscript/entry
 + /row
   row id=MEDIA-BUS-FMT-RGB444-2X8-PADHI-BE
 entryMEDIA_BUS_FMT_RGB444_2X8_PADHI_BE/entry
 entry0x1001/entry
 @@ -288,6 +306,28 @@
 entrygsubscript4/subscript/entry
 entrygsubscript3/subscript/entry
   /row
 + row id=MEDIA-BUS-FMT-RGB565-1X16
 +   entryMEDIA_BUS_FMT_RGB565_1X16/entry
 +   entry0x100d/entry
 +   entry/entry
 +   dash-ent-16;
 +   entryrsubscript4/subscript/entry
 +   entryrsubscript3/subscript/entry
 +   entryrsubscript2/subscript/entry
 +   entryrsubscript1/subscript/entry
 +   entryrsubscript0/subscript/entry
 +   entrygsubscript5/subscript/entry
 +   entrygsubscript4/subscript/entry
 +   entrygsubscript3/subscript/entry
 +   entrygsubscript2/subscript/entry
 +   entrygsubscript1/subscript/entry
 +   entrygsubscript0/subscript/entry
 +   entrybsubscript4/subscript/entry
 +   entrybsubscript3/subscript/entry
 +   entrybsubscript2/subscript/entry
 +   entrybsubscript1/subscript/entry
 +   entrybsubscript0/subscript/entry
 + /row
   row id=MEDIA-BUS-FMT-BGR565-2X8-BE
 entryMEDIA_BUS_FMT_BGR565_2X8_BE/entry
 entry0x1005/entry
 diff --git a/include/uapi/linux/media-bus-format.h 
 b/include/uapi/linux/media-bus-format.h
 index 23b4090..37091c6 100644
 --- a/include/uapi/linux/media-bus-format.h
 +++ b/include/uapi/linux/media-bus-format.h
 @@ -33,11 +33,13 @@
  
  #define MEDIA_BUS_FMT_FIXED  0x0001
  
 -/* RGB - next is 0x100e */
 +/* RGB - next is 0x1010 */
 +#define MEDIA_BUS_FMT_RGB444_1X120x100e
  #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE0x1001
  #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE0x1002
  #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE0x1003
  #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE0x1004
 +#define MEDIA_BUS_FMT_RGB565_1X160x100f
  #define MEDIA_BUS_FMT_BGR565_2X8_BE  0x1005
  #define MEDIA_BUS_FMT_BGR565_2X8_LE  0x1006
  #define MEDIA_BUS_FMT_RGB565_2X8_BE  0x1007



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/3] drm: add bus_formats and nbus_formats fields to drm_display_info

2014-11-30 Thread Boris Brezillon
Hi Laurent,

On Sat, 29 Nov 2014 00:13:47 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:

 Hi Boris,
 
 Thank you for the patch. I just have two small comments.
 
 On Tuesday 18 November 2014 14:46:18 Boris Brezillon wrote:
  Add bus_formats and nbus_formats fields and
  drm_display_info_set_bus_formats helper function to specify the bus
  formats supported by a given display.
  
  This information can be used by display controller drivers to configure
  the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
  RGB or LVDS busses).
  
  Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
  ---
   drivers/gpu/drm/drm_crtc.c | 30 ++
   include/drm/drm_crtc.h |  7 +++
   2 files changed, 37 insertions(+)
  
  diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
  index e79c8d3..17e3acf 100644
  --- a/drivers/gpu/drm/drm_crtc.c
  +++ b/drivers/gpu/drm/drm_crtc.c
  @@ -763,6 +763,36 @@ static void drm_mode_remove(struct drm_connector
  *connector, drm_mode_destroy(connector-dev, mode);
   }
  
  +/*
  + * drm_display_info_set_bus_formats - set the supported bus formats
  + * @info: display info to store bus formats in
  + * @fmts: array containing the supported bus formats
  + * @nfmts: the number of entries in the fmts array
  + *
  + * Store the suppported bus formats in display info structure.
 
 Could you document that the formats are specified as MEDIA_BUS_FMT_* values ?

Sure, I'll clearly state that.

 
  + */
  +int drm_display_info_set_bus_formats(struct drm_display_info *info, const
  u32 *fmts, + unsigned int num_fmts)
  +{
  +   u32 *formats = NULL;
  +
  +   if (!fmts  num_fmts)
  +   return -EINVAL;
  +
  +   if (fmts  num_fmts) {
  +   formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
  +   if (!formats)
  +   return -ENOMEM;
  +   }
  +
  +   kfree(info-bus_formats);
  +   info-bus_formats = formats;
  +   info-num_bus_formats = num_fmts;
  +
  +   return 0;
  +}
  +EXPORT_SYMBOL(drm_display_info_set_bus_formats);
  +
   /**
* drm_connector_get_cmdline_mode - reads the user's cmdline mode
* @connector: connector to quwery
  diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
  index c40070a..2e0a3e8 100644
  --- a/include/drm/drm_crtc.h
  +++ b/include/drm/drm_crtc.h
  @@ -31,6 +31,7 @@
   #include linux/idr.h
   #include linux/fb.h
   #include linux/hdmi.h
  +#include linux/media-bus-format.h
   #include uapi/drm/drm_mode.h
   #include uapi/drm/drm_fourcc.h
   #include drm/drm_modeset_lock.h
  @@ -130,6 +131,9 @@ struct drm_display_info {
  enum subpixel_order subpixel_order;
  u32 color_formats;
  
  +   const u32 *bus_formats;
  +   int num_bus_formats;
 
 As the number of formats is never negative, I would make it an unsigned int.

Okay, I'll make it an unsigned int.

Regards,

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 0/3] drm: describe display bus format

2014-11-30 Thread Boris Brezillon
Hi Laurent,

On Sat, 29 Nov 2014 00:29:10 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:

 Hi Boris,
 
 On Thursday 27 November 2014 14:37:50 Boris Brezillon wrote:
  On Tue, 18 Nov 2014 14:46:17 +0100 Boris Brezillon wrote:
   Hello,
   
   This series makes use of the MEDIA_BUS_FMT definition to describe how
   the data are transmitted to the display.
   
   This will allow drivers to configure their output display bus according
   to the display capabilities.
   For example some display controllers support DPI (or raw RGB) connectors
   and need to specify which format will be transmitted on the DPI bus
   (RGB444, RGB565, RGB888, ...).
   
   This series also adds a field to the panel_desc struct so that one
   can specify which format is natevely supported by a panel.
  
  Thierry, Laurent, Dave, can you take a look at this patch series: this
  is the last missing dependency to get the atmel-hlcdc DRM driver
  mainlined, and I was expecting to get this driver in 3.19...
 
 I've reviewed the series, it looks globally fine to me. I just had two small 
 comments on patch 1/3.
 

Thanks for the review, I'll address your comments in the next version.

Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 0/3] drm: describe display bus format

2014-11-27 Thread Boris Brezillon
Hi,

On Tue, 18 Nov 2014 14:46:17 +0100
Boris Brezillon boris.brezil...@free-electrons.com wrote:

 Hello,
 
 This series makes use of the MEDIA_BUS_FMT definition to describe how
 the data are transmitted to the display.
 
 This will allow drivers to configure their output display bus according
 to the display capabilities.
 For example some display controllers support DPI (or raw RGB) connectors
 and need to specify which format will be transmitted on the DPI bus
 (RGB444, RGB565, RGB888, ...).
 
 This series also adds a field to the panel_desc struct so that one
 can specify which format is natevely supported by a panel.

Thierry, Laurent, Dave, can you take a look at this patch series: this
is the last missing dependency to get the atmel-hlcdc DRM driver
mainlined, and I was expecting to get this driver in 3.19...

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/9] clk: sunxi: Add prcm mod0 clock driver

2014-11-27 Thread Boris Brezillon
Hi,

On Wed, 26 Nov 2014 22:13:18 +0100
Maxime Ripard maxime.rip...@free-electrons.com wrote:

[...]

 
 I remember someone (Chen-Yu? Boris?) saying that the 1wire clock was
 not really a mod0 clk. From what I could gather from the source code,
 it seems to have a wider m divider, so we could argue that it should
 need a new compatible.

Wasn't me :-).

Regarding the rest of the discussion I miss some context, but here's
what I remember decided us to choose the MFD approach for the PRCM
block:

1) it's embedding several unrelated functional blocks (reset, clk, and
some other things I don't remember).
2) none of the functionalities provided by the PRCM were required in
the early boot stage
3) We wanted to represent the HW blocks as they are really described in
the memory mapping instead of splitting small register chunks over the
DT.

Can someone sum-up the current issue you're trying to solve ?

IMHO, if you really want to split those functionalities over the DT
(some nodes under clks and other under reset controller), then I
suggest to use..
(Maxime, please stop smiling :P)
..

SYSCON

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 1/3] drm: add bus_formats and nbus_formats fields to drm_display_info

2014-11-18 Thread Boris Brezillon
Add bus_formats and nbus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.

This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB or LVDS busses).

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
 drivers/gpu/drm/drm_crtc.c | 30 ++
 include/drm/drm_crtc.h |  7 +++
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79c8d3..17e3acf 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -763,6 +763,36 @@ static void drm_mode_remove(struct drm_connector 
*connector,
drm_mode_destroy(connector-dev, mode);
 }
 
+/*
+ * drm_display_info_set_bus_formats - set the supported bus formats
+ * @info: display info to store bus formats in
+ * @fmts: array containing the supported bus formats
+ * @nfmts: the number of entries in the fmts array
+ *
+ * Store the suppported bus formats in display info structure.
+ */
+int drm_display_info_set_bus_formats(struct drm_display_info *info, const u32 
*fmts,
+unsigned int num_fmts)
+{
+   u32 *formats = NULL;
+
+   if (!fmts  num_fmts)
+   return -EINVAL;
+
+   if (fmts  num_fmts) {
+   formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
+   if (!formats)
+   return -ENOMEM;
+   }
+
+   kfree(info-bus_formats);
+   info-bus_formats = formats;
+   info-num_bus_formats = num_fmts;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_display_info_set_bus_formats);
+
 /**
  * drm_connector_get_cmdline_mode - reads the user's cmdline mode
  * @connector: connector to quwery
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c40070a..2e0a3e8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -31,6 +31,7 @@
 #include linux/idr.h
 #include linux/fb.h
 #include linux/hdmi.h
+#include linux/media-bus-format.h
 #include uapi/drm/drm_mode.h
 #include uapi/drm/drm_fourcc.h
 #include drm/drm_modeset_lock.h
@@ -130,6 +131,9 @@ struct drm_display_info {
enum subpixel_order subpixel_order;
u32 color_formats;
 
+   const u32 *bus_formats;
+   int num_bus_formats;
+
/* Mask of supported hdmi deep color modes */
u8 edid_hdmi_dc_modes;
 
@@ -982,6 +986,9 @@ extern int drm_mode_connector_set_path_property(struct 
drm_connector *connector,
 extern int drm_mode_connector_update_edid_property(struct drm_connector 
*connector,
struct edid *edid);
 
+extern int drm_display_info_set_bus_formats(struct drm_display_info *info,
+   const u32 *fmts, unsigned int 
nfmts);
+
 static inline bool drm_property_type_is(struct drm_property *property,
uint32_t type)
 {
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 0/3] drm: describe display bus format

2014-11-18 Thread Boris Brezillon
Hello,

This series makes use of the MEDIA_BUS_FMT definition to describe how
the data are transmitted to the display.

This will allow drivers to configure their output display bus according
to the display capabilities.
For example some display controllers support DPI (or raw RGB) connectors
and need to specify which format will be transmitted on the DPI bus
(RGB444, RGB565, RGB888, ...).

This series also adds a field to the panel_desc struct so that one
can specify which format is natevely supported by a panel.

Regards,

Boris

Changes since v2:
 - use the MEDIA_BUS_FMT macros

Changes since v1:
 - rename nformats into num_formats
 - declare num_formats as an unsigned int

Boris Brezillon (3):
  drm: add bus_formats and nbus_formats fields to drm_display_info
  drm: panel: simple-panel: add support for bus_format retrieval
  drm: panel: simple-panel: add bus format information for foxlink panel

 drivers/gpu/drm/drm_crtc.c   | 30 ++
 drivers/gpu/drm/panel/panel-simple.c |  6 ++
 include/drm/drm_crtc.h   |  7 +++
 3 files changed, 43 insertions(+)

-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 3/3] drm: panel: simple-panel: add bus format information for foxlink panel

2014-11-18 Thread Boris Brezillon
Foxlink's fl500wvr00-a0t supports RGB888 format.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 66838a5..695f406 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -545,6 +545,7 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
.width = 108,
.height = 65,
},
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };
 
 static const struct drm_display_mode innolux_n116bge_mode = {
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 2/3] drm: panel: simple-panel: add support for bus_format retrieval

2014-11-18 Thread Boris Brezillon
Provide a way to specify panel requirement in terms of supported media bus
format (particularly useful for panels connected to an RGB or LVDS bus).

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
 drivers/gpu/drm/panel/panel-simple.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 23de22f..66838a5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -61,6 +61,8 @@ struct panel_desc {
unsigned int disable;
unsigned int unprepare;
} delay;
+
+   u32 bus_format;
 };
 
 struct panel_simple {
@@ -111,6 +113,9 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
connector-display_info.bpc = panel-desc-bpc;
connector-display_info.width_mm = panel-desc-size.width;
connector-display_info.height_mm = panel-desc-size.height;
+   if (panel-desc-bus_format)
+   drm_display_info_set_bus_formats(connector-display_info,
+panel-desc-bus_format, 1);
 
return num;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats

2014-11-16 Thread Boris Brezillon
On Sat, 15 Nov 2014 16:49:33 +0200
Sakari Ailus sakari.ai...@iki.fi wrote:

 Hi Boris,
 
 Boris Brezillon wrote:
  Hi Sakari,
  
  On Fri, 14 Nov 2014 15:58:31 +0200
  Sakari Ailus sakari.ai...@iki.fi wrote:
  
  Hi Boris,
 
  On Fri, Nov 14, 2014 at 11:36:00AM +0100, Boris Brezillon wrote:
 ...
  diff --git a/include/uapi/linux/media-bus-format.h 
  b/include/uapi/linux/media-bus-format.h
  index 23b4090..cc7b79e 100644
  --- a/include/uapi/linux/media-bus-format.h
  +++ b/include/uapi/linux/media-bus-format.h
  @@ -33,7 +33,7 @@
   
   #define MEDIA_BUS_FMT_FIXED  0x0001
   
  -/* RGB - next is 0x100e */
  +/* RGB - next is 0x1010 */
   #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE0x1001
   #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE0x1002
   #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE0x1003
  @@ -47,6 +47,8 @@
   #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b
   #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c
   #define MEDIA_BUS_FMT_ARGB_1X32  0x100d
  +#define MEDIA_BUS_FMT_RGB444_1X120x100e
  +#define MEDIA_BUS_FMT_RGB565_1X160x100f
 
  I'd arrange these according to BPP and bits per sample, both in the header
  and documentation.
  
  I cannot keep both macro values and BPP/bits per sample in incrementing
  order. Are you sure you prefer to order macros in BPP/bits per sample
  order ?
 
 If you take a look elsewhere in the header, you'll notice that the
 ordering has preferred the BPP value (and other values with semantic
 significance) over the numeric value of the definition. I'd just prefer
 to keep it that way. This is also why the next is comments are there.
 

My bad, I only had a look at RGB formats.
I'll fix that.

Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats

2014-11-16 Thread Boris Brezillon
Add RGB444_1X12 and RGB565_1X16 format definitions and update the
documentation.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
---
Changes since v1:
- keep BPP and bits per sample ordering

 Documentation/DocBook/media/v4l/subdev-formats.xml | 40 ++
 include/uapi/linux/media-bus-format.h  |  4 ++-
 2 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 18730b9..0d6f731 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -176,6 +176,24 @@
/row
  /thead
  tbody valign=top
+   row id=MEDIA-BUS-FMT-RGB444-1X12
+ entryMEDIA_BUS_FMT_RGB444_1X12/entry
+ entry0x100d/entry
+ entry/entry
+ dash-ent-20;
+ entryrsubscript3/subscript/entry
+ entryrsubscript2/subscript/entry
+ entryrsubscript1/subscript/entry
+ entryrsubscript0/subscript/entry
+ entrygsubscript3/subscript/entry
+ entrygsubscript2/subscript/entry
+ entrygsubscript1/subscript/entry
+ entrygsubscript0/subscript/entry
+ entrybsubscript3/subscript/entry
+ entrybsubscript2/subscript/entry
+ entrybsubscript1/subscript/entry
+ entrybsubscript0/subscript/entry
+   /row
row id=MEDIA-BUS-FMT-RGB444-2X8-PADHI-BE
  entryMEDIA_BUS_FMT_RGB444_2X8_PADHI_BE/entry
  entry0x1001/entry
@@ -288,6 +306,28 @@
  entrygsubscript4/subscript/entry
  entrygsubscript3/subscript/entry
/row
+   row id=MEDIA-BUS-FMT-RGB565-1X16
+ entryMEDIA_BUS_FMT_RGB565_1X16/entry
+ entry0x100d/entry
+ entry/entry
+ dash-ent-16;
+ entryrsubscript4/subscript/entry
+ entryrsubscript3/subscript/entry
+ entryrsubscript2/subscript/entry
+ entryrsubscript1/subscript/entry
+ entryrsubscript0/subscript/entry
+ entrygsubscript5/subscript/entry
+ entrygsubscript4/subscript/entry
+ entrygsubscript3/subscript/entry
+ entrygsubscript2/subscript/entry
+ entrygsubscript1/subscript/entry
+ entrygsubscript0/subscript/entry
+ entrybsubscript4/subscript/entry
+ entrybsubscript3/subscript/entry
+ entrybsubscript2/subscript/entry
+ entrybsubscript1/subscript/entry
+ entrybsubscript0/subscript/entry
+   /row
row id=MEDIA-BUS-FMT-BGR565-2X8-BE
  entryMEDIA_BUS_FMT_BGR565_2X8_BE/entry
  entry0x1005/entry
diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 23b4090..37091c6 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -33,11 +33,13 @@
 
 #define MEDIA_BUS_FMT_FIXED0x0001
 
-/* RGB - next is   0x100e */
+/* RGB - next is   0x1010 */
+#define MEDIA_BUS_FMT_RGB444_1X12  0x100e
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE  0x1003
 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE  0x1004
+#define MEDIA_BUS_FMT_RGB565_1X16  0x100f
 #define MEDIA_BUS_FMT_BGR565_2X8_BE0x1005
 #define MEDIA_BUS_FMT_BGR565_2X8_LE0x1006
 #define MEDIA_BUS_FMT_RGB565_2X8_BE0x1007
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats

2014-11-14 Thread Boris Brezillon
Add RGB444_1X12 and RGB565_1X16 format definitions and update the
documentation.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
---
 Documentation/DocBook/media/v4l/subdev-formats.xml | 40 ++
 include/uapi/linux/media-bus-format.h  |  4 ++-
 2 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 18730b9..8c396db 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -563,6 +563,46 @@
  entrybsubscript1/subscript/entry
  entrybsubscript0/subscript/entry
/row
+   row id=MEDIA-BUS-FMT-RGB444-1X12
+ entryMEDIA_BUS_FMT_RGB444_1X12/entry
+ entry0x100d/entry
+ entry/entry
+ dash-ent-20;
+ entryrsubscript3/subscript/entry
+ entryrsubscript2/subscript/entry
+ entryrsubscript1/subscript/entry
+ entryrsubscript0/subscript/entry
+ entrygsubscript3/subscript/entry
+ entrygsubscript2/subscript/entry
+ entrygsubscript1/subscript/entry
+ entrygsubscript0/subscript/entry
+ entrybsubscript3/subscript/entry
+ entrybsubscript2/subscript/entry
+ entrybsubscript1/subscript/entry
+ entrybsubscript0/subscript/entry
+   /row
+   row id=MEDIA-BUS-FMT-RGB565-1X16
+ entryMEDIA_BUS_FMT_RGB565_1X16/entry
+ entry0x100d/entry
+ entry/entry
+ dash-ent-16;
+ entryrsubscript4/subscript/entry
+ entryrsubscript3/subscript/entry
+ entryrsubscript2/subscript/entry
+ entryrsubscript1/subscript/entry
+ entryrsubscript0/subscript/entry
+ entrygsubscript5/subscript/entry
+ entrygsubscript4/subscript/entry
+ entrygsubscript3/subscript/entry
+ entrygsubscript2/subscript/entry
+ entrygsubscript1/subscript/entry
+ entrygsubscript0/subscript/entry
+ entrybsubscript4/subscript/entry
+ entrybsubscript3/subscript/entry
+ entrybsubscript2/subscript/entry
+ entrybsubscript1/subscript/entry
+ entrybsubscript0/subscript/entry
+   /row
  /tbody
/tgroup
   /table
diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 23b4090..cc7b79e 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -33,7 +33,7 @@
 
 #define MEDIA_BUS_FMT_FIXED0x0001
 
-/* RGB - next is   0x100e */
+/* RGB - next is   0x1010 */
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE  0x1003
@@ -47,6 +47,8 @@
 #define MEDIA_BUS_FMT_RGB888_2X12_BE   0x100b
 #define MEDIA_BUS_FMT_RGB888_2X12_LE   0x100c
 #define MEDIA_BUS_FMT_ARGB_1X320x100d
+#define MEDIA_BUS_FMT_RGB444_1X12  0x100e
+#define MEDIA_BUS_FMT_RGB565_1X16  0x100f
 
 /* YUV (including grey) - next is  0x2024 */
 #define MEDIA_BUS_FMT_Y8_1X8   0x2001
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats

2014-11-14 Thread Boris Brezillon
Hi Sakari,

On Fri, 14 Nov 2014 15:58:31 +0200
Sakari Ailus sakari.ai...@iki.fi wrote:

 Hi Boris,
 
 On Fri, Nov 14, 2014 at 11:36:00AM +0100, Boris Brezillon wrote:
  Add RGB444_1X12 and RGB565_1X16 format definitions and update the
  documentation.
  
  Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
  Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
  ---
   Documentation/DocBook/media/v4l/subdev-formats.xml | 40 
  ++
   include/uapi/linux/media-bus-format.h  |  4 ++-
   2 files changed, 43 insertions(+), 1 deletion(-)
  
  diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
  b/Documentation/DocBook/media/v4l/subdev-formats.xml
  index 18730b9..8c396db 100644
  --- a/Documentation/DocBook/media/v4l/subdev-formats.xml
  +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
  @@ -563,6 +563,46 @@
entrybsubscript1/subscript/entry
entrybsubscript0/subscript/entry
  /row
  +   row id=MEDIA-BUS-FMT-RGB444-1X12
  + entryMEDIA_BUS_FMT_RGB444_1X12/entry
  + entry0x100d/entry
  + entry/entry
  + dash-ent-20;
  + entryrsubscript3/subscript/entry
  + entryrsubscript2/subscript/entry
  + entryrsubscript1/subscript/entry
  + entryrsubscript0/subscript/entry
  + entrygsubscript3/subscript/entry
  + entrygsubscript2/subscript/entry
  + entrygsubscript1/subscript/entry
  + entrygsubscript0/subscript/entry
  + entrybsubscript3/subscript/entry
  + entrybsubscript2/subscript/entry
  + entrybsubscript1/subscript/entry
  + entrybsubscript0/subscript/entry
  +   /row
  +   row id=MEDIA-BUS-FMT-RGB565-1X16
  + entryMEDIA_BUS_FMT_RGB565_1X16/entry
  + entry0x100d/entry
  + entry/entry
  + dash-ent-16;
  + entryrsubscript4/subscript/entry
  + entryrsubscript3/subscript/entry
  + entryrsubscript2/subscript/entry
  + entryrsubscript1/subscript/entry
  + entryrsubscript0/subscript/entry
  + entrygsubscript5/subscript/entry
  + entrygsubscript4/subscript/entry
  + entrygsubscript3/subscript/entry
  + entrygsubscript2/subscript/entry
  + entrygsubscript1/subscript/entry
  + entrygsubscript0/subscript/entry
  + entrybsubscript4/subscript/entry
  + entrybsubscript3/subscript/entry
  + entrybsubscript2/subscript/entry
  + entrybsubscript1/subscript/entry
  + entrybsubscript0/subscript/entry
  +   /row
/tbody
  /tgroup
 /table
  diff --git a/include/uapi/linux/media-bus-format.h 
  b/include/uapi/linux/media-bus-format.h
  index 23b4090..cc7b79e 100644
  --- a/include/uapi/linux/media-bus-format.h
  +++ b/include/uapi/linux/media-bus-format.h
  @@ -33,7 +33,7 @@
   
   #define MEDIA_BUS_FMT_FIXED0x0001
   
  -/* RGB - next is   0x100e */
  +/* RGB - next is   0x1010 */
   #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
   #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
   #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE  0x1003
  @@ -47,6 +47,8 @@
   #define MEDIA_BUS_FMT_RGB888_2X12_BE   0x100b
   #define MEDIA_BUS_FMT_RGB888_2X12_LE   0x100c
   #define MEDIA_BUS_FMT_ARGB_1X320x100d
  +#define MEDIA_BUS_FMT_RGB444_1X12  0x100e
  +#define MEDIA_BUS_FMT_RGB565_1X16  0x100f
 
 I'd arrange these according to BPP and bits per sample, both in the header
 and documentation.

I cannot keep both macro values and BPP/bits per sample in incrementing
order. Are you sure you prefer to order macros in BPP/bits per sample
order ?

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v5 10/10] [media] v4l: Forbid usage of V4L2_MBUS_FMT definitions inside the kernel

2014-11-10 Thread Boris Brezillon
On Mon, 10 Nov 2014 12:09:19 +0100
Hans Verkuil hverk...@xs4all.nl wrote:

 On 11/08/2014 04:47 PM, Boris Brezillon wrote:
  Place v4l2_mbus_pixelcode in a #ifndef __KERNEL__ section so that kernel
  users don't have access to these definitions.
  
  We have to keep this definition for user-space users even though they're
  encouraged to move to the new media_bus_format enum.
  
  Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
  Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
  ---
   include/uapi/linux/v4l2-mediabus.h | 45 
  --
   1 file changed, 28 insertions(+), 17 deletions(-)
  
  diff --git a/include/uapi/linux/v4l2-mediabus.h 
  b/include/uapi/linux/v4l2-mediabus.h
  index d712df8..5c9410d 100644
  --- a/include/uapi/linux/v4l2-mediabus.h
  +++ b/include/uapi/linux/v4l2-mediabus.h
  @@ -15,6 +15,33 @@
   #include linux/types.h
   #include linux/videodev2.h
   
  +/**
  + * struct v4l2_mbus_framefmt - frame format on the media bus
  + * @width: frame width
  + * @height:frame height
  + * @code:  data format code (from enum v4l2_mbus_pixelcode)
  + * @field: used interlacing type (from enum v4l2_field)
  + * @colorspace:colorspace of the data (from enum v4l2_colorspace)
  + */
  +struct v4l2_mbus_framefmt {
  +   __u32   width;
  +   __u32   height;
  +   __u32   code;
  +   __u32   field;
  +   __u32   colorspace;
  +   __u32   reserved[7];
  +};
  +
  +#ifndef __KERNEL__
  +/*
  + * enum v4l2_mbus_pixelcode and its definitions are now deprecated, and
  + * MEDIA_BUS_FMT_ definitions (defined in media-bus-format.h) should be
  + * used instead.
  + *
  + * New defines should only be added to media-bus-format.h. The
  + * v4l2_mbus_pixelcode enum is frozen.
  + */
  +
   #define V4L2_MBUS_FROM_MEDIA_BUS_FMT(name) \
  MEDIA_BUS_FMT_ ## name = V4L2_MBUS_FMT_ ## name
 
 Shouldn't this be the other way around?
 
   V4L2_MBUS_FMT_ ## name = MEDIA_BUS_FMT_ ## name

Argh! Absolutely, I'll fix that.

 
 Regards,
 
   Hans
 
   
  @@ -102,22 +129,6 @@ enum v4l2_mbus_pixelcode {
   
  V4L2_MBUS_FROM_MEDIA_BUS_FMT(AHSV_1X32),
   };
  -
  -/**
  - * struct v4l2_mbus_framefmt - frame format on the media bus
  - * @width: frame width
  - * @height:frame height
  - * @code:  data format code (from enum v4l2_mbus_pixelcode)
  - * @field: used interlacing type (from enum v4l2_field)
  - * @colorspace:colorspace of the data (from enum v4l2_colorspace)
  - */
  -struct v4l2_mbus_framefmt {
  -   __u32   width;
  -   __u32   height;
  -   __u32   code;
  -   __u32   field;
  -   __u32   colorspace;
  -   __u32   reserved[7];
  -};
  +#endif /* __KERNEL__ */
   
   #endif
  
 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v6 08/10] staging: media: Make use of MEDIA_BUS_FMT_ definitions

2014-11-10 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Reference new definitions in all media drivers residing in staging.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 drivers/staging/media/davinci_vpfe/dm365_ipipe.c   |  18 ++--
 .../staging/media/davinci_vpfe/dm365_ipipe_hw.c|  26 +++---
 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 100 ++---
 drivers/staging/media/davinci_vpfe/dm365_isif.c|  90 +--
 drivers/staging/media/davinci_vpfe/dm365_resizer.c |  98 ++--
 .../staging/media/davinci_vpfe/vpfe_mc_capture.c   |  18 ++--
 drivers/staging/media/omap4iss/iss_csi2.c  |  62 ++---
 drivers/staging/media/omap4iss/iss_ipipe.c |  16 ++--
 drivers/staging/media/omap4iss/iss_ipipeif.c   |  28 +++---
 drivers/staging/media/omap4iss/iss_resizer.c   |  26 +++---
 drivers/staging/media/omap4iss/iss_video.c |  78 
 drivers/staging/media/omap4iss/iss_video.h |  10 +--
 12 files changed, 285 insertions(+), 285 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index bdc7f00..704fa20 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -37,15 +37,15 @@
 
 /* ipipe input format's */
 static const unsigned int ipipe_input_fmts[] = {
-   V4L2_MBUS_FMT_UYVY8_2X8,
-   V4L2_MBUS_FMT_SGRBG12_1X12,
-   V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
-   V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8,
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_SGRBG12_1X12,
+   MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8,
+   MEDIA_BUS_FMT_SGRBG10_ALAW8_1X8,
 };
 
 /* ipipe output format's */
 static const unsigned int ipipe_output_fmts[] = {
-   V4L2_MBUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_UYVY8_2X8,
 };
 
 static int ipipe_validate_lutdpc_params(struct vpfe_ipipe_lutdpc *lutdpc)
@@ -1457,7 +1457,7 @@ ipipe_try_format(struct vpfe_ipipe_device *ipipe,
 
/* If not found, use SBGGR10 as default */
if (i = ARRAY_SIZE(ipipe_input_fmts))
-   fmt-code = V4L2_MBUS_FMT_SGRBG12_1X12;
+   fmt-code = MEDIA_BUS_FMT_SGRBG12_1X12;
} else if (pad == IPIPE_PAD_SOURCE) {
for (i = 0; i  ARRAY_SIZE(ipipe_output_fmts); i++)
if (fmt-code == ipipe_output_fmts[i])
@@ -1465,7 +1465,7 @@ ipipe_try_format(struct vpfe_ipipe_device *ipipe,
 
/* If not found, use UYVY as default */
if (i = ARRAY_SIZE(ipipe_output_fmts))
-   fmt-code = V4L2_MBUS_FMT_UYVY8_2X8;
+   fmt-code = MEDIA_BUS_FMT_UYVY8_2X8;
}
 
fmt-width = clamp_t(u32, fmt-width, MIN_OUT_HEIGHT, max_out_width);
@@ -1642,7 +1642,7 @@ ipipe_init_formats(struct v4l2_subdev *sd, struct 
v4l2_subdev_fh *fh)
memset(format, 0, sizeof(format));
format.pad = IPIPE_PAD_SINK;
format.which = fh ? V4L2_SUBDEV_FORMAT_TRY : V4L2_SUBDEV_FORMAT_ACTIVE;
-   format.format.code = V4L2_MBUS_FMT_SGRBG12_1X12;
+   format.format.code = MEDIA_BUS_FMT_SGRBG12_1X12;
format.format.width = IPIPE_MAX_OUTPUT_WIDTH_A;
format.format.height = IPIPE_MAX_OUTPUT_HEIGHT_A;
ipipe_set_format(sd, fh, format);
@@ -1650,7 +1650,7 @@ ipipe_init_formats(struct v4l2_subdev *sd, struct 
v4l2_subdev_fh *fh)
memset(format, 0, sizeof(format));
format.pad = IPIPE_PAD_SOURCE;
format.which = fh ? V4L2_SUBDEV_FORMAT_TRY : V4L2_SUBDEV_FORMAT_ACTIVE;
-   format.format.code = V4L2_MBUS_FMT_UYVY8_2X8;
+   format.format.code = MEDIA_BUS_FMT_UYVY8_2X8;
format.format.width = IPIPE_MAX_OUTPUT_WIDTH_A;
format.format.height = IPIPE_MAX_OUTPUT_HEIGHT_A;
ipipe_set_format(sd, fh, format);
diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
index b2daf5e..6461de1 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
@@ -196,12 +196,12 @@ ipipe_setup_resizer(void *__iomem rsz_base, struct 
resizer_params *params)
rsz_set_rsz_regs(rsz_base, RSZ_B, params);
 }
 
-static u32 ipipe_get_color_pat(enum v4l2_mbus_pixelcode pix)
+static u32 ipipe_get_color_pat(u32 pix)
 {
switch (pix) {
-   case V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8:
-   case V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SGRBG12_1X12:
+   case MEDIA_BUS_FMT_SGRBG10_ALAW8_1X8:
+   case MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SGRBG12_1X12:
return

[PATCH v6 07/10] [media] usb: Make use of media_bus_format enum

2014-11-10 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed enum values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Reference new definitions in all usb drivers.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 drivers/media/usb/cx231xx/cx231xx-417.c   | 2 +-
 drivers/media/usb/cx231xx/cx231xx-video.c | 4 ++--
 drivers/media/usb/em28xx/em28xx-camera.c  | 2 +-
 drivers/media/usb/go7007/go7007-v4l2.c| 2 +-
 drivers/media/usb/pvrusb2/pvrusb2-hdw.c   | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/cx231xx/cx231xx-417.c 
b/drivers/media/usb/cx231xx/cx231xx-417.c
index 459bb0e..95653ba 100644
--- a/drivers/media/usb/cx231xx/cx231xx-417.c
+++ b/drivers/media/usb/cx231xx/cx231xx-417.c
@@ -1878,7 +1878,7 @@ static int cx231xx_s_video_encoding(struct 
cx2341x_handler *cxhdl, u32 val)
/* fix videodecoder resolution */
fmt.width = cxhdl-width / (is_mpeg1 ? 2 : 1);
fmt.height = cxhdl-height;
-   fmt.code = V4L2_MBUS_FMT_FIXED;
+   fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(dev-sd_cx25840, video, s_mbus_fmt, fmt);
return 0;
 }
diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c 
b/drivers/media/usb/cx231xx/cx231xx-video.c
index 3b3ada6..989d527 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -967,7 +967,7 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void 
*priv,
dev-height = f-fmt.pix.height;
dev-format = fmt;
 
-   v4l2_fill_mbus_format(mbus_fmt, f-fmt.pix, V4L2_MBUS_FMT_FIXED);
+   v4l2_fill_mbus_format(mbus_fmt, f-fmt.pix, MEDIA_BUS_FMT_FIXED);
call_all(dev, video, s_mbus_fmt, mbus_fmt);
v4l2_fill_pix_format(f-fmt.pix, mbus_fmt);
 
@@ -1012,7 +1012,7 @@ static int vidioc_s_std(struct file *file, void *priv, 
v4l2_std_id norm)
   resolution (since a standard change effects things like the number
   of lines in VACT, etc) */
memset(mbus_fmt, 0, sizeof(mbus_fmt));
-   mbus_fmt.code = V4L2_MBUS_FMT_FIXED;
+   mbus_fmt.code = MEDIA_BUS_FMT_FIXED;
mbus_fmt.width = dev-width;
mbus_fmt.height = dev-height;
call_all(dev, video, s_mbus_fmt, mbus_fmt);
diff --git a/drivers/media/usb/em28xx/em28xx-camera.c 
b/drivers/media/usb/em28xx/em28xx-camera.c
index 6d2ea9a..38cf6c8 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -430,7 +430,7 @@ int em28xx_init_camera(struct em28xx *dev)
break;
}
 
-   fmt.code = V4L2_MBUS_FMT_YUYV8_2X8;
+   fmt.code = MEDIA_BUS_FMT_YUYV8_2X8;
fmt.width = 640;
fmt.height = 480;
v4l2_subdev_call(subdev, video, s_mbus_fmt, fmt);
diff --git a/drivers/media/usb/go7007/go7007-v4l2.c 
b/drivers/media/usb/go7007/go7007-v4l2.c
index ec799b4..d6bf982 100644
--- a/drivers/media/usb/go7007/go7007-v4l2.c
+++ b/drivers/media/usb/go7007/go7007-v4l2.c
@@ -252,7 +252,7 @@ static int set_capture_size(struct go7007 *go, struct 
v4l2_format *fmt, int try)
if (go-board_info-sensor_flags  GO7007_SENSOR_SCALING) {
struct v4l2_mbus_framefmt mbus_fmt;
 
-   mbus_fmt.code = V4L2_MBUS_FMT_FIXED;
+   mbus_fmt.code = MEDIA_BUS_FMT_FIXED;
mbus_fmt.width = fmt ? fmt-fmt.pix.width : width;
mbus_fmt.height = height;
go-encoder_h_halve = 0;
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c 
b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
index 9623b62..2fd9b5e 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
@@ -2966,7 +2966,7 @@ static void pvr2_subdev_update(struct pvr2_hdw *hdw)
memset(fmt, 0, sizeof(fmt));
fmt.width = hdw-res_hor_val;
fmt.height = hdw-res_ver_val;
-   fmt.code = V4L2_MBUS_FMT_FIXED;
+   fmt.code = MEDIA_BUS_FMT_FIXED;
pvr2_trace(PVR2_TRACE_CHIPS, subdev v4l2 set_size(%dx%d),
   fmt.width, fmt.height);
v4l2_device_call_all(hdw-v4l2_dev, 0, video, s_mbus_fmt, 
fmt);
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v6 06/10] [media] platform: Make use of media_bus_format enum

2014-11-10 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Reference new definitions in all platform drivers.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 Documentation/video4linux/soc-camera.txt   |   2 +-
 arch/arm/mach-davinci/board-dm355-evm.c|   2 +-
 arch/arm/mach-davinci/board-dm365-evm.c|   4 +-
 arch/arm/mach-davinci/dm355.c  |   7 +-
 arch/arm/mach-davinci/dm365.c  |   7 +-
 arch/arm/mach-shmobile/board-mackerel.c|   2 +-
 arch/sh/boards/mach-ap325rxa/setup.c   |   2 +-
 drivers/media/platform/blackfin/bfin_capture.c |  14 +--
 drivers/media/platform/davinci/vpbe.c  |   2 +-
 drivers/media/platform/davinci/vpfe_capture.c  |   4 +-
 drivers/media/platform/exynos-gsc/gsc-core.c   |   8 +-
 drivers/media/platform/exynos-gsc/gsc-core.h   |   2 +-
 drivers/media/platform/exynos4-is/fimc-capture.c   |   2 +-
 drivers/media/platform/exynos4-is/fimc-core.c  |  14 +--
 drivers/media/platform/exynos4-is/fimc-core.h  |   4 +-
 drivers/media/platform/exynos4-is/fimc-isp.c   |  16 +--
 drivers/media/platform/exynos4-is/fimc-lite-reg.c  |  26 ++---
 drivers/media/platform/exynos4-is/fimc-lite.c  |  14 +--
 drivers/media/platform/exynos4-is/fimc-reg.c   |  14 +--
 drivers/media/platform/exynos4-is/mipi-csis.c  |  14 +--
 drivers/media/platform/marvell-ccic/mcam-core.c|  21 ++--
 drivers/media/platform/marvell-ccic/mcam-core.h|   2 +-
 drivers/media/platform/omap3isp/ispccdc.c  | 112 ++---
 drivers/media/platform/omap3isp/ispccp2.c  |  18 ++--
 drivers/media/platform/omap3isp/ispcsi2.c  |  42 
 drivers/media/platform/omap3isp/isppreview.c   |  60 ++-
 drivers/media/platform/omap3isp/ispresizer.c   |  19 ++--
 drivers/media/platform/omap3isp/ispvideo.c |  95 +
 drivers/media/platform/omap3isp/ispvideo.h |  10 +-
 drivers/media/platform/s3c-camif/camif-capture.c   |  10 +-
 drivers/media/platform/s3c-camif/camif-regs.c  |   8 +-
 drivers/media/platform/s5p-tv/hdmi_drv.c   |   2 +-
 drivers/media/platform/s5p-tv/sdo_drv.c|   2 +-
 drivers/media/platform/sh_vou.c|   8 +-
 drivers/media/platform/soc_camera/atmel-isi.c  |  22 ++--
 drivers/media/platform/soc_camera/mx2_camera.c |  26 +++--
 drivers/media/platform/soc_camera/mx3_camera.c |   6 +-
 drivers/media/platform/soc_camera/omap1_camera.c   |  36 +++
 drivers/media/platform/soc_camera/pxa_camera.c |  16 +--
 drivers/media/platform/soc_camera/rcar_vin.c   |  14 +--
 .../platform/soc_camera/sh_mobile_ceu_camera.c |  20 ++--
 drivers/media/platform/soc_camera/sh_mobile_csi2.c |  38 +++
 drivers/media/platform/soc_camera/soc_camera.c |   2 +-
 .../platform/soc_camera/soc_camera_platform.c  |   2 +-
 drivers/media/platform/soc_camera/soc_mediabus.c   |  78 +++---
 drivers/media/platform/via-camera.c|   8 +-
 drivers/media/platform/vsp1/vsp1_bru.c |  14 +--
 drivers/media/platform/vsp1/vsp1_hsit.c|  12 +--
 drivers/media/platform/vsp1/vsp1_lif.c |  10 +-
 drivers/media/platform/vsp1/vsp1_lut.c |  14 +--
 drivers/media/platform/vsp1/vsp1_rwpf.c|  10 +-
 drivers/media/platform/vsp1/vsp1_sru.c |  12 +--
 drivers/media/platform/vsp1/vsp1_uds.c |  10 +-
 drivers/media/platform/vsp1/vsp1_video.c   |  42 
 include/media/davinci/vpbe.h   |   2 +-
 include/media/davinci/vpbe_venc.h  |   5 +-
 include/media/exynos-fimc.h|   2 +-
 include/media/soc_camera.h |   2 +-
 include/media/soc_mediabus.h   |   6 +-
 59 files changed, 483 insertions(+), 495 deletions(-)

diff --git a/Documentation/video4linux/soc-camera.txt 
b/Documentation/video4linux/soc-camera.txt
index daa9e2a..84f41cf 100644
--- a/Documentation/video4linux/soc-camera.txt
+++ b/Documentation/video4linux/soc-camera.txt
@@ -151,7 +151,7 @@ they are transferred over a media bus. Soc-camera provides 
support to
 conveniently manage these formats. A table of standard transformations is
 maintained by soc-camera core, which describes, what FOURCC pixel format will
 be obtained, if a media-bus pixel format is stored in memory according to
-certain rules. E.g. if V4L2_MBUS_FMT_YUYV8_2X8 data is sampled with 8 bits per
+certain rules. E.g. if MEDIA_BUS_FMT_YUYV8_2X8 data is sampled with 8 bits per
 sample and stored in memory in the little-endian order with no gaps between
 bytes, data in memory

[PATCH v6 10/10] [media] v4l: Forbid usage of V4L2_MBUS_FMT definitions inside the kernel

2014-11-10 Thread Boris Brezillon
Place v4l2_mbus_pixelcode in a #ifndef __KERNEL__ section so that kernel
users don't have access to these definitions.

We have to keep this definition for user-space users even though they're
encouraged to move to the new media_bus_format enum.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 include/uapi/linux/v4l2-mediabus.h | 45 --
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/include/uapi/linux/v4l2-mediabus.h 
b/include/uapi/linux/v4l2-mediabus.h
index d712df8..5c9410d 100644
--- a/include/uapi/linux/v4l2-mediabus.h
+++ b/include/uapi/linux/v4l2-mediabus.h
@@ -15,6 +15,33 @@
 #include linux/types.h
 #include linux/videodev2.h
 
+/**
+ * struct v4l2_mbus_framefmt - frame format on the media bus
+ * @width: frame width
+ * @height:frame height
+ * @code:  data format code (from enum v4l2_mbus_pixelcode)
+ * @field: used interlacing type (from enum v4l2_field)
+ * @colorspace:colorspace of the data (from enum v4l2_colorspace)
+ */
+struct v4l2_mbus_framefmt {
+   __u32   width;
+   __u32   height;
+   __u32   code;
+   __u32   field;
+   __u32   colorspace;
+   __u32   reserved[7];
+};
+
+#ifndef __KERNEL__
+/*
+ * enum v4l2_mbus_pixelcode and its definitions are now deprecated, and
+ * MEDIA_BUS_FMT_ definitions (defined in media-bus-format.h) should be
+ * used instead.
+ *
+ * New defines should only be added to media-bus-format.h. The
+ * v4l2_mbus_pixelcode enum is frozen.
+ */
+
 #define V4L2_MBUS_FROM_MEDIA_BUS_FMT(name) \
MEDIA_BUS_FMT_ ## name = V4L2_MBUS_FMT_ ## name
 
@@ -102,22 +129,6 @@ enum v4l2_mbus_pixelcode {
 
V4L2_MBUS_FROM_MEDIA_BUS_FMT(AHSV_1X32),
 };
-
-/**
- * struct v4l2_mbus_framefmt - frame format on the media bus
- * @width: frame width
- * @height:frame height
- * @code:  data format code (from enum v4l2_mbus_pixelcode)
- * @field: used interlacing type (from enum v4l2_field)
- * @colorspace:colorspace of the data (from enum v4l2_colorspace)
- */
-struct v4l2_mbus_framefmt {
-   __u32   width;
-   __u32   height;
-   __u32   code;
-   __u32   field;
-   __u32   colorspace;
-   __u32   reserved[7];
-};
+#endif /* __KERNEL__ */
 
 #endif
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v6 02/10] [media] v4l: Update subdev-formats doc with new MEDIA_BUS_FMT values

2014-11-10 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed them with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Update the v4l documentation accordingly.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 Documentation/DocBook/media/v4l/subdev-formats.xml | 308 ++---
 1 file changed, 154 insertions(+), 154 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index b2d5a03..18730b9 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -86,7 +86,7 @@
   green and 5-bit blue values padded on the high bit, transferred as 2 
8-bit
   samples per pixel with the most significant bits (padding, red and half 
of
   the green value) transferred first will be named
-  constantV4L2_MBUS_FMT_RGB555_2X8_PADHI_BE/constant.
+  constantMEDIA_BUS_FMT_RGB555_2X8_PADHI_BE/constant.
   /para
 
   paraThe following tables list existing packed RGB formats./para
@@ -176,8 +176,8 @@
/row
  /thead
  tbody valign=top
-   row id=V4L2-MBUS-FMT-RGB444-2X8-PADHI-BE
- entryV4L2_MBUS_FMT_RGB444_2X8_PADHI_BE/entry
+   row id=MEDIA-BUS-FMT-RGB444-2X8-PADHI-BE
+ entryMEDIA_BUS_FMT_RGB444_2X8_PADHI_BE/entry
  entry0x1001/entry
  entry/entry
  dash-ent-24;
@@ -204,8 +204,8 @@
  entrybsubscript1/subscript/entry
  entrybsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB444-2X8-PADHI-LE
- entryV4L2_MBUS_FMT_RGB444_2X8_PADHI_LE/entry
+   row id=MEDIA-BUS-FMT-RGB444-2X8-PADHI-LE
+ entryMEDIA_BUS_FMT_RGB444_2X8_PADHI_LE/entry
  entry0x1002/entry
  entry/entry
  dash-ent-24;
@@ -232,8 +232,8 @@
  entryrsubscript1/subscript/entry
  entryrsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB555-2X8-PADHI-BE
- entryV4L2_MBUS_FMT_RGB555_2X8_PADHI_BE/entry
+   row id=MEDIA-BUS-FMT-RGB555-2X8-PADHI-BE
+ entryMEDIA_BUS_FMT_RGB555_2X8_PADHI_BE/entry
  entry0x1003/entry
  entry/entry
  dash-ent-24;
@@ -260,8 +260,8 @@
  entrybsubscript1/subscript/entry
  entrybsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB555-2X8-PADHI-LE
- entryV4L2_MBUS_FMT_RGB555_2X8_PADHI_LE/entry
+   row id=MEDIA-BUS-FMT-RGB555-2X8-PADHI-LE
+ entryMEDIA_BUS_FMT_RGB555_2X8_PADHI_LE/entry
  entry0x1004/entry
  entry/entry
  dash-ent-24;
@@ -288,8 +288,8 @@
  entrygsubscript4/subscript/entry
  entrygsubscript3/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-BGR565-2X8-BE
- entryV4L2_MBUS_FMT_BGR565_2X8_BE/entry
+   row id=MEDIA-BUS-FMT-BGR565-2X8-BE
+ entryMEDIA_BUS_FMT_BGR565_2X8_BE/entry
  entry0x1005/entry
  entry/entry
  dash-ent-24;
@@ -316,8 +316,8 @@
  entryrsubscript1/subscript/entry
  entryrsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-BGR565-2X8-LE
- entryV4L2_MBUS_FMT_BGR565_2X8_LE/entry
+   row id=MEDIA-BUS-FMT-BGR565-2X8-LE
+ entryMEDIA_BUS_FMT_BGR565_2X8_LE/entry
  entry0x1006/entry
  entry/entry
  dash-ent-24;
@@ -344,8 +344,8 @@
  entrygsubscript4/subscript/entry
  entrygsubscript3/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB565-2X8-BE
- entryV4L2_MBUS_FMT_RGB565_2X8_BE/entry
+   row id=MEDIA-BUS-FMT-RGB565-2X8-BE
+ entryMEDIA_BUS_FMT_RGB565_2X8_BE/entry
  entry0x1007/entry
  entry/entry
  dash-ent-24;
@@ -372,8 +372,8 @@
  entrybsubscript1/subscript/entry
  entrybsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB565-2X8-LE
- entryV4L2_MBUS_FMT_RGB565_2X8_LE/entry
+   row id=MEDIA-BUS-FMT-RGB565-2X8-LE
+ entryMEDIA_BUS_FMT_RGB565_2X8_LE/entry
  entry0x1008/entry
  entry/entry
  dash-ent-24;
@@ -400,8 +400,8 @@
  entrygsubscript4/subscript/entry
  entrygsubscript3/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB666-1X18
- entryV4L2_MBUS_FMT_RGB666_1X18/entry
+   row id=MEDIA-BUS-FMT-RGB666-1X18
+ entryMEDIA_BUS_FMT_RGB666_1X18/entry
  entry0x1009/entry

[PATCH v6 04/10] [media] i2c: Make use of media_bus_format enum

2014-11-10 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definitions to include/uapi/linux/media-bus-format.h and
prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Replace all references to the old definitions in i2c drivers.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 drivers/media/i2c/adv7170.c   | 16 +++
 drivers/media/i2c/adv7175.c   | 16 +++
 drivers/media/i2c/adv7180.c   |  6 +--
 drivers/media/i2c/adv7183.c   |  6 +--
 drivers/media/i2c/adv7604.c   | 72 +++
 drivers/media/i2c/adv7842.c   |  6 +--
 drivers/media/i2c/ak881x.c|  8 ++--
 drivers/media/i2c/cx25840/cx25840-core.c  |  2 +-
 drivers/media/i2c/m5mols/m5mols_core.c|  6 +--
 drivers/media/i2c/ml86v7667.c |  6 +--
 drivers/media/i2c/mt9m032.c   |  6 +--
 drivers/media/i2c/mt9p031.c   |  8 ++--
 drivers/media/i2c/mt9t001.c   |  8 ++--
 drivers/media/i2c/mt9v011.c   |  6 +--
 drivers/media/i2c/mt9v032.c   | 12 +++---
 drivers/media/i2c/noon010pc30.c   | 12 +++---
 drivers/media/i2c/ov7670.c| 16 +++
 drivers/media/i2c/ov9650.c| 10 ++---
 drivers/media/i2c/s5c73m3/s5c73m3.h   |  6 +--
 drivers/media/i2c/s5k4ecgx.c  |  4 +-
 drivers/media/i2c/s5k5baf.c   | 14 +++---
 drivers/media/i2c/s5k6a3.c|  2 +-
 drivers/media/i2c/s5k6aa.c|  8 ++--
 drivers/media/i2c/saa6752hs.c |  6 +--
 drivers/media/i2c/saa7115.c   |  2 +-
 drivers/media/i2c/saa717x.c   |  2 +-
 drivers/media/i2c/smiapp/smiapp-core.c| 32 +++---
 drivers/media/i2c/soc_camera/imx074.c |  8 ++--
 drivers/media/i2c/soc_camera/mt9m001.c| 14 +++---
 drivers/media/i2c/soc_camera/mt9m111.c| 70 +++---
 drivers/media/i2c/soc_camera/mt9t031.c| 10 ++---
 drivers/media/i2c/soc_camera/mt9t112.c| 22 +-
 drivers/media/i2c/soc_camera/mt9v022.c| 26 +--
 drivers/media/i2c/soc_camera/ov2640.c | 54 +++
 drivers/media/i2c/soc_camera/ov5642.c |  8 ++--
 drivers/media/i2c/soc_camera/ov6650.c | 58 -
 drivers/media/i2c/soc_camera/ov772x.c | 20 -
 drivers/media/i2c/soc_camera/ov9640.c | 40 -
 drivers/media/i2c/soc_camera/ov9740.c | 12 +++---
 drivers/media/i2c/soc_camera/rj54n1cb0c.c | 54 +++
 drivers/media/i2c/soc_camera/tw9910.c | 10 ++---
 drivers/media/i2c/sr030pc30.c | 14 +++---
 drivers/media/i2c/tvp514x.c   | 12 +++---
 drivers/media/i2c/tvp5150.c   |  6 +--
 drivers/media/i2c/tvp7002.c   | 10 ++---
 drivers/media/i2c/vs6624.c| 18 
 46 files changed, 382 insertions(+), 382 deletions(-)

diff --git a/drivers/media/i2c/adv7170.c b/drivers/media/i2c/adv7170.c
index 04bb297..40a1a95 100644
--- a/drivers/media/i2c/adv7170.c
+++ b/drivers/media/i2c/adv7170.c
@@ -63,9 +63,9 @@ static inline struct adv7170 *to_adv7170(struct v4l2_subdev 
*sd)
 
 static char *inputs[] = { pass_through, play_back };
 
-static enum v4l2_mbus_pixelcode adv7170_codes[] = {
-   V4L2_MBUS_FMT_UYVY8_2X8,
-   V4L2_MBUS_FMT_UYVY8_1X16,
+static u32 adv7170_codes[] = {
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_UYVY8_1X16,
 };
 
 /* --- */
@@ -263,7 +263,7 @@ static int adv7170_s_routing(struct v4l2_subdev *sd,
 }
 
 static int adv7170_enum_fmt(struct v4l2_subdev *sd, unsigned int index,
-   enum v4l2_mbus_pixelcode *code)
+   u32 *code)
 {
if (index = ARRAY_SIZE(adv7170_codes))
return -EINVAL;
@@ -278,9 +278,9 @@ static int adv7170_g_fmt(struct v4l2_subdev *sd,
u8 val = adv7170_read(sd, 0x7);
 
if ((val  0x40) == (1  6))
-   mf-code = V4L2_MBUS_FMT_UYVY8_1X16;
+   mf-code = MEDIA_BUS_FMT_UYVY8_1X16;
else
-   mf-code = V4L2_MBUS_FMT_UYVY8_2X8;
+   mf-code = MEDIA_BUS_FMT_UYVY8_2X8;
 
mf-colorspace  = V4L2_COLORSPACE_SMPTE170M;
mf-width   = 0;
@@ -297,11 +297,11 @@ static int adv7170_s_fmt(struct v4l2_subdev *sd,
int ret;
 
switch (mf-code) {
-   case V4L2_MBUS_FMT_UYVY8_2X8:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
val = ~0x40;
break;
 
-   case V4L2_MBUS_FMT_UYVY8_1X16:
+   case MEDIA_BUS_FMT_UYVY8_1X16:
val |= 0x40;
break;
 
diff --git a/drivers/media/i2c/adv7175.c b/drivers/media/i2c/adv7175.c
index b88f3b3..d220af5 100644
--- a/drivers/media

[PATCH v6 09/10] gpu: ipu-v3: Make use of media_bus_format enum

2014-11-10 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed enum values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Reference new definitions in the ipu-v3 driver.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Philipp Zabel p.za...@pengutronix.de
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 drivers/gpu/ipu-v3/ipu-csi.c | 66 ++--
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index d6f56471..752cdd2 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -227,83 +227,83 @@ static int ipu_csi_set_testgen_mclk(struct ipu_csi *csi, 
u32 pixel_clk,
 static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config *cfg, u32 mbus_code)
 {
switch (mbus_code) {
-   case V4L2_MBUS_FMT_BGR565_2X8_BE:
-   case V4L2_MBUS_FMT_BGR565_2X8_LE:
-   case V4L2_MBUS_FMT_RGB565_2X8_BE:
-   case V4L2_MBUS_FMT_RGB565_2X8_LE:
+   case MEDIA_BUS_FMT_BGR565_2X8_BE:
+   case MEDIA_BUS_FMT_BGR565_2X8_LE:
+   case MEDIA_BUS_FMT_RGB565_2X8_BE:
+   case MEDIA_BUS_FMT_RGB565_2X8_LE:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_RGB565;
cfg-mipi_dt = MIPI_DT_RGB565;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE:
-   case V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE:
+   case MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE:
+   case MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_RGB444;
cfg-mipi_dt = MIPI_DT_RGB444;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE:
-   case V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE:
+   case MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE:
+   case MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_RGB555;
cfg-mipi_dt = MIPI_DT_RGB555;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_UYVY8_2X8:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_YUV422_UYVY;
cfg-mipi_dt = MIPI_DT_YUV422;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_YUYV8_2X8:
+   case MEDIA_BUS_FMT_YUYV8_2X8:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_YUV422_YUYV;
cfg-mipi_dt = MIPI_DT_YUV422;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_UYVY8_1X16:
+   case MEDIA_BUS_FMT_UYVY8_1X16:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_YUV422_UYVY;
cfg-mipi_dt = MIPI_DT_YUV422;
cfg-data_width = IPU_CSI_DATA_WIDTH_16;
break;
-   case V4L2_MBUS_FMT_YUYV8_1X16:
+   case MEDIA_BUS_FMT_YUYV8_1X16:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_YUV422_YUYV;
cfg-mipi_dt = MIPI_DT_YUV422;
cfg-data_width = IPU_CSI_DATA_WIDTH_16;
break;
-   case V4L2_MBUS_FMT_SBGGR8_1X8:
-   case V4L2_MBUS_FMT_SGBRG8_1X8:
-   case V4L2_MBUS_FMT_SGRBG8_1X8:
-   case V4L2_MBUS_FMT_SRGGB8_1X8:
+   case MEDIA_BUS_FMT_SBGGR8_1X8:
+   case MEDIA_BUS_FMT_SGBRG8_1X8:
+   case MEDIA_BUS_FMT_SGRBG8_1X8:
+   case MEDIA_BUS_FMT_SRGGB8_1X8:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_BAYER;
cfg-mipi_dt = MIPI_DT_RAW8;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE:
-   case V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE:
-   case V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE:
-   case V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE:
+   case MEDIA_BUS_FMT_SBGGR10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SGBRG10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SRGGB10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE:
+   case MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE:
+   case MEDIA_BUS_FMT_SBGGR10_2X8_PADLO_BE:
+   case MEDIA_BUS_FMT_SBGGR10_2X8_PADLO_LE:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_BAYER;
cfg-mipi_dt = MIPI_DT_RAW10;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_SBGGR10_1X10:
-   case V4L2_MBUS_FMT_SGBRG10_1X10:
-   case V4L2_MBUS_FMT_SGRBG10_1X10:
-   case V4L2_MBUS_FMT_SRGGB10_1X10:
+   case MEDIA_BUS_FMT_SBGGR10_1X10:
+   case

[PATCH v6 00/10] [media] Make mediabus format subsystem neutral

2014-11-10 Thread Boris Brezillon
Hello,

This patch series prepares the use of media bus formats outside of
the V4L2 subsytem (my final goal is to use it in the Atmel HLCDC DRM
driver where I have to configure my DPI/RGB bus according to the
connected display).

The series first defines MEDIA_BUS_FMT_ macros, and then replace all
references to the v4l2_mbus_pixelcode enum and its values within the
kernel.

Best Regards,

Boris

Changes since v5:
- fix V4L2_MBUS_FROM_MEDIA_BUS_FMT macro definition

Changes since v4:
- put deprecated enum v4l2_mbus_pixelcode at the end of v4l2-mediabus.h
  header

Changes since v3:
- add a comment specifying that the v4l2_mbus_pixelcode enum definition
  is frozen

Changes since v2:
- drop media_bus_format enum and replace its values with pre-processor
  macros

Changes since v1:
- drop patches deprecating v4l2_mbus_pixelcode for user-space users
- put V4L2 legacy format definitions into media-bus-format.h

Boris Brezillon (10):
  [media] Move mediabus format definition to a more standard place
  [media] v4l: Update subdev-formats doc with new MEDIA_BUS_FMT values
  [media] Make use of the new media_bus_format definitions
  [media] i2c: Make use of media_bus_format enum
  [media] pci: Make use of MEDIA_BUS_FMT definitions
  [media] platform: Make use of media_bus_format enum
  [media] usb: Make use of media_bus_format enum
  staging: media: Make use of MEDIA_BUS_FMT_ definitions
  gpu: ipu-v3: Make use of media_bus_format enum
  [media] v4l: Forbid usage of V4L2_MBUS_FMT definitions inside the
kernel

 Documentation/DocBook/media/v4l/subdev-formats.xml | 308 ++---
 Documentation/video4linux/soc-camera.txt   |   2 +-
 arch/arm/mach-davinci/board-dm355-evm.c|   2 +-
 arch/arm/mach-davinci/board-dm365-evm.c|   4 +-
 arch/arm/mach-davinci/dm355.c  |   7 +-
 arch/arm/mach-davinci/dm365.c  |   7 +-
 arch/arm/mach-shmobile/board-mackerel.c|   2 +-
 arch/sh/boards/mach-ap325rxa/setup.c   |   2 +-
 drivers/gpu/ipu-v3/ipu-csi.c   |  66 ++---
 drivers/media/i2c/adv7170.c|  16 +-
 drivers/media/i2c/adv7175.c|  16 +-
 drivers/media/i2c/adv7180.c|   6 +-
 drivers/media/i2c/adv7183.c|   6 +-
 drivers/media/i2c/adv7604.c|  72 ++---
 drivers/media/i2c/adv7842.c|   6 +-
 drivers/media/i2c/ak881x.c |   8 +-
 drivers/media/i2c/cx25840/cx25840-core.c   |   2 +-
 drivers/media/i2c/m5mols/m5mols_core.c |   6 +-
 drivers/media/i2c/ml86v7667.c  |   6 +-
 drivers/media/i2c/mt9m032.c|   6 +-
 drivers/media/i2c/mt9p031.c|   8 +-
 drivers/media/i2c/mt9t001.c|   8 +-
 drivers/media/i2c/mt9v011.c|   6 +-
 drivers/media/i2c/mt9v032.c|  12 +-
 drivers/media/i2c/noon010pc30.c|  12 +-
 drivers/media/i2c/ov7670.c |  16 +-
 drivers/media/i2c/ov9650.c |  10 +-
 drivers/media/i2c/s5c73m3/s5c73m3.h|   6 +-
 drivers/media/i2c/s5k4ecgx.c   |   4 +-
 drivers/media/i2c/s5k5baf.c|  14 +-
 drivers/media/i2c/s5k6a3.c |   2 +-
 drivers/media/i2c/s5k6aa.c |   8 +-
 drivers/media/i2c/saa6752hs.c  |   6 +-
 drivers/media/i2c/saa7115.c|   2 +-
 drivers/media/i2c/saa717x.c|   2 +-
 drivers/media/i2c/smiapp/smiapp-core.c |  32 +--
 drivers/media/i2c/soc_camera/imx074.c  |   8 +-
 drivers/media/i2c/soc_camera/mt9m001.c |  14 +-
 drivers/media/i2c/soc_camera/mt9m111.c |  70 ++---
 drivers/media/i2c/soc_camera/mt9t031.c |  10 +-
 drivers/media/i2c/soc_camera/mt9t112.c |  22 +-
 drivers/media/i2c/soc_camera/mt9v022.c |  26 +-
 drivers/media/i2c/soc_camera/ov2640.c  |  54 ++--
 drivers/media/i2c/soc_camera/ov5642.c  |   8 +-
 drivers/media/i2c/soc_camera/ov6650.c  |  58 ++--
 drivers/media/i2c/soc_camera/ov772x.c  |  20 +-
 drivers/media/i2c/soc_camera/ov9640.c  |  40 +--
 drivers/media/i2c/soc_camera/ov9740.c  |  12 +-
 drivers/media/i2c/soc_camera/rj54n1cb0c.c  |  54 ++--
 drivers/media/i2c/soc_camera/tw9910.c  |  10 +-
 drivers/media/i2c/sr030pc30.c  |  14 +-
 drivers/media/i2c/tvp514x.c|  12 +-
 drivers/media/i2c/tvp5150.c|   6 +-
 drivers/media/i2c/tvp7002.c|  10 +-
 drivers/media/i2c/vs6624.c |  18 +-
 drivers/media/pci/cx18/cx18-av-core.c  |   2 +-
 drivers/media

[PATCH v6 05/10] [media] pci: Make use of MEDIA_BUS_FMT definitions

2014-11-10 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Replace all references to the old definitions in pci drivers.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 drivers/media/pci/cx18/cx18-av-core.c   | 2 +-
 drivers/media/pci/cx18/cx18-controls.c  | 2 +-
 drivers/media/pci/cx18/cx18-ioctl.c | 2 +-
 drivers/media/pci/cx23885/cx23885-video.c   | 2 +-
 drivers/media/pci/ivtv/ivtv-controls.c  | 2 +-
 drivers/media/pci/ivtv/ivtv-ioctl.c | 2 +-
 drivers/media/pci/saa7134/saa7134-empress.c | 4 ++--
 7 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/media/pci/cx18/cx18-av-core.c 
b/drivers/media/pci/cx18/cx18-av-core.c
index 2d3afe0..4c6ce21 100644
--- a/drivers/media/pci/cx18/cx18-av-core.c
+++ b/drivers/media/pci/cx18/cx18-av-core.c
@@ -952,7 +952,7 @@ static int cx18_av_s_mbus_fmt(struct v4l2_subdev *sd, 
struct v4l2_mbus_framefmt
int HSC, VSC, Vsrc, Hsrc, filter, Vlines;
int is_50Hz = !(state-std  V4L2_STD_525_60);
 
-   if (fmt-code != V4L2_MBUS_FMT_FIXED)
+   if (fmt-code != MEDIA_BUS_FMT_FIXED)
return -EINVAL;
 
fmt-field = V4L2_FIELD_INTERLACED;
diff --git a/drivers/media/pci/cx18/cx18-controls.c 
b/drivers/media/pci/cx18/cx18-controls.c
index 282a3d2..4aeb7c6 100644
--- a/drivers/media/pci/cx18/cx18-controls.c
+++ b/drivers/media/pci/cx18/cx18-controls.c
@@ -98,7 +98,7 @@ static int cx18_s_video_encoding(struct cx2341x_handler 
*cxhdl, u32 val)
/* fix videodecoder resolution */
fmt.width = cxhdl-width / (is_mpeg1 ? 2 : 1);
fmt.height = cxhdl-height;
-   fmt.code = V4L2_MBUS_FMT_FIXED;
+   fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(cx-sd_av, video, s_mbus_fmt, fmt);
return 0;
 }
diff --git a/drivers/media/pci/cx18/cx18-ioctl.c 
b/drivers/media/pci/cx18/cx18-ioctl.c
index 6f2b590..71963db 100644
--- a/drivers/media/pci/cx18/cx18-ioctl.c
+++ b/drivers/media/pci/cx18/cx18-ioctl.c
@@ -294,7 +294,7 @@ static int cx18_s_fmt_vid_cap(struct file *file, void *fh,
 
mbus_fmt.width = cx-cxhdl.width = w;
mbus_fmt.height = cx-cxhdl.height = h;
-   mbus_fmt.code = V4L2_MBUS_FMT_FIXED;
+   mbus_fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(cx-sd_av, video, s_mbus_fmt, mbus_fmt);
return cx18_g_fmt_vid_cap(file, fh, fmt);
 }
diff --git a/drivers/media/pci/cx23885/cx23885-video.c 
b/drivers/media/pci/cx23885/cx23885-video.c
index 682a4f9..091f5db 100644
--- a/drivers/media/pci/cx23885/cx23885-video.c
+++ b/drivers/media/pci/cx23885/cx23885-video.c
@@ -608,7 +608,7 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void 
*priv,
dev-field  = f-fmt.pix.field;
dprintk(2, %s() width=%d height=%d field=%d\n, __func__,
dev-width, dev-height, dev-field);
-   v4l2_fill_mbus_format(mbus_fmt, f-fmt.pix, V4L2_MBUS_FMT_FIXED);
+   v4l2_fill_mbus_format(mbus_fmt, f-fmt.pix, MEDIA_BUS_FMT_FIXED);
call_all(dev, video, s_mbus_fmt, mbus_fmt);
v4l2_fill_pix_format(f-fmt.pix, mbus_fmt);
/* s_mbus_fmt overwrites f-fmt.pix.field, restore it */
diff --git a/drivers/media/pci/ivtv/ivtv-controls.c 
b/drivers/media/pci/ivtv/ivtv-controls.c
index 2b0ab26..ccf548c 100644
--- a/drivers/media/pci/ivtv/ivtv-controls.c
+++ b/drivers/media/pci/ivtv/ivtv-controls.c
@@ -69,7 +69,7 @@ static int ivtv_s_video_encoding(struct cx2341x_handler 
*cxhdl, u32 val)
/* fix videodecoder resolution */
fmt.width = cxhdl-width / (is_mpeg1 ? 2 : 1);
fmt.height = cxhdl-height;
-   fmt.code = V4L2_MBUS_FMT_FIXED;
+   fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(itv-sd_video, video, s_mbus_fmt, fmt);
return 0;
 }
diff --git a/drivers/media/pci/ivtv/ivtv-ioctl.c 
b/drivers/media/pci/ivtv/ivtv-ioctl.c
index 3e0cb77..4d8ee18 100644
--- a/drivers/media/pci/ivtv/ivtv-ioctl.c
+++ b/drivers/media/pci/ivtv/ivtv-ioctl.c
@@ -595,7 +595,7 @@ static int ivtv_s_fmt_vid_cap(struct file *file, void *fh, 
struct v4l2_format *f
fmt-fmt.pix.width /= 2;
mbus_fmt.width = fmt-fmt.pix.width;
mbus_fmt.height = h;
-   mbus_fmt.code = V4L2_MBUS_FMT_FIXED;
+   mbus_fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(itv-sd_video, video, s_mbus_fmt, mbus_fmt);
return ivtv_g_fmt_vid_cap(file, fh, fmt);
 }
diff --git a/drivers/media/pci/saa7134/saa7134-empress.c 
b/drivers/media/pci/saa7134/saa7134-empress.c
index e4ea85f..8b3bb78 100644
--- a/drivers/media/pci/saa7134/saa7134-empress.c
+++ b/drivers/media/pci/saa7134/saa7134-empress.c
@@ -140,7 +140,7 @@ static int empress_s_fmt_vid_cap(struct file *file, void 
*priv,
struct saa7134_dev *dev = video_drvdata

[PATCH v6 01/10] [media] Move mediabus format definition to a more standard place

2014-11-10 Thread Boris Brezillon
Define MEDIA_BUS_FMT macros (re-using the values defined in the
v4l2_mbus_pixelcode enum) into a separate header file so that they can be
used from the DRM/KMS subsystem without any reference to the V4L2
subsystem.

Then set V4L2_MBUS_FMT definitions to the MEDIA_BUS_FMT values using the
V4L2_MBUS_FROM_MEDIA_BUS_FMT macro.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 include/uapi/linux/Kbuild |   1 +
 include/uapi/linux/media-bus-format.h | 125 +++
 include/uapi/linux/v4l2-mediabus.h| 184 +++---
 3 files changed, 206 insertions(+), 104 deletions(-)
 create mode 100644 include/uapi/linux/media-bus-format.h

diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index b70237e..ed39ac8 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -241,6 +241,7 @@ header-y += map_to_7segment.h
 header-y += matroxfb.h
 header-y += mdio.h
 header-y += media.h
+header-y += media-bus-format.h
 header-y += mei.h
 header-y += memfd.h
 header-y += mempolicy.h
diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
new file mode 100644
index 000..23b4090
--- /dev/null
+++ b/include/uapi/linux/media-bus-format.h
@@ -0,0 +1,125 @@
+/*
+ * Media Bus API header
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __LINUX_MEDIA_BUS_FORMAT_H
+#define __LINUX_MEDIA_BUS_FORMAT_H
+
+/*
+ * These bus formats uniquely identify data formats on the data bus. Format 0
+ * is reserved, MEDIA_BUS_FMT_FIXED shall be used by host-client pairs, where
+ * the data format is fixed. Additionally, 2X8 means that one pixel is
+ * transferred in two 8-bit samples, BE or LE specify in which order those
+ * samples are transferred over the bus: LE means that the least significant
+ * bits are transferred first, BE means that the most significant bits are
+ * transferred first, and PADHI and PADLO define which bits - low or high,
+ * in the incomplete high byte, are filled with padding bits.
+ *
+ * The bus formats are grouped by type, bus_width, bits per component, samples
+ * per pixel and order of subsamples. Numerical values are sorted using generic
+ * numerical sort order (8 thus comes before 10).
+ *
+ * As their value can't change when a new bus format is inserted in the
+ * enumeration, the bus formats are explicitly given a numerical value. The 
next
+ * free values for each category are listed below, update them when inserting
+ * new pixel codes.
+ */
+
+#define MEDIA_BUS_FMT_FIXED0x0001
+
+/* RGB - next is   0x100e */
+#define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
+#define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
+#define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE  0x1003
+#define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE  0x1004
+#define MEDIA_BUS_FMT_BGR565_2X8_BE0x1005
+#define MEDIA_BUS_FMT_BGR565_2X8_LE0x1006
+#define MEDIA_BUS_FMT_RGB565_2X8_BE0x1007
+#define MEDIA_BUS_FMT_RGB565_2X8_LE0x1008
+#define MEDIA_BUS_FMT_RGB666_1X18  0x1009
+#define MEDIA_BUS_FMT_RGB888_1X24  0x100a
+#define MEDIA_BUS_FMT_RGB888_2X12_BE   0x100b
+#define MEDIA_BUS_FMT_RGB888_2X12_LE   0x100c
+#define MEDIA_BUS_FMT_ARGB_1X320x100d
+
+/* YUV (including grey) - next is  0x2024 */
+#define MEDIA_BUS_FMT_Y8_1X8   0x2001
+#define MEDIA_BUS_FMT_UV8_1X8  0x2015
+#define MEDIA_BUS_FMT_UYVY8_1_5X8  0x2002
+#define MEDIA_BUS_FMT_VYUY8_1_5X8  0x2003
+#define MEDIA_BUS_FMT_YUYV8_1_5X8  0x2004
+#define MEDIA_BUS_FMT_YVYU8_1_5X8  0x2005
+#define MEDIA_BUS_FMT_UYVY8_2X80x2006
+#define MEDIA_BUS_FMT_VYUY8_2X80x2007
+#define MEDIA_BUS_FMT_YUYV8_2X80x2008
+#define MEDIA_BUS_FMT_YVYU8_2X80x2009
+#define MEDIA_BUS_FMT_Y10_1X10 0x200a
+#define MEDIA_BUS_FMT_UYVY10_2X10  0x2018
+#define MEDIA_BUS_FMT_VYUY10_2X10  0x2019
+#define MEDIA_BUS_FMT_YUYV10_2X10  0x200b
+#define MEDIA_BUS_FMT_YVYU10_2X10  0x200c
+#define MEDIA_BUS_FMT_Y12_1X12 0x2013
+#define MEDIA_BUS_FMT_UYVY8_1X16   0x200f
+#define MEDIA_BUS_FMT_VYUY8_1X16   0x2010
+#define MEDIA_BUS_FMT_YUYV8_1X16   0x2011
+#define MEDIA_BUS_FMT_YVYU8_1X16   0x2012
+#define MEDIA_BUS_FMT_YDYUYDYV8_1X16   0x2014
+#define MEDIA_BUS_FMT_UYVY10_1X20

[PATCH v6 RESEND 10/10] [media] v4l: Forbid usage of V4L2_MBUS_FMT definitions inside the kernel

2014-11-10 Thread Boris Brezillon
Place v4l2_mbus_pixelcode in a #ifndef __KERNEL__ section so that kernel
users don't have access to these definitions.

We have to keep this definition for user-space users even though they're
encouraged to move to the new media_bus_format enum.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 include/uapi/linux/v4l2-mediabus.h | 45 --
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/include/uapi/linux/v4l2-mediabus.h 
b/include/uapi/linux/v4l2-mediabus.h
index 2618084..b1934a3 100644
--- a/include/uapi/linux/v4l2-mediabus.h
+++ b/include/uapi/linux/v4l2-mediabus.h
@@ -15,6 +15,33 @@
 #include linux/types.h
 #include linux/videodev2.h
 
+/**
+ * struct v4l2_mbus_framefmt - frame format on the media bus
+ * @width: frame width
+ * @height:frame height
+ * @code:  data format code (from enum v4l2_mbus_pixelcode)
+ * @field: used interlacing type (from enum v4l2_field)
+ * @colorspace:colorspace of the data (from enum v4l2_colorspace)
+ */
+struct v4l2_mbus_framefmt {
+   __u32   width;
+   __u32   height;
+   __u32   code;
+   __u32   field;
+   __u32   colorspace;
+   __u32   reserved[7];
+};
+
+#ifndef __KERNEL__
+/*
+ * enum v4l2_mbus_pixelcode and its definitions are now deprecated, and
+ * MEDIA_BUS_FMT_ definitions (defined in media-bus-format.h) should be
+ * used instead.
+ *
+ * New defines should only be added to media-bus-format.h. The
+ * v4l2_mbus_pixelcode enum is frozen.
+ */
+
 #define V4L2_MBUS_FROM_MEDIA_BUS_FMT(name) \
V4L2_MBUS_FMT_ ## name = MEDIA_BUS_FMT_ ## name
 
@@ -102,22 +129,6 @@ enum v4l2_mbus_pixelcode {
 
V4L2_MBUS_FROM_MEDIA_BUS_FMT(AHSV_1X32),
 };
-
-/**
- * struct v4l2_mbus_framefmt - frame format on the media bus
- * @width: frame width
- * @height:frame height
- * @code:  data format code (from enum v4l2_mbus_pixelcode)
- * @field: used interlacing type (from enum v4l2_field)
- * @colorspace:colorspace of the data (from enum v4l2_colorspace)
- */
-struct v4l2_mbus_framefmt {
-   __u32   width;
-   __u32   height;
-   __u32   code;
-   __u32   field;
-   __u32   colorspace;
-   __u32   reserved[7];
-};
+#endif /* __KERNEL__ */
 
 #endif
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v6 RESEND 08/10] staging: media: Make use of MEDIA_BUS_FMT_ definitions

2014-11-10 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Reference new definitions in all media drivers residing in staging.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 drivers/staging/media/davinci_vpfe/dm365_ipipe.c   |  18 ++--
 .../staging/media/davinci_vpfe/dm365_ipipe_hw.c|  26 +++---
 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 100 ++---
 drivers/staging/media/davinci_vpfe/dm365_isif.c|  90 +--
 drivers/staging/media/davinci_vpfe/dm365_resizer.c |  98 ++--
 .../staging/media/davinci_vpfe/vpfe_mc_capture.c   |  18 ++--
 drivers/staging/media/omap4iss/iss_csi2.c  |  62 ++---
 drivers/staging/media/omap4iss/iss_ipipe.c |  16 ++--
 drivers/staging/media/omap4iss/iss_ipipeif.c   |  28 +++---
 drivers/staging/media/omap4iss/iss_resizer.c   |  26 +++---
 drivers/staging/media/omap4iss/iss_video.c |  78 
 drivers/staging/media/omap4iss/iss_video.h |  10 +--
 12 files changed, 285 insertions(+), 285 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index bdc7f00..704fa20 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -37,15 +37,15 @@
 
 /* ipipe input format's */
 static const unsigned int ipipe_input_fmts[] = {
-   V4L2_MBUS_FMT_UYVY8_2X8,
-   V4L2_MBUS_FMT_SGRBG12_1X12,
-   V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
-   V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8,
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_SGRBG12_1X12,
+   MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8,
+   MEDIA_BUS_FMT_SGRBG10_ALAW8_1X8,
 };
 
 /* ipipe output format's */
 static const unsigned int ipipe_output_fmts[] = {
-   V4L2_MBUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_UYVY8_2X8,
 };
 
 static int ipipe_validate_lutdpc_params(struct vpfe_ipipe_lutdpc *lutdpc)
@@ -1457,7 +1457,7 @@ ipipe_try_format(struct vpfe_ipipe_device *ipipe,
 
/* If not found, use SBGGR10 as default */
if (i = ARRAY_SIZE(ipipe_input_fmts))
-   fmt-code = V4L2_MBUS_FMT_SGRBG12_1X12;
+   fmt-code = MEDIA_BUS_FMT_SGRBG12_1X12;
} else if (pad == IPIPE_PAD_SOURCE) {
for (i = 0; i  ARRAY_SIZE(ipipe_output_fmts); i++)
if (fmt-code == ipipe_output_fmts[i])
@@ -1465,7 +1465,7 @@ ipipe_try_format(struct vpfe_ipipe_device *ipipe,
 
/* If not found, use UYVY as default */
if (i = ARRAY_SIZE(ipipe_output_fmts))
-   fmt-code = V4L2_MBUS_FMT_UYVY8_2X8;
+   fmt-code = MEDIA_BUS_FMT_UYVY8_2X8;
}
 
fmt-width = clamp_t(u32, fmt-width, MIN_OUT_HEIGHT, max_out_width);
@@ -1642,7 +1642,7 @@ ipipe_init_formats(struct v4l2_subdev *sd, struct 
v4l2_subdev_fh *fh)
memset(format, 0, sizeof(format));
format.pad = IPIPE_PAD_SINK;
format.which = fh ? V4L2_SUBDEV_FORMAT_TRY : V4L2_SUBDEV_FORMAT_ACTIVE;
-   format.format.code = V4L2_MBUS_FMT_SGRBG12_1X12;
+   format.format.code = MEDIA_BUS_FMT_SGRBG12_1X12;
format.format.width = IPIPE_MAX_OUTPUT_WIDTH_A;
format.format.height = IPIPE_MAX_OUTPUT_HEIGHT_A;
ipipe_set_format(sd, fh, format);
@@ -1650,7 +1650,7 @@ ipipe_init_formats(struct v4l2_subdev *sd, struct 
v4l2_subdev_fh *fh)
memset(format, 0, sizeof(format));
format.pad = IPIPE_PAD_SOURCE;
format.which = fh ? V4L2_SUBDEV_FORMAT_TRY : V4L2_SUBDEV_FORMAT_ACTIVE;
-   format.format.code = V4L2_MBUS_FMT_UYVY8_2X8;
+   format.format.code = MEDIA_BUS_FMT_UYVY8_2X8;
format.format.width = IPIPE_MAX_OUTPUT_WIDTH_A;
format.format.height = IPIPE_MAX_OUTPUT_HEIGHT_A;
ipipe_set_format(sd, fh, format);
diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
index b2daf5e..6461de1 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
@@ -196,12 +196,12 @@ ipipe_setup_resizer(void *__iomem rsz_base, struct 
resizer_params *params)
rsz_set_rsz_regs(rsz_base, RSZ_B, params);
 }
 
-static u32 ipipe_get_color_pat(enum v4l2_mbus_pixelcode pix)
+static u32 ipipe_get_color_pat(u32 pix)
 {
switch (pix) {
-   case V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8:
-   case V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SGRBG12_1X12:
+   case MEDIA_BUS_FMT_SGRBG10_ALAW8_1X8:
+   case MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SGRBG12_1X12:
return

[PATCH v6 RESEND 07/10] [media] usb: Make use of media_bus_format enum

2014-11-10 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed enum values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Reference new definitions in all usb drivers.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 drivers/media/usb/cx231xx/cx231xx-417.c   | 2 +-
 drivers/media/usb/cx231xx/cx231xx-video.c | 4 ++--
 drivers/media/usb/em28xx/em28xx-camera.c  | 2 +-
 drivers/media/usb/go7007/go7007-v4l2.c| 2 +-
 drivers/media/usb/pvrusb2/pvrusb2-hdw.c   | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/cx231xx/cx231xx-417.c 
b/drivers/media/usb/cx231xx/cx231xx-417.c
index 459bb0e..95653ba 100644
--- a/drivers/media/usb/cx231xx/cx231xx-417.c
+++ b/drivers/media/usb/cx231xx/cx231xx-417.c
@@ -1878,7 +1878,7 @@ static int cx231xx_s_video_encoding(struct 
cx2341x_handler *cxhdl, u32 val)
/* fix videodecoder resolution */
fmt.width = cxhdl-width / (is_mpeg1 ? 2 : 1);
fmt.height = cxhdl-height;
-   fmt.code = V4L2_MBUS_FMT_FIXED;
+   fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(dev-sd_cx25840, video, s_mbus_fmt, fmt);
return 0;
 }
diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c 
b/drivers/media/usb/cx231xx/cx231xx-video.c
index 3b3ada6..989d527 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -967,7 +967,7 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void 
*priv,
dev-height = f-fmt.pix.height;
dev-format = fmt;
 
-   v4l2_fill_mbus_format(mbus_fmt, f-fmt.pix, V4L2_MBUS_FMT_FIXED);
+   v4l2_fill_mbus_format(mbus_fmt, f-fmt.pix, MEDIA_BUS_FMT_FIXED);
call_all(dev, video, s_mbus_fmt, mbus_fmt);
v4l2_fill_pix_format(f-fmt.pix, mbus_fmt);
 
@@ -1012,7 +1012,7 @@ static int vidioc_s_std(struct file *file, void *priv, 
v4l2_std_id norm)
   resolution (since a standard change effects things like the number
   of lines in VACT, etc) */
memset(mbus_fmt, 0, sizeof(mbus_fmt));
-   mbus_fmt.code = V4L2_MBUS_FMT_FIXED;
+   mbus_fmt.code = MEDIA_BUS_FMT_FIXED;
mbus_fmt.width = dev-width;
mbus_fmt.height = dev-height;
call_all(dev, video, s_mbus_fmt, mbus_fmt);
diff --git a/drivers/media/usb/em28xx/em28xx-camera.c 
b/drivers/media/usb/em28xx/em28xx-camera.c
index 6d2ea9a..38cf6c8 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -430,7 +430,7 @@ int em28xx_init_camera(struct em28xx *dev)
break;
}
 
-   fmt.code = V4L2_MBUS_FMT_YUYV8_2X8;
+   fmt.code = MEDIA_BUS_FMT_YUYV8_2X8;
fmt.width = 640;
fmt.height = 480;
v4l2_subdev_call(subdev, video, s_mbus_fmt, fmt);
diff --git a/drivers/media/usb/go7007/go7007-v4l2.c 
b/drivers/media/usb/go7007/go7007-v4l2.c
index ec799b4..d6bf982 100644
--- a/drivers/media/usb/go7007/go7007-v4l2.c
+++ b/drivers/media/usb/go7007/go7007-v4l2.c
@@ -252,7 +252,7 @@ static int set_capture_size(struct go7007 *go, struct 
v4l2_format *fmt, int try)
if (go-board_info-sensor_flags  GO7007_SENSOR_SCALING) {
struct v4l2_mbus_framefmt mbus_fmt;
 
-   mbus_fmt.code = V4L2_MBUS_FMT_FIXED;
+   mbus_fmt.code = MEDIA_BUS_FMT_FIXED;
mbus_fmt.width = fmt ? fmt-fmt.pix.width : width;
mbus_fmt.height = height;
go-encoder_h_halve = 0;
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c 
b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
index 9623b62..2fd9b5e 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
@@ -2966,7 +2966,7 @@ static void pvr2_subdev_update(struct pvr2_hdw *hdw)
memset(fmt, 0, sizeof(fmt));
fmt.width = hdw-res_hor_val;
fmt.height = hdw-res_ver_val;
-   fmt.code = V4L2_MBUS_FMT_FIXED;
+   fmt.code = MEDIA_BUS_FMT_FIXED;
pvr2_trace(PVR2_TRACE_CHIPS, subdev v4l2 set_size(%dx%d),
   fmt.width, fmt.height);
v4l2_device_call_all(hdw-v4l2_dev, 0, video, s_mbus_fmt, 
fmt);
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v6 RESEND 06/10] [media] platform: Make use of media_bus_format enum

2014-11-10 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Reference new definitions in all platform drivers.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 Documentation/video4linux/soc-camera.txt   |   2 +-
 arch/arm/mach-davinci/board-dm355-evm.c|   2 +-
 arch/arm/mach-davinci/board-dm365-evm.c|   4 +-
 arch/arm/mach-davinci/dm355.c  |   7 +-
 arch/arm/mach-davinci/dm365.c  |   7 +-
 arch/arm/mach-shmobile/board-mackerel.c|   2 +-
 arch/sh/boards/mach-ap325rxa/setup.c   |   2 +-
 drivers/media/platform/blackfin/bfin_capture.c |  14 +--
 drivers/media/platform/davinci/vpbe.c  |   2 +-
 drivers/media/platform/davinci/vpfe_capture.c  |   4 +-
 drivers/media/platform/exynos-gsc/gsc-core.c   |   8 +-
 drivers/media/platform/exynos-gsc/gsc-core.h   |   2 +-
 drivers/media/platform/exynos4-is/fimc-capture.c   |   2 +-
 drivers/media/platform/exynos4-is/fimc-core.c  |  14 +--
 drivers/media/platform/exynos4-is/fimc-core.h  |   4 +-
 drivers/media/platform/exynos4-is/fimc-isp.c   |  16 +--
 drivers/media/platform/exynos4-is/fimc-lite-reg.c  |  26 ++---
 drivers/media/platform/exynos4-is/fimc-lite.c  |  14 +--
 drivers/media/platform/exynos4-is/fimc-reg.c   |  14 +--
 drivers/media/platform/exynos4-is/mipi-csis.c  |  14 +--
 drivers/media/platform/marvell-ccic/mcam-core.c|  21 ++--
 drivers/media/platform/marvell-ccic/mcam-core.h|   2 +-
 drivers/media/platform/omap3isp/ispccdc.c  | 112 ++---
 drivers/media/platform/omap3isp/ispccp2.c  |  18 ++--
 drivers/media/platform/omap3isp/ispcsi2.c  |  42 
 drivers/media/platform/omap3isp/isppreview.c   |  60 ++-
 drivers/media/platform/omap3isp/ispresizer.c   |  19 ++--
 drivers/media/platform/omap3isp/ispvideo.c |  95 +
 drivers/media/platform/omap3isp/ispvideo.h |  10 +-
 drivers/media/platform/s3c-camif/camif-capture.c   |  10 +-
 drivers/media/platform/s3c-camif/camif-regs.c  |   8 +-
 drivers/media/platform/s5p-tv/hdmi_drv.c   |   2 +-
 drivers/media/platform/s5p-tv/sdo_drv.c|   2 +-
 drivers/media/platform/sh_vou.c|   8 +-
 drivers/media/platform/soc_camera/atmel-isi.c  |  22 ++--
 drivers/media/platform/soc_camera/mx2_camera.c |  26 +++--
 drivers/media/platform/soc_camera/mx3_camera.c |   6 +-
 drivers/media/platform/soc_camera/omap1_camera.c   |  36 +++
 drivers/media/platform/soc_camera/pxa_camera.c |  16 +--
 drivers/media/platform/soc_camera/rcar_vin.c   |  14 +--
 .../platform/soc_camera/sh_mobile_ceu_camera.c |  20 ++--
 drivers/media/platform/soc_camera/sh_mobile_csi2.c |  38 +++
 drivers/media/platform/soc_camera/soc_camera.c |   2 +-
 .../platform/soc_camera/soc_camera_platform.c  |   2 +-
 drivers/media/platform/soc_camera/soc_mediabus.c   |  78 +++---
 drivers/media/platform/via-camera.c|   8 +-
 drivers/media/platform/vsp1/vsp1_bru.c |  14 +--
 drivers/media/platform/vsp1/vsp1_hsit.c|  12 +--
 drivers/media/platform/vsp1/vsp1_lif.c |  10 +-
 drivers/media/platform/vsp1/vsp1_lut.c |  14 +--
 drivers/media/platform/vsp1/vsp1_rwpf.c|  10 +-
 drivers/media/platform/vsp1/vsp1_sru.c |  12 +--
 drivers/media/platform/vsp1/vsp1_uds.c |  10 +-
 drivers/media/platform/vsp1/vsp1_video.c   |  42 
 include/media/davinci/vpbe.h   |   2 +-
 include/media/davinci/vpbe_venc.h  |   5 +-
 include/media/exynos-fimc.h|   2 +-
 include/media/soc_camera.h |   2 +-
 include/media/soc_mediabus.h   |   6 +-
 59 files changed, 483 insertions(+), 495 deletions(-)

diff --git a/Documentation/video4linux/soc-camera.txt 
b/Documentation/video4linux/soc-camera.txt
index daa9e2a..84f41cf 100644
--- a/Documentation/video4linux/soc-camera.txt
+++ b/Documentation/video4linux/soc-camera.txt
@@ -151,7 +151,7 @@ they are transferred over a media bus. Soc-camera provides 
support to
 conveniently manage these formats. A table of standard transformations is
 maintained by soc-camera core, which describes, what FOURCC pixel format will
 be obtained, if a media-bus pixel format is stored in memory according to
-certain rules. E.g. if V4L2_MBUS_FMT_YUYV8_2X8 data is sampled with 8 bits per
+certain rules. E.g. if MEDIA_BUS_FMT_YUYV8_2X8 data is sampled with 8 bits per
 sample and stored in memory in the little-endian order with no gaps between
 bytes, data in memory

[PATCH v6 03/10] [media] Make use of the new media_bus_format definitions

2014-11-10 Thread Boris Brezillon
Replace references to the v4l2_mbus_pixelcode enum with the new
media_bus_format enum in all common headers.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 include/media/v4l2-mediabus.h| 2 +-
 include/media/v4l2-subdev.h  | 2 +-
 include/uapi/linux/v4l2-subdev.h | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 395c4a9..59d7397 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -98,7 +98,7 @@ static inline void v4l2_fill_pix_format(struct 
v4l2_pix_format *pix_fmt,
 
 static inline void v4l2_fill_mbus_format(struct v4l2_mbus_framefmt *mbus_fmt,
   const struct v4l2_pix_format *pix_fmt,
-  enum v4l2_mbus_pixelcode code)
+  u32 code)
 {
mbus_fmt-width = pix_fmt-width;
mbus_fmt-height = pix_fmt-height;
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index d746572..5860292 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -341,7 +341,7 @@ struct v4l2_subdev_video_ops {
int (*query_dv_timings)(struct v4l2_subdev *sd,
struct v4l2_dv_timings *timings);
int (*enum_mbus_fmt)(struct v4l2_subdev *sd, unsigned int index,
-enum v4l2_mbus_pixelcode *code);
+u32 *code);
int (*enum_mbus_fsizes)(struct v4l2_subdev *sd,
 struct v4l2_frmsizeenum *fsize);
int (*g_mbus_fmt)(struct v4l2_subdev *sd,
diff --git a/include/uapi/linux/v4l2-subdev.h b/include/uapi/linux/v4l2-subdev.h
index a619cdd..e0a7e3d 100644
--- a/include/uapi/linux/v4l2-subdev.h
+++ b/include/uapi/linux/v4l2-subdev.h
@@ -68,7 +68,7 @@ struct v4l2_subdev_crop {
  * struct v4l2_subdev_mbus_code_enum - Media bus format enumeration
  * @pad: pad number, as reported by the media API
  * @index: format index during enumeration
- * @code: format code (from enum v4l2_mbus_pixelcode)
+ * @code: format code (MEDIA_BUS_FMT_ definitions)
  */
 struct v4l2_subdev_mbus_code_enum {
__u32 pad;
@@ -81,7 +81,7 @@ struct v4l2_subdev_mbus_code_enum {
  * struct v4l2_subdev_frame_size_enum - Media bus format enumeration
  * @pad: pad number, as reported by the media API
  * @index: format index during enumeration
- * @code: format code (from enum v4l2_mbus_pixelcode)
+ * @code: format code (MEDIA_BUS_FMT_ definitions)
  */
 struct v4l2_subdev_frame_size_enum {
__u32 index;
@@ -109,7 +109,7 @@ struct v4l2_subdev_frame_interval {
  * struct v4l2_subdev_frame_interval_enum - Frame interval enumeration
  * @pad: pad number, as reported by the media API
  * @index: frame interval index during enumeration
- * @code: format code (from enum v4l2_mbus_pixelcode)
+ * @code: format code (MEDIA_BUS_FMT_ definitions)
  * @width: frame width in pixels
  * @height: frame height in pixels
  * @interval: frame interval in seconds
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v6 00/10] [media] Make mediabus format subsystem neutral

2014-11-10 Thread Boris Brezillon
On Mon, 10 Nov 2014 18:21:44 +0100
Boris Brezillon boris.brezil...@free-electrons.com wrote:

 Hello,
 
 This patch series prepares the use of media bus formats outside of
 the V4L2 subsytem (my final goal is to use it in the Atmel HLCDC DRM
 driver where I have to configure my DPI/RGB bus according to the
 connected display).
 
 The series first defines MEDIA_BUS_FMT_ macros, and then replace all
 references to the v4l2_mbus_pixelcode enum and its values within the
 kernel.
 
 Best Regards,
 
 Boris
 
 Changes since v5:
 - fix V4L2_MBUS_FROM_MEDIA_BUS_FMT macro definition

Sorry for the noise, I sent the wrong patch set :-(.

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v6 RESEND 02/10] [media] v4l: Update subdev-formats doc with new MEDIA_BUS_FMT values

2014-11-10 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed them with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Update the v4l documentation accordingly.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 Documentation/DocBook/media/v4l/subdev-formats.xml | 308 ++---
 1 file changed, 154 insertions(+), 154 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index b2d5a03..18730b9 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -86,7 +86,7 @@
   green and 5-bit blue values padded on the high bit, transferred as 2 
8-bit
   samples per pixel with the most significant bits (padding, red and half 
of
   the green value) transferred first will be named
-  constantV4L2_MBUS_FMT_RGB555_2X8_PADHI_BE/constant.
+  constantMEDIA_BUS_FMT_RGB555_2X8_PADHI_BE/constant.
   /para
 
   paraThe following tables list existing packed RGB formats./para
@@ -176,8 +176,8 @@
/row
  /thead
  tbody valign=top
-   row id=V4L2-MBUS-FMT-RGB444-2X8-PADHI-BE
- entryV4L2_MBUS_FMT_RGB444_2X8_PADHI_BE/entry
+   row id=MEDIA-BUS-FMT-RGB444-2X8-PADHI-BE
+ entryMEDIA_BUS_FMT_RGB444_2X8_PADHI_BE/entry
  entry0x1001/entry
  entry/entry
  dash-ent-24;
@@ -204,8 +204,8 @@
  entrybsubscript1/subscript/entry
  entrybsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB444-2X8-PADHI-LE
- entryV4L2_MBUS_FMT_RGB444_2X8_PADHI_LE/entry
+   row id=MEDIA-BUS-FMT-RGB444-2X8-PADHI-LE
+ entryMEDIA_BUS_FMT_RGB444_2X8_PADHI_LE/entry
  entry0x1002/entry
  entry/entry
  dash-ent-24;
@@ -232,8 +232,8 @@
  entryrsubscript1/subscript/entry
  entryrsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB555-2X8-PADHI-BE
- entryV4L2_MBUS_FMT_RGB555_2X8_PADHI_BE/entry
+   row id=MEDIA-BUS-FMT-RGB555-2X8-PADHI-BE
+ entryMEDIA_BUS_FMT_RGB555_2X8_PADHI_BE/entry
  entry0x1003/entry
  entry/entry
  dash-ent-24;
@@ -260,8 +260,8 @@
  entrybsubscript1/subscript/entry
  entrybsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB555-2X8-PADHI-LE
- entryV4L2_MBUS_FMT_RGB555_2X8_PADHI_LE/entry
+   row id=MEDIA-BUS-FMT-RGB555-2X8-PADHI-LE
+ entryMEDIA_BUS_FMT_RGB555_2X8_PADHI_LE/entry
  entry0x1004/entry
  entry/entry
  dash-ent-24;
@@ -288,8 +288,8 @@
  entrygsubscript4/subscript/entry
  entrygsubscript3/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-BGR565-2X8-BE
- entryV4L2_MBUS_FMT_BGR565_2X8_BE/entry
+   row id=MEDIA-BUS-FMT-BGR565-2X8-BE
+ entryMEDIA_BUS_FMT_BGR565_2X8_BE/entry
  entry0x1005/entry
  entry/entry
  dash-ent-24;
@@ -316,8 +316,8 @@
  entryrsubscript1/subscript/entry
  entryrsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-BGR565-2X8-LE
- entryV4L2_MBUS_FMT_BGR565_2X8_LE/entry
+   row id=MEDIA-BUS-FMT-BGR565-2X8-LE
+ entryMEDIA_BUS_FMT_BGR565_2X8_LE/entry
  entry0x1006/entry
  entry/entry
  dash-ent-24;
@@ -344,8 +344,8 @@
  entrygsubscript4/subscript/entry
  entrygsubscript3/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB565-2X8-BE
- entryV4L2_MBUS_FMT_RGB565_2X8_BE/entry
+   row id=MEDIA-BUS-FMT-RGB565-2X8-BE
+ entryMEDIA_BUS_FMT_RGB565_2X8_BE/entry
  entry0x1007/entry
  entry/entry
  dash-ent-24;
@@ -372,8 +372,8 @@
  entrybsubscript1/subscript/entry
  entrybsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB565-2X8-LE
- entryV4L2_MBUS_FMT_RGB565_2X8_LE/entry
+   row id=MEDIA-BUS-FMT-RGB565-2X8-LE
+ entryMEDIA_BUS_FMT_RGB565_2X8_LE/entry
  entry0x1008/entry
  entry/entry
  dash-ent-24;
@@ -400,8 +400,8 @@
  entrygsubscript4/subscript/entry
  entrygsubscript3/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB666-1X18
- entryV4L2_MBUS_FMT_RGB666_1X18/entry
+   row id=MEDIA-BUS-FMT-RGB666-1X18
+ entryMEDIA_BUS_FMT_RGB666_1X18/entry
  entry0x1009/entry

[PATCH v6 RESEND 05/10] [media] pci: Make use of MEDIA_BUS_FMT definitions

2014-11-10 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Replace all references to the old definitions in pci drivers.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 drivers/media/pci/cx18/cx18-av-core.c   | 2 +-
 drivers/media/pci/cx18/cx18-controls.c  | 2 +-
 drivers/media/pci/cx18/cx18-ioctl.c | 2 +-
 drivers/media/pci/cx23885/cx23885-video.c   | 2 +-
 drivers/media/pci/ivtv/ivtv-controls.c  | 2 +-
 drivers/media/pci/ivtv/ivtv-ioctl.c | 2 +-
 drivers/media/pci/saa7134/saa7134-empress.c | 4 ++--
 7 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/media/pci/cx18/cx18-av-core.c 
b/drivers/media/pci/cx18/cx18-av-core.c
index 2d3afe0..4c6ce21 100644
--- a/drivers/media/pci/cx18/cx18-av-core.c
+++ b/drivers/media/pci/cx18/cx18-av-core.c
@@ -952,7 +952,7 @@ static int cx18_av_s_mbus_fmt(struct v4l2_subdev *sd, 
struct v4l2_mbus_framefmt
int HSC, VSC, Vsrc, Hsrc, filter, Vlines;
int is_50Hz = !(state-std  V4L2_STD_525_60);
 
-   if (fmt-code != V4L2_MBUS_FMT_FIXED)
+   if (fmt-code != MEDIA_BUS_FMT_FIXED)
return -EINVAL;
 
fmt-field = V4L2_FIELD_INTERLACED;
diff --git a/drivers/media/pci/cx18/cx18-controls.c 
b/drivers/media/pci/cx18/cx18-controls.c
index 282a3d2..4aeb7c6 100644
--- a/drivers/media/pci/cx18/cx18-controls.c
+++ b/drivers/media/pci/cx18/cx18-controls.c
@@ -98,7 +98,7 @@ static int cx18_s_video_encoding(struct cx2341x_handler 
*cxhdl, u32 val)
/* fix videodecoder resolution */
fmt.width = cxhdl-width / (is_mpeg1 ? 2 : 1);
fmt.height = cxhdl-height;
-   fmt.code = V4L2_MBUS_FMT_FIXED;
+   fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(cx-sd_av, video, s_mbus_fmt, fmt);
return 0;
 }
diff --git a/drivers/media/pci/cx18/cx18-ioctl.c 
b/drivers/media/pci/cx18/cx18-ioctl.c
index 6f2b590..71963db 100644
--- a/drivers/media/pci/cx18/cx18-ioctl.c
+++ b/drivers/media/pci/cx18/cx18-ioctl.c
@@ -294,7 +294,7 @@ static int cx18_s_fmt_vid_cap(struct file *file, void *fh,
 
mbus_fmt.width = cx-cxhdl.width = w;
mbus_fmt.height = cx-cxhdl.height = h;
-   mbus_fmt.code = V4L2_MBUS_FMT_FIXED;
+   mbus_fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(cx-sd_av, video, s_mbus_fmt, mbus_fmt);
return cx18_g_fmt_vid_cap(file, fh, fmt);
 }
diff --git a/drivers/media/pci/cx23885/cx23885-video.c 
b/drivers/media/pci/cx23885/cx23885-video.c
index 682a4f9..091f5db 100644
--- a/drivers/media/pci/cx23885/cx23885-video.c
+++ b/drivers/media/pci/cx23885/cx23885-video.c
@@ -608,7 +608,7 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void 
*priv,
dev-field  = f-fmt.pix.field;
dprintk(2, %s() width=%d height=%d field=%d\n, __func__,
dev-width, dev-height, dev-field);
-   v4l2_fill_mbus_format(mbus_fmt, f-fmt.pix, V4L2_MBUS_FMT_FIXED);
+   v4l2_fill_mbus_format(mbus_fmt, f-fmt.pix, MEDIA_BUS_FMT_FIXED);
call_all(dev, video, s_mbus_fmt, mbus_fmt);
v4l2_fill_pix_format(f-fmt.pix, mbus_fmt);
/* s_mbus_fmt overwrites f-fmt.pix.field, restore it */
diff --git a/drivers/media/pci/ivtv/ivtv-controls.c 
b/drivers/media/pci/ivtv/ivtv-controls.c
index 2b0ab26..ccf548c 100644
--- a/drivers/media/pci/ivtv/ivtv-controls.c
+++ b/drivers/media/pci/ivtv/ivtv-controls.c
@@ -69,7 +69,7 @@ static int ivtv_s_video_encoding(struct cx2341x_handler 
*cxhdl, u32 val)
/* fix videodecoder resolution */
fmt.width = cxhdl-width / (is_mpeg1 ? 2 : 1);
fmt.height = cxhdl-height;
-   fmt.code = V4L2_MBUS_FMT_FIXED;
+   fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(itv-sd_video, video, s_mbus_fmt, fmt);
return 0;
 }
diff --git a/drivers/media/pci/ivtv/ivtv-ioctl.c 
b/drivers/media/pci/ivtv/ivtv-ioctl.c
index 3e0cb77..4d8ee18 100644
--- a/drivers/media/pci/ivtv/ivtv-ioctl.c
+++ b/drivers/media/pci/ivtv/ivtv-ioctl.c
@@ -595,7 +595,7 @@ static int ivtv_s_fmt_vid_cap(struct file *file, void *fh, 
struct v4l2_format *f
fmt-fmt.pix.width /= 2;
mbus_fmt.width = fmt-fmt.pix.width;
mbus_fmt.height = h;
-   mbus_fmt.code = V4L2_MBUS_FMT_FIXED;
+   mbus_fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(itv-sd_video, video, s_mbus_fmt, mbus_fmt);
return ivtv_g_fmt_vid_cap(file, fh, fmt);
 }
diff --git a/drivers/media/pci/saa7134/saa7134-empress.c 
b/drivers/media/pci/saa7134/saa7134-empress.c
index e4ea85f..8b3bb78 100644
--- a/drivers/media/pci/saa7134/saa7134-empress.c
+++ b/drivers/media/pci/saa7134/saa7134-empress.c
@@ -140,7 +140,7 @@ static int empress_s_fmt_vid_cap(struct file *file, void 
*priv,
struct saa7134_dev *dev = video_drvdata

[PATCH v6 RESEND 00/10] [media] Make mediabus format subsystem neutral

2014-11-10 Thread Boris Brezillon
Hello,

This patch series prepares the use of media bus formats outside of
the V4L2 subsytem (my final goal is to use it in the Atmel HLCDC DRM
driver where I have to configure my DPI/RGB bus according to the
connected display).

The series first defines MEDIA_BUS_FMT_ macros, and then replace all
references to the v4l2_mbus_pixelcode enum and its values within the
kernel.

Best Regards,

Boris

Changes since v5:
- fix V4L2_MBUS_FROM_MEDIA_BUS_FMT macro definition

Changes since v4:
- put deprecated enum v4l2_mbus_pixelcode at the end of v4l2-mediabus.h
  header

Changes since v3:
- add a comment specifying that the v4l2_mbus_pixelcode enum definition
  is frozen

Changes since v2:
- drop media_bus_format enum and replace its values with pre-processor
  macros

Changes since v1:
- drop patches deprecating v4l2_mbus_pixelcode for user-space users
- put V4L2 legacy format definitions into media-bus-format.h


Boris Brezillon (10):
  [media] Move mediabus format definition to a more standard place
  [media] v4l: Update subdev-formats doc with new MEDIA_BUS_FMT values
  [media] Make use of the new media_bus_format definitions
  [media] i2c: Make use of media_bus_format enum
  [media] pci: Make use of MEDIA_BUS_FMT definitions
  [media] platform: Make use of media_bus_format enum
  [media] usb: Make use of media_bus_format enum
  staging: media: Make use of MEDIA_BUS_FMT_ definitions
  gpu: ipu-v3: Make use of media_bus_format enum
  [media] v4l: Forbid usage of V4L2_MBUS_FMT definitions inside the
kernel

 Documentation/DocBook/media/v4l/subdev-formats.xml | 308 ++---
 Documentation/video4linux/soc-camera.txt   |   2 +-
 arch/arm/mach-davinci/board-dm355-evm.c|   2 +-
 arch/arm/mach-davinci/board-dm365-evm.c|   4 +-
 arch/arm/mach-davinci/dm355.c  |   7 +-
 arch/arm/mach-davinci/dm365.c  |   7 +-
 arch/arm/mach-shmobile/board-mackerel.c|   2 +-
 arch/sh/boards/mach-ap325rxa/setup.c   |   2 +-
 drivers/gpu/ipu-v3/ipu-csi.c   |  66 ++---
 drivers/media/i2c/adv7170.c|  16 +-
 drivers/media/i2c/adv7175.c|  16 +-
 drivers/media/i2c/adv7180.c|   6 +-
 drivers/media/i2c/adv7183.c|   6 +-
 drivers/media/i2c/adv7604.c|  72 ++---
 drivers/media/i2c/adv7842.c|   6 +-
 drivers/media/i2c/ak881x.c |   8 +-
 drivers/media/i2c/cx25840/cx25840-core.c   |   2 +-
 drivers/media/i2c/m5mols/m5mols_core.c |   6 +-
 drivers/media/i2c/ml86v7667.c  |   6 +-
 drivers/media/i2c/mt9m032.c|   6 +-
 drivers/media/i2c/mt9p031.c|   8 +-
 drivers/media/i2c/mt9t001.c|   8 +-
 drivers/media/i2c/mt9v011.c|   6 +-
 drivers/media/i2c/mt9v032.c|  12 +-
 drivers/media/i2c/noon010pc30.c|  12 +-
 drivers/media/i2c/ov7670.c |  16 +-
 drivers/media/i2c/ov9650.c |  10 +-
 drivers/media/i2c/s5c73m3/s5c73m3.h|   6 +-
 drivers/media/i2c/s5k4ecgx.c   |   4 +-
 drivers/media/i2c/s5k5baf.c|  14 +-
 drivers/media/i2c/s5k6a3.c |   2 +-
 drivers/media/i2c/s5k6aa.c |   8 +-
 drivers/media/i2c/saa6752hs.c  |   6 +-
 drivers/media/i2c/saa7115.c|   2 +-
 drivers/media/i2c/saa717x.c|   2 +-
 drivers/media/i2c/smiapp/smiapp-core.c |  32 +--
 drivers/media/i2c/soc_camera/imx074.c  |   8 +-
 drivers/media/i2c/soc_camera/mt9m001.c |  14 +-
 drivers/media/i2c/soc_camera/mt9m111.c |  70 ++---
 drivers/media/i2c/soc_camera/mt9t031.c |  10 +-
 drivers/media/i2c/soc_camera/mt9t112.c |  22 +-
 drivers/media/i2c/soc_camera/mt9v022.c |  26 +-
 drivers/media/i2c/soc_camera/ov2640.c  |  54 ++--
 drivers/media/i2c/soc_camera/ov5642.c  |   8 +-
 drivers/media/i2c/soc_camera/ov6650.c  |  58 ++--
 drivers/media/i2c/soc_camera/ov772x.c  |  20 +-
 drivers/media/i2c/soc_camera/ov9640.c  |  40 +--
 drivers/media/i2c/soc_camera/ov9740.c  |  12 +-
 drivers/media/i2c/soc_camera/rj54n1cb0c.c  |  54 ++--
 drivers/media/i2c/soc_camera/tw9910.c  |  10 +-
 drivers/media/i2c/sr030pc30.c  |  14 +-
 drivers/media/i2c/tvp514x.c|  12 +-
 drivers/media/i2c/tvp5150.c|   6 +-
 drivers/media/i2c/tvp7002.c|  10 +-
 drivers/media/i2c/vs6624.c |  18 +-
 drivers/media/pci/cx18/cx18-av-core.c  |   2 +-
 drivers/media

[PATCH v6 RESEND 03/10] [media] Make use of the new media_bus_format definitions

2014-11-10 Thread Boris Brezillon
Replace references to the v4l2_mbus_pixelcode enum with the new
media_bus_format enum in all common headers.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 include/media/v4l2-mediabus.h| 2 +-
 include/media/v4l2-subdev.h  | 2 +-
 include/uapi/linux/v4l2-subdev.h | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 395c4a9..59d7397 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -98,7 +98,7 @@ static inline void v4l2_fill_pix_format(struct 
v4l2_pix_format *pix_fmt,
 
 static inline void v4l2_fill_mbus_format(struct v4l2_mbus_framefmt *mbus_fmt,
   const struct v4l2_pix_format *pix_fmt,
-  enum v4l2_mbus_pixelcode code)
+  u32 code)
 {
mbus_fmt-width = pix_fmt-width;
mbus_fmt-height = pix_fmt-height;
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index d746572..5860292 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -341,7 +341,7 @@ struct v4l2_subdev_video_ops {
int (*query_dv_timings)(struct v4l2_subdev *sd,
struct v4l2_dv_timings *timings);
int (*enum_mbus_fmt)(struct v4l2_subdev *sd, unsigned int index,
-enum v4l2_mbus_pixelcode *code);
+u32 *code);
int (*enum_mbus_fsizes)(struct v4l2_subdev *sd,
 struct v4l2_frmsizeenum *fsize);
int (*g_mbus_fmt)(struct v4l2_subdev *sd,
diff --git a/include/uapi/linux/v4l2-subdev.h b/include/uapi/linux/v4l2-subdev.h
index a619cdd..e0a7e3d 100644
--- a/include/uapi/linux/v4l2-subdev.h
+++ b/include/uapi/linux/v4l2-subdev.h
@@ -68,7 +68,7 @@ struct v4l2_subdev_crop {
  * struct v4l2_subdev_mbus_code_enum - Media bus format enumeration
  * @pad: pad number, as reported by the media API
  * @index: format index during enumeration
- * @code: format code (from enum v4l2_mbus_pixelcode)
+ * @code: format code (MEDIA_BUS_FMT_ definitions)
  */
 struct v4l2_subdev_mbus_code_enum {
__u32 pad;
@@ -81,7 +81,7 @@ struct v4l2_subdev_mbus_code_enum {
  * struct v4l2_subdev_frame_size_enum - Media bus format enumeration
  * @pad: pad number, as reported by the media API
  * @index: format index during enumeration
- * @code: format code (from enum v4l2_mbus_pixelcode)
+ * @code: format code (MEDIA_BUS_FMT_ definitions)
  */
 struct v4l2_subdev_frame_size_enum {
__u32 index;
@@ -109,7 +109,7 @@ struct v4l2_subdev_frame_interval {
  * struct v4l2_subdev_frame_interval_enum - Frame interval enumeration
  * @pad: pad number, as reported by the media API
  * @index: frame interval index during enumeration
- * @code: format code (from enum v4l2_mbus_pixelcode)
+ * @code: format code (MEDIA_BUS_FMT_ definitions)
  * @width: frame width in pixels
  * @height: frame height in pixels
  * @interval: frame interval in seconds
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v6 RESEND 01/10] [media] Move mediabus format definition to a more standard place

2014-11-10 Thread Boris Brezillon
Define MEDIA_BUS_FMT macros (re-using the values defined in the
v4l2_mbus_pixelcode enum) into a separate header file so that they can be
used from the DRM/KMS subsystem without any reference to the V4L2
subsystem.

Then set V4L2_MBUS_FMT definitions to the MEDIA_BUS_FMT values using the
V4L2_MBUS_FROM_MEDIA_BUS_FMT macro.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 include/uapi/linux/Kbuild |   1 +
 include/uapi/linux/media-bus-format.h | 125 +++
 include/uapi/linux/v4l2-mediabus.h| 184 +++---
 3 files changed, 206 insertions(+), 104 deletions(-)
 create mode 100644 include/uapi/linux/media-bus-format.h

diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index b70237e..ed39ac8 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -241,6 +241,7 @@ header-y += map_to_7segment.h
 header-y += matroxfb.h
 header-y += mdio.h
 header-y += media.h
+header-y += media-bus-format.h
 header-y += mei.h
 header-y += memfd.h
 header-y += mempolicy.h
diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
new file mode 100644
index 000..23b4090
--- /dev/null
+++ b/include/uapi/linux/media-bus-format.h
@@ -0,0 +1,125 @@
+/*
+ * Media Bus API header
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __LINUX_MEDIA_BUS_FORMAT_H
+#define __LINUX_MEDIA_BUS_FORMAT_H
+
+/*
+ * These bus formats uniquely identify data formats on the data bus. Format 0
+ * is reserved, MEDIA_BUS_FMT_FIXED shall be used by host-client pairs, where
+ * the data format is fixed. Additionally, 2X8 means that one pixel is
+ * transferred in two 8-bit samples, BE or LE specify in which order those
+ * samples are transferred over the bus: LE means that the least significant
+ * bits are transferred first, BE means that the most significant bits are
+ * transferred first, and PADHI and PADLO define which bits - low or high,
+ * in the incomplete high byte, are filled with padding bits.
+ *
+ * The bus formats are grouped by type, bus_width, bits per component, samples
+ * per pixel and order of subsamples. Numerical values are sorted using generic
+ * numerical sort order (8 thus comes before 10).
+ *
+ * As their value can't change when a new bus format is inserted in the
+ * enumeration, the bus formats are explicitly given a numerical value. The 
next
+ * free values for each category are listed below, update them when inserting
+ * new pixel codes.
+ */
+
+#define MEDIA_BUS_FMT_FIXED0x0001
+
+/* RGB - next is   0x100e */
+#define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
+#define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
+#define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE  0x1003
+#define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE  0x1004
+#define MEDIA_BUS_FMT_BGR565_2X8_BE0x1005
+#define MEDIA_BUS_FMT_BGR565_2X8_LE0x1006
+#define MEDIA_BUS_FMT_RGB565_2X8_BE0x1007
+#define MEDIA_BUS_FMT_RGB565_2X8_LE0x1008
+#define MEDIA_BUS_FMT_RGB666_1X18  0x1009
+#define MEDIA_BUS_FMT_RGB888_1X24  0x100a
+#define MEDIA_BUS_FMT_RGB888_2X12_BE   0x100b
+#define MEDIA_BUS_FMT_RGB888_2X12_LE   0x100c
+#define MEDIA_BUS_FMT_ARGB_1X320x100d
+
+/* YUV (including grey) - next is  0x2024 */
+#define MEDIA_BUS_FMT_Y8_1X8   0x2001
+#define MEDIA_BUS_FMT_UV8_1X8  0x2015
+#define MEDIA_BUS_FMT_UYVY8_1_5X8  0x2002
+#define MEDIA_BUS_FMT_VYUY8_1_5X8  0x2003
+#define MEDIA_BUS_FMT_YUYV8_1_5X8  0x2004
+#define MEDIA_BUS_FMT_YVYU8_1_5X8  0x2005
+#define MEDIA_BUS_FMT_UYVY8_2X80x2006
+#define MEDIA_BUS_FMT_VYUY8_2X80x2007
+#define MEDIA_BUS_FMT_YUYV8_2X80x2008
+#define MEDIA_BUS_FMT_YVYU8_2X80x2009
+#define MEDIA_BUS_FMT_Y10_1X10 0x200a
+#define MEDIA_BUS_FMT_UYVY10_2X10  0x2018
+#define MEDIA_BUS_FMT_VYUY10_2X10  0x2019
+#define MEDIA_BUS_FMT_YUYV10_2X10  0x200b
+#define MEDIA_BUS_FMT_YVYU10_2X10  0x200c
+#define MEDIA_BUS_FMT_Y12_1X12 0x2013
+#define MEDIA_BUS_FMT_UYVY8_1X16   0x200f
+#define MEDIA_BUS_FMT_VYUY8_1X16   0x2010
+#define MEDIA_BUS_FMT_YUYV8_1X16   0x2011
+#define MEDIA_BUS_FMT_YVYU8_1X16   0x2012
+#define MEDIA_BUS_FMT_YDYUYDYV8_1X16   0x2014
+#define MEDIA_BUS_FMT_UYVY10_1X20

[PATCH v6 RESEND 04/10] [media] i2c: Make use of media_bus_format enum

2014-11-10 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definitions to include/uapi/linux/media-bus-format.h and
prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Replace all references to the old definitions in i2c drivers.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 drivers/media/i2c/adv7170.c   | 16 +++
 drivers/media/i2c/adv7175.c   | 16 +++
 drivers/media/i2c/adv7180.c   |  6 +--
 drivers/media/i2c/adv7183.c   |  6 +--
 drivers/media/i2c/adv7604.c   | 72 +++
 drivers/media/i2c/adv7842.c   |  6 +--
 drivers/media/i2c/ak881x.c|  8 ++--
 drivers/media/i2c/cx25840/cx25840-core.c  |  2 +-
 drivers/media/i2c/m5mols/m5mols_core.c|  6 +--
 drivers/media/i2c/ml86v7667.c |  6 +--
 drivers/media/i2c/mt9m032.c   |  6 +--
 drivers/media/i2c/mt9p031.c   |  8 ++--
 drivers/media/i2c/mt9t001.c   |  8 ++--
 drivers/media/i2c/mt9v011.c   |  6 +--
 drivers/media/i2c/mt9v032.c   | 12 +++---
 drivers/media/i2c/noon010pc30.c   | 12 +++---
 drivers/media/i2c/ov7670.c| 16 +++
 drivers/media/i2c/ov9650.c| 10 ++---
 drivers/media/i2c/s5c73m3/s5c73m3.h   |  6 +--
 drivers/media/i2c/s5k4ecgx.c  |  4 +-
 drivers/media/i2c/s5k5baf.c   | 14 +++---
 drivers/media/i2c/s5k6a3.c|  2 +-
 drivers/media/i2c/s5k6aa.c|  8 ++--
 drivers/media/i2c/saa6752hs.c |  6 +--
 drivers/media/i2c/saa7115.c   |  2 +-
 drivers/media/i2c/saa717x.c   |  2 +-
 drivers/media/i2c/smiapp/smiapp-core.c| 32 +++---
 drivers/media/i2c/soc_camera/imx074.c |  8 ++--
 drivers/media/i2c/soc_camera/mt9m001.c| 14 +++---
 drivers/media/i2c/soc_camera/mt9m111.c| 70 +++---
 drivers/media/i2c/soc_camera/mt9t031.c| 10 ++---
 drivers/media/i2c/soc_camera/mt9t112.c| 22 +-
 drivers/media/i2c/soc_camera/mt9v022.c| 26 +--
 drivers/media/i2c/soc_camera/ov2640.c | 54 +++
 drivers/media/i2c/soc_camera/ov5642.c |  8 ++--
 drivers/media/i2c/soc_camera/ov6650.c | 58 -
 drivers/media/i2c/soc_camera/ov772x.c | 20 -
 drivers/media/i2c/soc_camera/ov9640.c | 40 -
 drivers/media/i2c/soc_camera/ov9740.c | 12 +++---
 drivers/media/i2c/soc_camera/rj54n1cb0c.c | 54 +++
 drivers/media/i2c/soc_camera/tw9910.c | 10 ++---
 drivers/media/i2c/sr030pc30.c | 14 +++---
 drivers/media/i2c/tvp514x.c   | 12 +++---
 drivers/media/i2c/tvp5150.c   |  6 +--
 drivers/media/i2c/tvp7002.c   | 10 ++---
 drivers/media/i2c/vs6624.c| 18 
 46 files changed, 382 insertions(+), 382 deletions(-)

diff --git a/drivers/media/i2c/adv7170.c b/drivers/media/i2c/adv7170.c
index 04bb297..40a1a95 100644
--- a/drivers/media/i2c/adv7170.c
+++ b/drivers/media/i2c/adv7170.c
@@ -63,9 +63,9 @@ static inline struct adv7170 *to_adv7170(struct v4l2_subdev 
*sd)
 
 static char *inputs[] = { pass_through, play_back };
 
-static enum v4l2_mbus_pixelcode adv7170_codes[] = {
-   V4L2_MBUS_FMT_UYVY8_2X8,
-   V4L2_MBUS_FMT_UYVY8_1X16,
+static u32 adv7170_codes[] = {
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_UYVY8_1X16,
 };
 
 /* --- */
@@ -263,7 +263,7 @@ static int adv7170_s_routing(struct v4l2_subdev *sd,
 }
 
 static int adv7170_enum_fmt(struct v4l2_subdev *sd, unsigned int index,
-   enum v4l2_mbus_pixelcode *code)
+   u32 *code)
 {
if (index = ARRAY_SIZE(adv7170_codes))
return -EINVAL;
@@ -278,9 +278,9 @@ static int adv7170_g_fmt(struct v4l2_subdev *sd,
u8 val = adv7170_read(sd, 0x7);
 
if ((val  0x40) == (1  6))
-   mf-code = V4L2_MBUS_FMT_UYVY8_1X16;
+   mf-code = MEDIA_BUS_FMT_UYVY8_1X16;
else
-   mf-code = V4L2_MBUS_FMT_UYVY8_2X8;
+   mf-code = MEDIA_BUS_FMT_UYVY8_2X8;
 
mf-colorspace  = V4L2_COLORSPACE_SMPTE170M;
mf-width   = 0;
@@ -297,11 +297,11 @@ static int adv7170_s_fmt(struct v4l2_subdev *sd,
int ret;
 
switch (mf-code) {
-   case V4L2_MBUS_FMT_UYVY8_2X8:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
val = ~0x40;
break;
 
-   case V4L2_MBUS_FMT_UYVY8_1X16:
+   case MEDIA_BUS_FMT_UYVY8_1X16:
val |= 0x40;
break;
 
diff --git a/drivers/media/i2c/adv7175.c b/drivers/media/i2c/adv7175.c
index b88f3b3..d220af5 100644
--- a/drivers/media

[PATCH v6 RESEND 09/10] gpu: ipu-v3: Make use of media_bus_format enum

2014-11-10 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed enum values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Reference new definitions in the ipu-v3 driver.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Philipp Zabel p.za...@pengutronix.de
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 drivers/gpu/ipu-v3/ipu-csi.c | 66 ++--
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index d6f56471..752cdd2 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -227,83 +227,83 @@ static int ipu_csi_set_testgen_mclk(struct ipu_csi *csi, 
u32 pixel_clk,
 static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config *cfg, u32 mbus_code)
 {
switch (mbus_code) {
-   case V4L2_MBUS_FMT_BGR565_2X8_BE:
-   case V4L2_MBUS_FMT_BGR565_2X8_LE:
-   case V4L2_MBUS_FMT_RGB565_2X8_BE:
-   case V4L2_MBUS_FMT_RGB565_2X8_LE:
+   case MEDIA_BUS_FMT_BGR565_2X8_BE:
+   case MEDIA_BUS_FMT_BGR565_2X8_LE:
+   case MEDIA_BUS_FMT_RGB565_2X8_BE:
+   case MEDIA_BUS_FMT_RGB565_2X8_LE:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_RGB565;
cfg-mipi_dt = MIPI_DT_RGB565;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE:
-   case V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE:
+   case MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE:
+   case MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_RGB444;
cfg-mipi_dt = MIPI_DT_RGB444;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE:
-   case V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE:
+   case MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE:
+   case MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_RGB555;
cfg-mipi_dt = MIPI_DT_RGB555;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_UYVY8_2X8:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_YUV422_UYVY;
cfg-mipi_dt = MIPI_DT_YUV422;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_YUYV8_2X8:
+   case MEDIA_BUS_FMT_YUYV8_2X8:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_YUV422_YUYV;
cfg-mipi_dt = MIPI_DT_YUV422;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_UYVY8_1X16:
+   case MEDIA_BUS_FMT_UYVY8_1X16:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_YUV422_UYVY;
cfg-mipi_dt = MIPI_DT_YUV422;
cfg-data_width = IPU_CSI_DATA_WIDTH_16;
break;
-   case V4L2_MBUS_FMT_YUYV8_1X16:
+   case MEDIA_BUS_FMT_YUYV8_1X16:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_YUV422_YUYV;
cfg-mipi_dt = MIPI_DT_YUV422;
cfg-data_width = IPU_CSI_DATA_WIDTH_16;
break;
-   case V4L2_MBUS_FMT_SBGGR8_1X8:
-   case V4L2_MBUS_FMT_SGBRG8_1X8:
-   case V4L2_MBUS_FMT_SGRBG8_1X8:
-   case V4L2_MBUS_FMT_SRGGB8_1X8:
+   case MEDIA_BUS_FMT_SBGGR8_1X8:
+   case MEDIA_BUS_FMT_SGBRG8_1X8:
+   case MEDIA_BUS_FMT_SGRBG8_1X8:
+   case MEDIA_BUS_FMT_SRGGB8_1X8:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_BAYER;
cfg-mipi_dt = MIPI_DT_RAW8;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE:
-   case V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE:
-   case V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE:
-   case V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE:
+   case MEDIA_BUS_FMT_SBGGR10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SGBRG10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SRGGB10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE:
+   case MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE:
+   case MEDIA_BUS_FMT_SBGGR10_2X8_PADLO_BE:
+   case MEDIA_BUS_FMT_SBGGR10_2X8_PADLO_LE:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_BAYER;
cfg-mipi_dt = MIPI_DT_RAW10;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_SBGGR10_1X10:
-   case V4L2_MBUS_FMT_SGBRG10_1X10:
-   case V4L2_MBUS_FMT_SGRBG10_1X10:
-   case V4L2_MBUS_FMT_SRGGB10_1X10:
+   case MEDIA_BUS_FMT_SBGGR10_1X10:
+   case

[PATCH v5 10/10] [media] v4l: Forbid usage of V4L2_MBUS_FMT definitions inside the kernel

2014-11-08 Thread Boris Brezillon
Place v4l2_mbus_pixelcode in a #ifndef __KERNEL__ section so that kernel
users don't have access to these definitions.

We have to keep this definition for user-space users even though they're
encouraged to move to the new media_bus_format enum.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 include/uapi/linux/v4l2-mediabus.h | 45 --
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/include/uapi/linux/v4l2-mediabus.h 
b/include/uapi/linux/v4l2-mediabus.h
index d712df8..5c9410d 100644
--- a/include/uapi/linux/v4l2-mediabus.h
+++ b/include/uapi/linux/v4l2-mediabus.h
@@ -15,6 +15,33 @@
 #include linux/types.h
 #include linux/videodev2.h
 
+/**
+ * struct v4l2_mbus_framefmt - frame format on the media bus
+ * @width: frame width
+ * @height:frame height
+ * @code:  data format code (from enum v4l2_mbus_pixelcode)
+ * @field: used interlacing type (from enum v4l2_field)
+ * @colorspace:colorspace of the data (from enum v4l2_colorspace)
+ */
+struct v4l2_mbus_framefmt {
+   __u32   width;
+   __u32   height;
+   __u32   code;
+   __u32   field;
+   __u32   colorspace;
+   __u32   reserved[7];
+};
+
+#ifndef __KERNEL__
+/*
+ * enum v4l2_mbus_pixelcode and its definitions are now deprecated, and
+ * MEDIA_BUS_FMT_ definitions (defined in media-bus-format.h) should be
+ * used instead.
+ *
+ * New defines should only be added to media-bus-format.h. The
+ * v4l2_mbus_pixelcode enum is frozen.
+ */
+
 #define V4L2_MBUS_FROM_MEDIA_BUS_FMT(name) \
MEDIA_BUS_FMT_ ## name = V4L2_MBUS_FMT_ ## name
 
@@ -102,22 +129,6 @@ enum v4l2_mbus_pixelcode {
 
V4L2_MBUS_FROM_MEDIA_BUS_FMT(AHSV_1X32),
 };
-
-/**
- * struct v4l2_mbus_framefmt - frame format on the media bus
- * @width: frame width
- * @height:frame height
- * @code:  data format code (from enum v4l2_mbus_pixelcode)
- * @field: used interlacing type (from enum v4l2_field)
- * @colorspace:colorspace of the data (from enum v4l2_colorspace)
- */
-struct v4l2_mbus_framefmt {
-   __u32   width;
-   __u32   height;
-   __u32   code;
-   __u32   field;
-   __u32   colorspace;
-   __u32   reserved[7];
-};
+#endif /* __KERNEL__ */
 
 #endif
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 01/10] [media] Move mediabus format definition to a more standard place

2014-11-07 Thread Boris Brezillon
On Fri, 7 Nov 2014 13:43:59 +0200
Sakari Ailus sakari.ai...@iki.fi wrote:

 Hi Boris,
 
 Thank you for the update.
 
 On Thu, Nov 06, 2014 at 10:56:59AM +0100, Boris Brezillon wrote:
  Rename mediabus formats and move the enum into a separate header file so
  that it can be used by DRM/KMS subsystem without any reference to the V4L2
  subsystem.
  
  Old v4l2_mbus_pixelcode now points to media_bus_format.
  
  Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
  Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
  ---
   include/uapi/linux/Kbuild |   1 +
   include/uapi/linux/media-bus-format.h | 131 
  ++
   include/uapi/linux/v4l2-mediabus.h| 114 +
   3 files changed, 134 insertions(+), 112 deletions(-)
   create mode 100644 include/uapi/linux/media-bus-format.h
  
  diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
  index b70237e..b2c23f8 100644
  --- a/include/uapi/linux/Kbuild
  +++ b/include/uapi/linux/Kbuild
  @@ -414,6 +414,7 @@ header-y += veth.h
   header-y += vfio.h
   header-y += vhost.h
   header-y += videodev2.h
  +header-y += media-bus-format.h
 
 Could you arrange this to the list alphabetically, please?
 
   header-y += virtio_9p.h
   header-y += virtio_balloon.h
   header-y += virtio_blk.h
  diff --git a/include/uapi/linux/media-bus-format.h 
  b/include/uapi/linux/media-bus-format.h
  new file mode 100644
  index 000..251a902
  --- /dev/null
  +++ b/include/uapi/linux/media-bus-format.h
  @@ -0,0 +1,131 @@
  +/*
  + * Media Bus API header
  + *
  + * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License version 2 as
  + * published by the Free Software Foundation.
  + */
  +
  +#ifndef __LINUX_MEDIA_BUS_FORMAT_H
  +#define __LINUX_MEDIA_BUS_FORMAT_H
  +
  +/*
  + * These bus formats uniquely identify data formats on the data bus. 
  Format 0
  + * is reserved, MEDIA_BUS_FMT_FIXED shall be used by host-client pairs, 
  where
  + * the data format is fixed. Additionally, 2X8 means that one pixel is
  + * transferred in two 8-bit samples, BE or LE specify in which order 
  those
  + * samples are transferred over the bus: LE means that the least 
  significant
  + * bits are transferred first, BE means that the most significant bits 
  are
  + * transferred first, and PADHI and PADLO define which bits - low or 
  high,
  + * in the incomplete high byte, are filled with padding bits.
  + *
  + * The bus formats are grouped by type, bus_width, bits per component, 
  samples
  + * per pixel and order of subsamples. Numerical values are sorted using 
  generic
  + * numerical sort order (8 thus comes before 10).
  + *
  + * As their value can't change when a new bus format is inserted in the
  + * enumeration, the bus formats are explicitly given a numerical value. 
  The next
  + * free values for each category are listed below, update them when 
  inserting
  + * new pixel codes.
  + */
  +
  +#define MEDIA_BUS_FMT_ENTRY(name, val) \
  +   MEDIA_BUS_FMT_ ## name = val,   \
  +   V4L2_MBUS_FMT_ ## name = val
  +
  +enum media_bus_format {
 
 There's no really a need to keep the definitions inside the enum. It looks a
 little bit confusing to me. That made me realise something I missed
 yesterday.
 
 There's a difference: the enum in C++ is a different thing than in C, and
 the enum type isn't able to contain any other values than those defined in
 the enumeration.
 
 So what I propose is the following. Keep enum v4l2_mbus_pixelcode around,
 including the enum values. Define new values for MEDIA_BUS_* equivalents
 using preprocessor macros, as you've done below. Drop the definition of enum
 media_bus_format, and use u32 (or uint32_t) type for the variables.
 
 This way the enum stays intact for existing C++ applications, and new
 applications will have to use a 32-bit type.
 

Fair enough. If Hans agree I'll rework the series and drop the
media_bus_format enum.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 07/10] [media] usb: Make use of media_bus_format enum

2014-11-07 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed enum values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Reference new definitions in all usb drivers.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
 drivers/media/usb/cx231xx/cx231xx-417.c   | 2 +-
 drivers/media/usb/cx231xx/cx231xx-video.c | 4 ++--
 drivers/media/usb/em28xx/em28xx-camera.c  | 2 +-
 drivers/media/usb/go7007/go7007-v4l2.c| 2 +-
 drivers/media/usb/pvrusb2/pvrusb2-hdw.c   | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/cx231xx/cx231xx-417.c 
b/drivers/media/usb/cx231xx/cx231xx-417.c
index 459bb0e..95653ba 100644
--- a/drivers/media/usb/cx231xx/cx231xx-417.c
+++ b/drivers/media/usb/cx231xx/cx231xx-417.c
@@ -1878,7 +1878,7 @@ static int cx231xx_s_video_encoding(struct 
cx2341x_handler *cxhdl, u32 val)
/* fix videodecoder resolution */
fmt.width = cxhdl-width / (is_mpeg1 ? 2 : 1);
fmt.height = cxhdl-height;
-   fmt.code = V4L2_MBUS_FMT_FIXED;
+   fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(dev-sd_cx25840, video, s_mbus_fmt, fmt);
return 0;
 }
diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c 
b/drivers/media/usb/cx231xx/cx231xx-video.c
index 3b3ada6..989d527 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -967,7 +967,7 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void 
*priv,
dev-height = f-fmt.pix.height;
dev-format = fmt;
 
-   v4l2_fill_mbus_format(mbus_fmt, f-fmt.pix, V4L2_MBUS_FMT_FIXED);
+   v4l2_fill_mbus_format(mbus_fmt, f-fmt.pix, MEDIA_BUS_FMT_FIXED);
call_all(dev, video, s_mbus_fmt, mbus_fmt);
v4l2_fill_pix_format(f-fmt.pix, mbus_fmt);
 
@@ -1012,7 +1012,7 @@ static int vidioc_s_std(struct file *file, void *priv, 
v4l2_std_id norm)
   resolution (since a standard change effects things like the number
   of lines in VACT, etc) */
memset(mbus_fmt, 0, sizeof(mbus_fmt));
-   mbus_fmt.code = V4L2_MBUS_FMT_FIXED;
+   mbus_fmt.code = MEDIA_BUS_FMT_FIXED;
mbus_fmt.width = dev-width;
mbus_fmt.height = dev-height;
call_all(dev, video, s_mbus_fmt, mbus_fmt);
diff --git a/drivers/media/usb/em28xx/em28xx-camera.c 
b/drivers/media/usb/em28xx/em28xx-camera.c
index 6d2ea9a..38cf6c8 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -430,7 +430,7 @@ int em28xx_init_camera(struct em28xx *dev)
break;
}
 
-   fmt.code = V4L2_MBUS_FMT_YUYV8_2X8;
+   fmt.code = MEDIA_BUS_FMT_YUYV8_2X8;
fmt.width = 640;
fmt.height = 480;
v4l2_subdev_call(subdev, video, s_mbus_fmt, fmt);
diff --git a/drivers/media/usb/go7007/go7007-v4l2.c 
b/drivers/media/usb/go7007/go7007-v4l2.c
index ec799b4..d6bf982 100644
--- a/drivers/media/usb/go7007/go7007-v4l2.c
+++ b/drivers/media/usb/go7007/go7007-v4l2.c
@@ -252,7 +252,7 @@ static int set_capture_size(struct go7007 *go, struct 
v4l2_format *fmt, int try)
if (go-board_info-sensor_flags  GO7007_SENSOR_SCALING) {
struct v4l2_mbus_framefmt mbus_fmt;
 
-   mbus_fmt.code = V4L2_MBUS_FMT_FIXED;
+   mbus_fmt.code = MEDIA_BUS_FMT_FIXED;
mbus_fmt.width = fmt ? fmt-fmt.pix.width : width;
mbus_fmt.height = height;
go-encoder_h_halve = 0;
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c 
b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
index 9623b62..2fd9b5e 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
@@ -2966,7 +2966,7 @@ static void pvr2_subdev_update(struct pvr2_hdw *hdw)
memset(fmt, 0, sizeof(fmt));
fmt.width = hdw-res_hor_val;
fmt.height = hdw-res_ver_val;
-   fmt.code = V4L2_MBUS_FMT_FIXED;
+   fmt.code = MEDIA_BUS_FMT_FIXED;
pvr2_trace(PVR2_TRACE_CHIPS, subdev v4l2 set_size(%dx%d),
   fmt.width, fmt.height);
v4l2_device_call_all(hdw-v4l2_dev, 0, video, s_mbus_fmt, 
fmt);
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 08/10] staging: media: Make use of MEDIA_BUS_FMT_ definitions

2014-11-07 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Reference new definitions in all media drivers residing in staging.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
 drivers/staging/media/davinci_vpfe/dm365_ipipe.c   |  18 ++--
 .../staging/media/davinci_vpfe/dm365_ipipe_hw.c|  26 +++---
 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 100 ++---
 drivers/staging/media/davinci_vpfe/dm365_isif.c|  90 +--
 drivers/staging/media/davinci_vpfe/dm365_resizer.c |  98 ++--
 .../staging/media/davinci_vpfe/vpfe_mc_capture.c   |  18 ++--
 drivers/staging/media/omap4iss/iss_csi2.c  |  62 ++---
 drivers/staging/media/omap4iss/iss_ipipe.c |  16 ++--
 drivers/staging/media/omap4iss/iss_ipipeif.c   |  28 +++---
 drivers/staging/media/omap4iss/iss_resizer.c   |  26 +++---
 drivers/staging/media/omap4iss/iss_video.c |  78 
 drivers/staging/media/omap4iss/iss_video.h |  10 +--
 12 files changed, 285 insertions(+), 285 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index bdc7f00..704fa20 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -37,15 +37,15 @@
 
 /* ipipe input format's */
 static const unsigned int ipipe_input_fmts[] = {
-   V4L2_MBUS_FMT_UYVY8_2X8,
-   V4L2_MBUS_FMT_SGRBG12_1X12,
-   V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
-   V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8,
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_SGRBG12_1X12,
+   MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8,
+   MEDIA_BUS_FMT_SGRBG10_ALAW8_1X8,
 };
 
 /* ipipe output format's */
 static const unsigned int ipipe_output_fmts[] = {
-   V4L2_MBUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_UYVY8_2X8,
 };
 
 static int ipipe_validate_lutdpc_params(struct vpfe_ipipe_lutdpc *lutdpc)
@@ -1457,7 +1457,7 @@ ipipe_try_format(struct vpfe_ipipe_device *ipipe,
 
/* If not found, use SBGGR10 as default */
if (i = ARRAY_SIZE(ipipe_input_fmts))
-   fmt-code = V4L2_MBUS_FMT_SGRBG12_1X12;
+   fmt-code = MEDIA_BUS_FMT_SGRBG12_1X12;
} else if (pad == IPIPE_PAD_SOURCE) {
for (i = 0; i  ARRAY_SIZE(ipipe_output_fmts); i++)
if (fmt-code == ipipe_output_fmts[i])
@@ -1465,7 +1465,7 @@ ipipe_try_format(struct vpfe_ipipe_device *ipipe,
 
/* If not found, use UYVY as default */
if (i = ARRAY_SIZE(ipipe_output_fmts))
-   fmt-code = V4L2_MBUS_FMT_UYVY8_2X8;
+   fmt-code = MEDIA_BUS_FMT_UYVY8_2X8;
}
 
fmt-width = clamp_t(u32, fmt-width, MIN_OUT_HEIGHT, max_out_width);
@@ -1642,7 +1642,7 @@ ipipe_init_formats(struct v4l2_subdev *sd, struct 
v4l2_subdev_fh *fh)
memset(format, 0, sizeof(format));
format.pad = IPIPE_PAD_SINK;
format.which = fh ? V4L2_SUBDEV_FORMAT_TRY : V4L2_SUBDEV_FORMAT_ACTIVE;
-   format.format.code = V4L2_MBUS_FMT_SGRBG12_1X12;
+   format.format.code = MEDIA_BUS_FMT_SGRBG12_1X12;
format.format.width = IPIPE_MAX_OUTPUT_WIDTH_A;
format.format.height = IPIPE_MAX_OUTPUT_HEIGHT_A;
ipipe_set_format(sd, fh, format);
@@ -1650,7 +1650,7 @@ ipipe_init_formats(struct v4l2_subdev *sd, struct 
v4l2_subdev_fh *fh)
memset(format, 0, sizeof(format));
format.pad = IPIPE_PAD_SOURCE;
format.which = fh ? V4L2_SUBDEV_FORMAT_TRY : V4L2_SUBDEV_FORMAT_ACTIVE;
-   format.format.code = V4L2_MBUS_FMT_UYVY8_2X8;
+   format.format.code = MEDIA_BUS_FMT_UYVY8_2X8;
format.format.width = IPIPE_MAX_OUTPUT_WIDTH_A;
format.format.height = IPIPE_MAX_OUTPUT_HEIGHT_A;
ipipe_set_format(sd, fh, format);
diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
index b2daf5e..6461de1 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
@@ -196,12 +196,12 @@ ipipe_setup_resizer(void *__iomem rsz_base, struct 
resizer_params *params)
rsz_set_rsz_regs(rsz_base, RSZ_B, params);
 }
 
-static u32 ipipe_get_color_pat(enum v4l2_mbus_pixelcode pix)
+static u32 ipipe_get_color_pat(u32 pix)
 {
switch (pix) {
-   case V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8:
-   case V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SGRBG12_1X12:
+   case MEDIA_BUS_FMT_SGRBG10_ALAW8_1X8:
+   case MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SGRBG12_1X12:
return ipipe_sgrbg_pattern;
 
default:
@@ -211,23 +211,23 @@ static u32 ipipe_get_color_pat(enum

[PATCH v3 06/10] [media] platform: Make use of media_bus_format enum

2014-11-07 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Reference new definitions in all platform drivers.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
 Documentation/video4linux/soc-camera.txt   |   2 +-
 arch/arm/mach-davinci/board-dm355-evm.c|   2 +-
 arch/arm/mach-davinci/board-dm365-evm.c|   4 +-
 arch/arm/mach-davinci/dm355.c  |   7 +-
 arch/arm/mach-davinci/dm365.c  |   7 +-
 arch/arm/mach-shmobile/board-mackerel.c|   2 +-
 arch/sh/boards/mach-ap325rxa/setup.c   |   2 +-
 drivers/media/platform/blackfin/bfin_capture.c |  14 +--
 drivers/media/platform/davinci/vpbe.c  |   2 +-
 drivers/media/platform/davinci/vpfe_capture.c  |   4 +-
 drivers/media/platform/exynos-gsc/gsc-core.c   |   8 +-
 drivers/media/platform/exynos-gsc/gsc-core.h   |   2 +-
 drivers/media/platform/exynos4-is/fimc-capture.c   |   2 +-
 drivers/media/platform/exynos4-is/fimc-core.c  |  14 +--
 drivers/media/platform/exynos4-is/fimc-core.h  |   4 +-
 drivers/media/platform/exynos4-is/fimc-isp.c   |  16 +--
 drivers/media/platform/exynos4-is/fimc-lite-reg.c  |  26 ++---
 drivers/media/platform/exynos4-is/fimc-lite.c  |  14 +--
 drivers/media/platform/exynos4-is/fimc-reg.c   |  14 +--
 drivers/media/platform/exynos4-is/mipi-csis.c  |  14 +--
 drivers/media/platform/marvell-ccic/mcam-core.c|  21 ++--
 drivers/media/platform/marvell-ccic/mcam-core.h|   2 +-
 drivers/media/platform/omap3isp/ispccdc.c  | 112 ++---
 drivers/media/platform/omap3isp/ispccp2.c  |  18 ++--
 drivers/media/platform/omap3isp/ispcsi2.c  |  42 
 drivers/media/platform/omap3isp/isppreview.c   |  60 ++-
 drivers/media/platform/omap3isp/ispresizer.c   |  19 ++--
 drivers/media/platform/omap3isp/ispvideo.c |  95 +
 drivers/media/platform/omap3isp/ispvideo.h |  10 +-
 drivers/media/platform/s3c-camif/camif-capture.c   |  10 +-
 drivers/media/platform/s3c-camif/camif-regs.c  |   8 +-
 drivers/media/platform/s5p-tv/hdmi_drv.c   |   2 +-
 drivers/media/platform/s5p-tv/sdo_drv.c|   2 +-
 drivers/media/platform/sh_vou.c|   8 +-
 drivers/media/platform/soc_camera/atmel-isi.c  |  22 ++--
 drivers/media/platform/soc_camera/mx2_camera.c |  26 +++--
 drivers/media/platform/soc_camera/mx3_camera.c |   6 +-
 drivers/media/platform/soc_camera/omap1_camera.c   |  36 +++
 drivers/media/platform/soc_camera/pxa_camera.c |  16 +--
 drivers/media/platform/soc_camera/rcar_vin.c   |  14 +--
 .../platform/soc_camera/sh_mobile_ceu_camera.c |  20 ++--
 drivers/media/platform/soc_camera/sh_mobile_csi2.c |  38 +++
 drivers/media/platform/soc_camera/soc_camera.c |   2 +-
 .../platform/soc_camera/soc_camera_platform.c  |   2 +-
 drivers/media/platform/soc_camera/soc_mediabus.c   |  78 +++---
 drivers/media/platform/via-camera.c|   8 +-
 drivers/media/platform/vsp1/vsp1_bru.c |  14 +--
 drivers/media/platform/vsp1/vsp1_hsit.c|  12 +--
 drivers/media/platform/vsp1/vsp1_lif.c |  10 +-
 drivers/media/platform/vsp1/vsp1_lut.c |  14 +--
 drivers/media/platform/vsp1/vsp1_rwpf.c|  10 +-
 drivers/media/platform/vsp1/vsp1_sru.c |  12 +--
 drivers/media/platform/vsp1/vsp1_uds.c |  10 +-
 drivers/media/platform/vsp1/vsp1_video.c   |  42 
 include/media/davinci/vpbe.h   |   2 +-
 include/media/davinci/vpbe_venc.h  |   5 +-
 include/media/exynos-fimc.h|   2 +-
 include/media/soc_camera.h |   2 +-
 include/media/soc_mediabus.h   |   6 +-
 59 files changed, 483 insertions(+), 495 deletions(-)

diff --git a/Documentation/video4linux/soc-camera.txt 
b/Documentation/video4linux/soc-camera.txt
index daa9e2a..84f41cf 100644
--- a/Documentation/video4linux/soc-camera.txt
+++ b/Documentation/video4linux/soc-camera.txt
@@ -151,7 +151,7 @@ they are transferred over a media bus. Soc-camera provides 
support to
 conveniently manage these formats. A table of standard transformations is
 maintained by soc-camera core, which describes, what FOURCC pixel format will
 be obtained, if a media-bus pixel format is stored in memory according to
-certain rules. E.g. if V4L2_MBUS_FMT_YUYV8_2X8 data is sampled with 8 bits per
+certain rules. E.g. if MEDIA_BUS_FMT_YUYV8_2X8 data is sampled with 8 bits per
 sample and stored in memory in the little-endian order with no gaps between
 bytes, data in memory will represent the V4L2_PIX_FMT_YUYV FOURCC format. These
 standard transformations will be used by soc-camera

[PATCH v3 00/10] [media] Make mediabus format subsystem neutral

2014-11-07 Thread Boris Brezillon
Hello,

This patch series prepares the use of media bus formats outside of
the V4L2 subsytem (my final goal is to use it in the Atmel HLCDC DRM
driver where I have to configure my DPI/RGB bus according to the
connected display).

The series first defines MEDIA_BUS_FMT_ macros, and then replace all
references to the v4l2_mbus_pixelcode enum and its values within the
kernel.

Best Regards,

Boris

Changes since v2:
- drop media_bus_format enum and replace its values with pre-processor
  macros

Changes since v1:
- drop patches deprecating v4l2_mbus_pixelcode for user-space users
- put V4L2 legacy format definitions into media-bus-format.h

Boris Brezillon (10):
  [media] Move mediabus format definition to a more standard place
  [media] v4l: Update subdev-formats doc with new MEDIA_BUS_FMT values
  [media] Make use of the new media_bus_format definitions
  [media] i2c: Make use of media_bus_format enum
  [media] pci: Make use of MEDIA_BUS_FMT definitions
  [media] platform: Make use of media_bus_format enum
  [media] usb: Make use of media_bus_format enum
  staging: media: Make use of MEDIA_BUS_FMT_ definitions
  gpu: ipu-v3: Make use of media_bus_format enum
  [media] v4l: Forbid usage of V4L2_MBUS_FMT definitions inside the
kernel

 Documentation/DocBook/media/v4l/subdev-formats.xml | 308 ++---
 Documentation/video4linux/soc-camera.txt   |   2 +-
 arch/arm/mach-davinci/board-dm355-evm.c|   2 +-
 arch/arm/mach-davinci/board-dm365-evm.c|   4 +-
 arch/arm/mach-davinci/dm355.c  |   7 +-
 arch/arm/mach-davinci/dm365.c  |   7 +-
 arch/arm/mach-shmobile/board-mackerel.c|   2 +-
 arch/sh/boards/mach-ap325rxa/setup.c   |   2 +-
 drivers/gpu/ipu-v3/ipu-csi.c   |  66 ++---
 drivers/media/i2c/adv7170.c|  16 +-
 drivers/media/i2c/adv7175.c|  16 +-
 drivers/media/i2c/adv7180.c|   6 +-
 drivers/media/i2c/adv7183.c|   6 +-
 drivers/media/i2c/adv7604.c|  72 ++---
 drivers/media/i2c/adv7842.c|   6 +-
 drivers/media/i2c/ak881x.c |   8 +-
 drivers/media/i2c/cx25840/cx25840-core.c   |   2 +-
 drivers/media/i2c/m5mols/m5mols_core.c |   6 +-
 drivers/media/i2c/ml86v7667.c  |   6 +-
 drivers/media/i2c/mt9m032.c|   6 +-
 drivers/media/i2c/mt9p031.c|   8 +-
 drivers/media/i2c/mt9t001.c|   8 +-
 drivers/media/i2c/mt9v011.c|   6 +-
 drivers/media/i2c/mt9v032.c|  12 +-
 drivers/media/i2c/noon010pc30.c|  12 +-
 drivers/media/i2c/ov7670.c |  16 +-
 drivers/media/i2c/ov9650.c |  10 +-
 drivers/media/i2c/s5c73m3/s5c73m3.h|   6 +-
 drivers/media/i2c/s5k4ecgx.c   |   4 +-
 drivers/media/i2c/s5k5baf.c|  14 +-
 drivers/media/i2c/s5k6a3.c |   2 +-
 drivers/media/i2c/s5k6aa.c |   8 +-
 drivers/media/i2c/saa6752hs.c  |   6 +-
 drivers/media/i2c/saa7115.c|   2 +-
 drivers/media/i2c/saa717x.c|   2 +-
 drivers/media/i2c/smiapp/smiapp-core.c |  32 +--
 drivers/media/i2c/soc_camera/imx074.c  |   8 +-
 drivers/media/i2c/soc_camera/mt9m001.c |  14 +-
 drivers/media/i2c/soc_camera/mt9m111.c |  70 ++---
 drivers/media/i2c/soc_camera/mt9t031.c |  10 +-
 drivers/media/i2c/soc_camera/mt9t112.c |  22 +-
 drivers/media/i2c/soc_camera/mt9v022.c |  26 +-
 drivers/media/i2c/soc_camera/ov2640.c  |  54 ++--
 drivers/media/i2c/soc_camera/ov5642.c  |   8 +-
 drivers/media/i2c/soc_camera/ov6650.c  |  58 ++--
 drivers/media/i2c/soc_camera/ov772x.c  |  20 +-
 drivers/media/i2c/soc_camera/ov9640.c  |  40 +--
 drivers/media/i2c/soc_camera/ov9740.c  |  12 +-
 drivers/media/i2c/soc_camera/rj54n1cb0c.c  |  54 ++--
 drivers/media/i2c/soc_camera/tw9910.c  |  10 +-
 drivers/media/i2c/sr030pc30.c  |  14 +-
 drivers/media/i2c/tvp514x.c|  12 +-
 drivers/media/i2c/tvp5150.c|   6 +-
 drivers/media/i2c/tvp7002.c|  10 +-
 drivers/media/i2c/vs6624.c |  18 +-
 drivers/media/pci/cx18/cx18-av-core.c  |   2 +-
 drivers/media/pci/cx18/cx18-controls.c |   2 +-
 drivers/media/pci/cx18/cx18-ioctl.c|   2 +-
 drivers/media/pci/cx23885/cx23885-video.c  |   2 +-
 drivers/media/pci/ivtv/ivtv-controls.c |   2 +-
 drivers/media/pci/ivtv/ivtv-ioctl.c

[PATCH v3 10/10] [media] v4l: Forbid usage of V4L2_MBUS_FMT definitions inside the kernel

2014-11-07 Thread Boris Brezillon
Place v4l2_mbus_pixelcode in a #ifndef __KERNEL__ section so that kernel
users don't have access to these definitions.

We have to keep this definition for user-space users even though they're
encouraged to move to the new media_bus_format enum.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
 include/uapi/linux/v4l2-mediabus.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/uapi/linux/v4l2-mediabus.h 
b/include/uapi/linux/v4l2-mediabus.h
index 3d87db7..4f31d0e 100644
--- a/include/uapi/linux/v4l2-mediabus.h
+++ b/include/uapi/linux/v4l2-mediabus.h
@@ -15,6 +15,14 @@
 #include linux/videodev2.h
 #include linux/media-bus-format.h
 
+#ifndef __KERNEL__
+
+/*
+ * enum v4l2_mbus_pixelcode and its defintions are now deprecated, and
+ * MEDIA_BUS_FMT_ defintions (defined in media-bus-format.h) should be
+ * used instead.
+ */
+
 #define V4L2_MBUS_FROM_MEDIA_BUS_FMT(name) \
MEDIA_BUS_FMT_ ## name = V4L2_MBUS_FMT_ ## name
 
@@ -102,6 +110,7 @@ enum v4l2_mbus_pixelcode {
 
V4L2_MBUS_FROM_MEDIA_BUS_FMT(AHSV_1X32),
 };
+#endif /* __KERNEL__ */
 
 /**
  * struct v4l2_mbus_framefmt - frame format on the media bus
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 01/10] [media] Move mediabus format definition to a more standard place

2014-11-07 Thread Boris Brezillon
Define MEDIA_BUS_FMT macros (re-using the values defined in the
v4l2_mbus_pixelcode enum) into a separate header file so that they can be
used from the DRM/KMS subsystem without any reference to the V4L2
subsystem.

Then set V4L2_MBUS_FMT definitions to the MEDIA_BUS_FMT values using the
V4L2_MBUS_FROM_MEDIA_BUS_FMT macro.

Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
 include/uapi/linux/Kbuild |   1 +
 include/uapi/linux/media-bus-format.h | 125 +++
 include/uapi/linux/v4l2-mediabus.h| 184 +++---
 3 files changed, 206 insertions(+), 104 deletions(-)
 create mode 100644 include/uapi/linux/media-bus-format.h

diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index b70237e..ed39ac8 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -241,6 +241,7 @@ header-y += map_to_7segment.h
 header-y += matroxfb.h
 header-y += mdio.h
 header-y += media.h
+header-y += media-bus-format.h
 header-y += mei.h
 header-y += memfd.h
 header-y += mempolicy.h
diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
new file mode 100644
index 000..23b4090
--- /dev/null
+++ b/include/uapi/linux/media-bus-format.h
@@ -0,0 +1,125 @@
+/*
+ * Media Bus API header
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __LINUX_MEDIA_BUS_FORMAT_H
+#define __LINUX_MEDIA_BUS_FORMAT_H
+
+/*
+ * These bus formats uniquely identify data formats on the data bus. Format 0
+ * is reserved, MEDIA_BUS_FMT_FIXED shall be used by host-client pairs, where
+ * the data format is fixed. Additionally, 2X8 means that one pixel is
+ * transferred in two 8-bit samples, BE or LE specify in which order those
+ * samples are transferred over the bus: LE means that the least significant
+ * bits are transferred first, BE means that the most significant bits are
+ * transferred first, and PADHI and PADLO define which bits - low or high,
+ * in the incomplete high byte, are filled with padding bits.
+ *
+ * The bus formats are grouped by type, bus_width, bits per component, samples
+ * per pixel and order of subsamples. Numerical values are sorted using generic
+ * numerical sort order (8 thus comes before 10).
+ *
+ * As their value can't change when a new bus format is inserted in the
+ * enumeration, the bus formats are explicitly given a numerical value. The 
next
+ * free values for each category are listed below, update them when inserting
+ * new pixel codes.
+ */
+
+#define MEDIA_BUS_FMT_FIXED0x0001
+
+/* RGB - next is   0x100e */
+#define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
+#define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
+#define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE  0x1003
+#define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE  0x1004
+#define MEDIA_BUS_FMT_BGR565_2X8_BE0x1005
+#define MEDIA_BUS_FMT_BGR565_2X8_LE0x1006
+#define MEDIA_BUS_FMT_RGB565_2X8_BE0x1007
+#define MEDIA_BUS_FMT_RGB565_2X8_LE0x1008
+#define MEDIA_BUS_FMT_RGB666_1X18  0x1009
+#define MEDIA_BUS_FMT_RGB888_1X24  0x100a
+#define MEDIA_BUS_FMT_RGB888_2X12_BE   0x100b
+#define MEDIA_BUS_FMT_RGB888_2X12_LE   0x100c
+#define MEDIA_BUS_FMT_ARGB_1X320x100d
+
+/* YUV (including grey) - next is  0x2024 */
+#define MEDIA_BUS_FMT_Y8_1X8   0x2001
+#define MEDIA_BUS_FMT_UV8_1X8  0x2015
+#define MEDIA_BUS_FMT_UYVY8_1_5X8  0x2002
+#define MEDIA_BUS_FMT_VYUY8_1_5X8  0x2003
+#define MEDIA_BUS_FMT_YUYV8_1_5X8  0x2004
+#define MEDIA_BUS_FMT_YVYU8_1_5X8  0x2005
+#define MEDIA_BUS_FMT_UYVY8_2X80x2006
+#define MEDIA_BUS_FMT_VYUY8_2X80x2007
+#define MEDIA_BUS_FMT_YUYV8_2X80x2008
+#define MEDIA_BUS_FMT_YVYU8_2X80x2009
+#define MEDIA_BUS_FMT_Y10_1X10 0x200a
+#define MEDIA_BUS_FMT_UYVY10_2X10  0x2018
+#define MEDIA_BUS_FMT_VYUY10_2X10  0x2019
+#define MEDIA_BUS_FMT_YUYV10_2X10  0x200b
+#define MEDIA_BUS_FMT_YVYU10_2X10  0x200c
+#define MEDIA_BUS_FMT_Y12_1X12 0x2013
+#define MEDIA_BUS_FMT_UYVY8_1X16   0x200f
+#define MEDIA_BUS_FMT_VYUY8_1X16   0x2010
+#define MEDIA_BUS_FMT_YUYV8_1X16   0x2011
+#define MEDIA_BUS_FMT_YVYU8_1X16   0x2012
+#define MEDIA_BUS_FMT_YDYUYDYV8_1X16   0x2014
+#define MEDIA_BUS_FMT_UYVY10_1X20  0x201a
+#define MEDIA_BUS_FMT_VYUY10_1X20  0x201b
+#define MEDIA_BUS_FMT_YUYV10_1X20

[PATCH v3 05/10] [media] pci: Make use of MEDIA_BUS_FMT definitions

2014-11-07 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Replace all references to the old definitions in pci drivers.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
 drivers/media/pci/cx18/cx18-av-core.c   | 2 +-
 drivers/media/pci/cx18/cx18-controls.c  | 2 +-
 drivers/media/pci/cx18/cx18-ioctl.c | 2 +-
 drivers/media/pci/cx23885/cx23885-video.c   | 2 +-
 drivers/media/pci/ivtv/ivtv-controls.c  | 2 +-
 drivers/media/pci/ivtv/ivtv-ioctl.c | 2 +-
 drivers/media/pci/saa7134/saa7134-empress.c | 4 ++--
 7 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/media/pci/cx18/cx18-av-core.c 
b/drivers/media/pci/cx18/cx18-av-core.c
index 2d3afe0..4c6ce21 100644
--- a/drivers/media/pci/cx18/cx18-av-core.c
+++ b/drivers/media/pci/cx18/cx18-av-core.c
@@ -952,7 +952,7 @@ static int cx18_av_s_mbus_fmt(struct v4l2_subdev *sd, 
struct v4l2_mbus_framefmt
int HSC, VSC, Vsrc, Hsrc, filter, Vlines;
int is_50Hz = !(state-std  V4L2_STD_525_60);
 
-   if (fmt-code != V4L2_MBUS_FMT_FIXED)
+   if (fmt-code != MEDIA_BUS_FMT_FIXED)
return -EINVAL;
 
fmt-field = V4L2_FIELD_INTERLACED;
diff --git a/drivers/media/pci/cx18/cx18-controls.c 
b/drivers/media/pci/cx18/cx18-controls.c
index 282a3d2..4aeb7c6 100644
--- a/drivers/media/pci/cx18/cx18-controls.c
+++ b/drivers/media/pci/cx18/cx18-controls.c
@@ -98,7 +98,7 @@ static int cx18_s_video_encoding(struct cx2341x_handler 
*cxhdl, u32 val)
/* fix videodecoder resolution */
fmt.width = cxhdl-width / (is_mpeg1 ? 2 : 1);
fmt.height = cxhdl-height;
-   fmt.code = V4L2_MBUS_FMT_FIXED;
+   fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(cx-sd_av, video, s_mbus_fmt, fmt);
return 0;
 }
diff --git a/drivers/media/pci/cx18/cx18-ioctl.c 
b/drivers/media/pci/cx18/cx18-ioctl.c
index 6f2b590..71963db 100644
--- a/drivers/media/pci/cx18/cx18-ioctl.c
+++ b/drivers/media/pci/cx18/cx18-ioctl.c
@@ -294,7 +294,7 @@ static int cx18_s_fmt_vid_cap(struct file *file, void *fh,
 
mbus_fmt.width = cx-cxhdl.width = w;
mbus_fmt.height = cx-cxhdl.height = h;
-   mbus_fmt.code = V4L2_MBUS_FMT_FIXED;
+   mbus_fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(cx-sd_av, video, s_mbus_fmt, mbus_fmt);
return cx18_g_fmt_vid_cap(file, fh, fmt);
 }
diff --git a/drivers/media/pci/cx23885/cx23885-video.c 
b/drivers/media/pci/cx23885/cx23885-video.c
index 682a4f9..091f5db 100644
--- a/drivers/media/pci/cx23885/cx23885-video.c
+++ b/drivers/media/pci/cx23885/cx23885-video.c
@@ -608,7 +608,7 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void 
*priv,
dev-field  = f-fmt.pix.field;
dprintk(2, %s() width=%d height=%d field=%d\n, __func__,
dev-width, dev-height, dev-field);
-   v4l2_fill_mbus_format(mbus_fmt, f-fmt.pix, V4L2_MBUS_FMT_FIXED);
+   v4l2_fill_mbus_format(mbus_fmt, f-fmt.pix, MEDIA_BUS_FMT_FIXED);
call_all(dev, video, s_mbus_fmt, mbus_fmt);
v4l2_fill_pix_format(f-fmt.pix, mbus_fmt);
/* s_mbus_fmt overwrites f-fmt.pix.field, restore it */
diff --git a/drivers/media/pci/ivtv/ivtv-controls.c 
b/drivers/media/pci/ivtv/ivtv-controls.c
index 2b0ab26..ccf548c 100644
--- a/drivers/media/pci/ivtv/ivtv-controls.c
+++ b/drivers/media/pci/ivtv/ivtv-controls.c
@@ -69,7 +69,7 @@ static int ivtv_s_video_encoding(struct cx2341x_handler 
*cxhdl, u32 val)
/* fix videodecoder resolution */
fmt.width = cxhdl-width / (is_mpeg1 ? 2 : 1);
fmt.height = cxhdl-height;
-   fmt.code = V4L2_MBUS_FMT_FIXED;
+   fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(itv-sd_video, video, s_mbus_fmt, fmt);
return 0;
 }
diff --git a/drivers/media/pci/ivtv/ivtv-ioctl.c 
b/drivers/media/pci/ivtv/ivtv-ioctl.c
index 3e0cb77..4d8ee18 100644
--- a/drivers/media/pci/ivtv/ivtv-ioctl.c
+++ b/drivers/media/pci/ivtv/ivtv-ioctl.c
@@ -595,7 +595,7 @@ static int ivtv_s_fmt_vid_cap(struct file *file, void *fh, 
struct v4l2_format *f
fmt-fmt.pix.width /= 2;
mbus_fmt.width = fmt-fmt.pix.width;
mbus_fmt.height = h;
-   mbus_fmt.code = V4L2_MBUS_FMT_FIXED;
+   mbus_fmt.code = MEDIA_BUS_FMT_FIXED;
v4l2_subdev_call(itv-sd_video, video, s_mbus_fmt, mbus_fmt);
return ivtv_g_fmt_vid_cap(file, fh, fmt);
 }
diff --git a/drivers/media/pci/saa7134/saa7134-empress.c 
b/drivers/media/pci/saa7134/saa7134-empress.c
index e4ea85f..8b3bb78 100644
--- a/drivers/media/pci/saa7134/saa7134-empress.c
+++ b/drivers/media/pci/saa7134/saa7134-empress.c
@@ -140,7 +140,7 @@ static int empress_s_fmt_vid_cap(struct file *file, void 
*priv,
struct saa7134_dev *dev = video_drvdata(file);
struct v4l2_mbus_framefmt mbus_fmt;
 
-   v4l2_fill_mbus_format(mbus_fmt, f

[PATCH v3 09/10] gpu: ipu-v3: Make use of media_bus_format enum

2014-11-07 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed enum values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Reference new definitions in the ipu-v3 driver.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
 drivers/gpu/ipu-v3/ipu-csi.c | 66 ++--
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index d6f56471..752cdd2 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -227,83 +227,83 @@ static int ipu_csi_set_testgen_mclk(struct ipu_csi *csi, 
u32 pixel_clk,
 static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config *cfg, u32 mbus_code)
 {
switch (mbus_code) {
-   case V4L2_MBUS_FMT_BGR565_2X8_BE:
-   case V4L2_MBUS_FMT_BGR565_2X8_LE:
-   case V4L2_MBUS_FMT_RGB565_2X8_BE:
-   case V4L2_MBUS_FMT_RGB565_2X8_LE:
+   case MEDIA_BUS_FMT_BGR565_2X8_BE:
+   case MEDIA_BUS_FMT_BGR565_2X8_LE:
+   case MEDIA_BUS_FMT_RGB565_2X8_BE:
+   case MEDIA_BUS_FMT_RGB565_2X8_LE:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_RGB565;
cfg-mipi_dt = MIPI_DT_RGB565;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE:
-   case V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE:
+   case MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE:
+   case MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_RGB444;
cfg-mipi_dt = MIPI_DT_RGB444;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE:
-   case V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE:
+   case MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE:
+   case MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_RGB555;
cfg-mipi_dt = MIPI_DT_RGB555;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_UYVY8_2X8:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_YUV422_UYVY;
cfg-mipi_dt = MIPI_DT_YUV422;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_YUYV8_2X8:
+   case MEDIA_BUS_FMT_YUYV8_2X8:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_YUV422_YUYV;
cfg-mipi_dt = MIPI_DT_YUV422;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_UYVY8_1X16:
+   case MEDIA_BUS_FMT_UYVY8_1X16:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_YUV422_UYVY;
cfg-mipi_dt = MIPI_DT_YUV422;
cfg-data_width = IPU_CSI_DATA_WIDTH_16;
break;
-   case V4L2_MBUS_FMT_YUYV8_1X16:
+   case MEDIA_BUS_FMT_YUYV8_1X16:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_YUV422_YUYV;
cfg-mipi_dt = MIPI_DT_YUV422;
cfg-data_width = IPU_CSI_DATA_WIDTH_16;
break;
-   case V4L2_MBUS_FMT_SBGGR8_1X8:
-   case V4L2_MBUS_FMT_SGBRG8_1X8:
-   case V4L2_MBUS_FMT_SGRBG8_1X8:
-   case V4L2_MBUS_FMT_SRGGB8_1X8:
+   case MEDIA_BUS_FMT_SBGGR8_1X8:
+   case MEDIA_BUS_FMT_SGBRG8_1X8:
+   case MEDIA_BUS_FMT_SGRBG8_1X8:
+   case MEDIA_BUS_FMT_SRGGB8_1X8:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_BAYER;
cfg-mipi_dt = MIPI_DT_RAW8;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8:
-   case V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE:
-   case V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE:
-   case V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE:
-   case V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE:
+   case MEDIA_BUS_FMT_SBGGR10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SGBRG10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SRGGB10_DPCM8_1X8:
+   case MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE:
+   case MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE:
+   case MEDIA_BUS_FMT_SBGGR10_2X8_PADLO_BE:
+   case MEDIA_BUS_FMT_SBGGR10_2X8_PADLO_LE:
cfg-data_fmt = CSI_SENS_CONF_DATA_FMT_BAYER;
cfg-mipi_dt = MIPI_DT_RAW10;
cfg-data_width = IPU_CSI_DATA_WIDTH_8;
break;
-   case V4L2_MBUS_FMT_SBGGR10_1X10:
-   case V4L2_MBUS_FMT_SGBRG10_1X10:
-   case V4L2_MBUS_FMT_SGRBG10_1X10:
-   case V4L2_MBUS_FMT_SRGGB10_1X10:
+   case MEDIA_BUS_FMT_SBGGR10_1X10:
+   case MEDIA_BUS_FMT_SGBRG10_1X10:
+   case MEDIA_BUS_FMT_SGRBG10_1X10:
+   case MEDIA_BUS_FMT_SRGGB10_1X10:
cfg-data_fmt

[PATCH v3 04/10] [media] i2c: Make use of media_bus_format enum

2014-11-07 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definitions to include/uapi/linux/media-bus-format.h and
prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Replace all references to the old definitions in i2c drivers.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
 drivers/media/i2c/adv7170.c   | 16 +++
 drivers/media/i2c/adv7175.c   | 16 +++
 drivers/media/i2c/adv7180.c   |  6 +--
 drivers/media/i2c/adv7183.c   |  6 +--
 drivers/media/i2c/adv7604.c   | 72 +++
 drivers/media/i2c/adv7842.c   |  6 +--
 drivers/media/i2c/ak881x.c|  8 ++--
 drivers/media/i2c/cx25840/cx25840-core.c  |  2 +-
 drivers/media/i2c/m5mols/m5mols_core.c|  6 +--
 drivers/media/i2c/ml86v7667.c |  6 +--
 drivers/media/i2c/mt9m032.c   |  6 +--
 drivers/media/i2c/mt9p031.c   |  8 ++--
 drivers/media/i2c/mt9t001.c   |  8 ++--
 drivers/media/i2c/mt9v011.c   |  6 +--
 drivers/media/i2c/mt9v032.c   | 12 +++---
 drivers/media/i2c/noon010pc30.c   | 12 +++---
 drivers/media/i2c/ov7670.c| 16 +++
 drivers/media/i2c/ov9650.c| 10 ++---
 drivers/media/i2c/s5c73m3/s5c73m3.h   |  6 +--
 drivers/media/i2c/s5k4ecgx.c  |  4 +-
 drivers/media/i2c/s5k5baf.c   | 14 +++---
 drivers/media/i2c/s5k6a3.c|  2 +-
 drivers/media/i2c/s5k6aa.c|  8 ++--
 drivers/media/i2c/saa6752hs.c |  6 +--
 drivers/media/i2c/saa7115.c   |  2 +-
 drivers/media/i2c/saa717x.c   |  2 +-
 drivers/media/i2c/smiapp/smiapp-core.c| 32 +++---
 drivers/media/i2c/soc_camera/imx074.c |  8 ++--
 drivers/media/i2c/soc_camera/mt9m001.c| 14 +++---
 drivers/media/i2c/soc_camera/mt9m111.c| 70 +++---
 drivers/media/i2c/soc_camera/mt9t031.c| 10 ++---
 drivers/media/i2c/soc_camera/mt9t112.c| 22 +-
 drivers/media/i2c/soc_camera/mt9v022.c| 26 +--
 drivers/media/i2c/soc_camera/ov2640.c | 54 +++
 drivers/media/i2c/soc_camera/ov5642.c |  8 ++--
 drivers/media/i2c/soc_camera/ov6650.c | 58 -
 drivers/media/i2c/soc_camera/ov772x.c | 20 -
 drivers/media/i2c/soc_camera/ov9640.c | 40 -
 drivers/media/i2c/soc_camera/ov9740.c | 12 +++---
 drivers/media/i2c/soc_camera/rj54n1cb0c.c | 54 +++
 drivers/media/i2c/soc_camera/tw9910.c | 10 ++---
 drivers/media/i2c/sr030pc30.c | 14 +++---
 drivers/media/i2c/tvp514x.c   | 12 +++---
 drivers/media/i2c/tvp5150.c   |  6 +--
 drivers/media/i2c/tvp7002.c   | 10 ++---
 drivers/media/i2c/vs6624.c| 18 
 46 files changed, 382 insertions(+), 382 deletions(-)

diff --git a/drivers/media/i2c/adv7170.c b/drivers/media/i2c/adv7170.c
index 04bb297..40a1a95 100644
--- a/drivers/media/i2c/adv7170.c
+++ b/drivers/media/i2c/adv7170.c
@@ -63,9 +63,9 @@ static inline struct adv7170 *to_adv7170(struct v4l2_subdev 
*sd)
 
 static char *inputs[] = { pass_through, play_back };
 
-static enum v4l2_mbus_pixelcode adv7170_codes[] = {
-   V4L2_MBUS_FMT_UYVY8_2X8,
-   V4L2_MBUS_FMT_UYVY8_1X16,
+static u32 adv7170_codes[] = {
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_UYVY8_1X16,
 };
 
 /* --- */
@@ -263,7 +263,7 @@ static int adv7170_s_routing(struct v4l2_subdev *sd,
 }
 
 static int adv7170_enum_fmt(struct v4l2_subdev *sd, unsigned int index,
-   enum v4l2_mbus_pixelcode *code)
+   u32 *code)
 {
if (index = ARRAY_SIZE(adv7170_codes))
return -EINVAL;
@@ -278,9 +278,9 @@ static int adv7170_g_fmt(struct v4l2_subdev *sd,
u8 val = adv7170_read(sd, 0x7);
 
if ((val  0x40) == (1  6))
-   mf-code = V4L2_MBUS_FMT_UYVY8_1X16;
+   mf-code = MEDIA_BUS_FMT_UYVY8_1X16;
else
-   mf-code = V4L2_MBUS_FMT_UYVY8_2X8;
+   mf-code = MEDIA_BUS_FMT_UYVY8_2X8;
 
mf-colorspace  = V4L2_COLORSPACE_SMPTE170M;
mf-width   = 0;
@@ -297,11 +297,11 @@ static int adv7170_s_fmt(struct v4l2_subdev *sd,
int ret;
 
switch (mf-code) {
-   case V4L2_MBUS_FMT_UYVY8_2X8:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
val = ~0x40;
break;
 
-   case V4L2_MBUS_FMT_UYVY8_1X16:
+   case MEDIA_BUS_FMT_UYVY8_1X16:
val |= 0x40;
break;
 
diff --git a/drivers/media/i2c/adv7175.c b/drivers/media/i2c/adv7175.c
index b88f3b3..d220af5 100644
--- a/drivers/media/i2c/adv7175.c
+++ b/drivers/media/i2c/adv7175.c
@@ -60,9 +60,9 @@ static inline struct adv7175

[PATCH v3 02/10] [media] v4l: Update subdev-formats doc with new MEDIA_BUS_FMT values

2014-11-07 Thread Boris Brezillon
In order to have subsytem agnostic media bus format definitions we've
moved media bus definition to include/uapi/linux/media-bus-format.h and
prefixed them with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.

Update the v4l documentation accordingly.

Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
 Documentation/DocBook/media/v4l/subdev-formats.xml | 308 ++---
 1 file changed, 154 insertions(+), 154 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index b2d5a03..18730b9 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -86,7 +86,7 @@
   green and 5-bit blue values padded on the high bit, transferred as 2 
8-bit
   samples per pixel with the most significant bits (padding, red and half 
of
   the green value) transferred first will be named
-  constantV4L2_MBUS_FMT_RGB555_2X8_PADHI_BE/constant.
+  constantMEDIA_BUS_FMT_RGB555_2X8_PADHI_BE/constant.
   /para
 
   paraThe following tables list existing packed RGB formats./para
@@ -176,8 +176,8 @@
/row
  /thead
  tbody valign=top
-   row id=V4L2-MBUS-FMT-RGB444-2X8-PADHI-BE
- entryV4L2_MBUS_FMT_RGB444_2X8_PADHI_BE/entry
+   row id=MEDIA-BUS-FMT-RGB444-2X8-PADHI-BE
+ entryMEDIA_BUS_FMT_RGB444_2X8_PADHI_BE/entry
  entry0x1001/entry
  entry/entry
  dash-ent-24;
@@ -204,8 +204,8 @@
  entrybsubscript1/subscript/entry
  entrybsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB444-2X8-PADHI-LE
- entryV4L2_MBUS_FMT_RGB444_2X8_PADHI_LE/entry
+   row id=MEDIA-BUS-FMT-RGB444-2X8-PADHI-LE
+ entryMEDIA_BUS_FMT_RGB444_2X8_PADHI_LE/entry
  entry0x1002/entry
  entry/entry
  dash-ent-24;
@@ -232,8 +232,8 @@
  entryrsubscript1/subscript/entry
  entryrsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB555-2X8-PADHI-BE
- entryV4L2_MBUS_FMT_RGB555_2X8_PADHI_BE/entry
+   row id=MEDIA-BUS-FMT-RGB555-2X8-PADHI-BE
+ entryMEDIA_BUS_FMT_RGB555_2X8_PADHI_BE/entry
  entry0x1003/entry
  entry/entry
  dash-ent-24;
@@ -260,8 +260,8 @@
  entrybsubscript1/subscript/entry
  entrybsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB555-2X8-PADHI-LE
- entryV4L2_MBUS_FMT_RGB555_2X8_PADHI_LE/entry
+   row id=MEDIA-BUS-FMT-RGB555-2X8-PADHI-LE
+ entryMEDIA_BUS_FMT_RGB555_2X8_PADHI_LE/entry
  entry0x1004/entry
  entry/entry
  dash-ent-24;
@@ -288,8 +288,8 @@
  entrygsubscript4/subscript/entry
  entrygsubscript3/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-BGR565-2X8-BE
- entryV4L2_MBUS_FMT_BGR565_2X8_BE/entry
+   row id=MEDIA-BUS-FMT-BGR565-2X8-BE
+ entryMEDIA_BUS_FMT_BGR565_2X8_BE/entry
  entry0x1005/entry
  entry/entry
  dash-ent-24;
@@ -316,8 +316,8 @@
  entryrsubscript1/subscript/entry
  entryrsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-BGR565-2X8-LE
- entryV4L2_MBUS_FMT_BGR565_2X8_LE/entry
+   row id=MEDIA-BUS-FMT-BGR565-2X8-LE
+ entryMEDIA_BUS_FMT_BGR565_2X8_LE/entry
  entry0x1006/entry
  entry/entry
  dash-ent-24;
@@ -344,8 +344,8 @@
  entrygsubscript4/subscript/entry
  entrygsubscript3/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB565-2X8-BE
- entryV4L2_MBUS_FMT_RGB565_2X8_BE/entry
+   row id=MEDIA-BUS-FMT-RGB565-2X8-BE
+ entryMEDIA_BUS_FMT_RGB565_2X8_BE/entry
  entry0x1007/entry
  entry/entry
  dash-ent-24;
@@ -372,8 +372,8 @@
  entrybsubscript1/subscript/entry
  entrybsubscript0/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB565-2X8-LE
- entryV4L2_MBUS_FMT_RGB565_2X8_LE/entry
+   row id=MEDIA-BUS-FMT-RGB565-2X8-LE
+ entryMEDIA_BUS_FMT_RGB565_2X8_LE/entry
  entry0x1008/entry
  entry/entry
  dash-ent-24;
@@ -400,8 +400,8 @@
  entrygsubscript4/subscript/entry
  entrygsubscript3/subscript/entry
/row
-   row id=V4L2-MBUS-FMT-RGB666-1X18
- entryV4L2_MBUS_FMT_RGB666_1X18/entry
+   row id=MEDIA-BUS-FMT-RGB666-1X18
+ entryMEDIA_BUS_FMT_RGB666_1X18/entry
  entry0x1009/entry
  entry/entry
  dash-ent-14;
@@ -424,8 +424,8 @@
  entrybsubscript1/subscript

  1   2   >