Re: [RFC] pinctrl: sh-pfc: only use dummy states for non-DT platforms

[Shawn Guo]

On Mon, Mar 07, 2016 at 10:00:37PM +0100, Geert Uytterhoeven wrote:
> CC Shawn, Sascha for imx1

Sorry for the late response.

> 
> On Mon, Mar 7, 2016 at 9:34 PM, Sergei Shtylyov
>  wrote:
> > On 03/07/2016 11:29 PM, Geert Uytterhoeven wrote:
> >
> > --- a/drivers/pinctrl/sh-pfc/core.c
> > +++ b/drivers/pinctrl/sh-pfc/core.c
> > @@ -545,7 +545,9 @@ static int sh_pfc_probe(struct platform_device
> > *pdev)
> >   return ret;
> >   }
> >
> > -   pinctrl_provide_dummies();
> > +   /* Enable dummy states for those platforms without pinctrl
> > support */
> > +   if (!of_have_populated_dt())
> >>>
> >>>
> >>> I'd considered this condition -- it won't fly on SH where
> >>> CONFIG_OF=n,
> >>> the kernel just won't build IIUC...
> >>
> >>
> >> I haven't tried to compile it yet, but  does provide a dummy
> >> that
> >> returns false.
> >
> >
> >Oops, indeed. I missed it. :-(
> >This approach is better then, won't have to fix again whenever SH gets DT
> > support.
> 
> Perhaps the of_have_populated_dt() check should be moved inside
> pinctrl_provide_dummies()?
> 
> Besides omap2, which has its own check, the only other user is imx1.
> Does imx1 (still) needs this on DT-based platforms?
> 
> (Context for Shawn and Sascha:
>  http://article.gmane.org/gmane.linux.kernel.renesas-soc/1639)

pinctrl_provide_dummies() is only used on a few legacy i.MX platforms
for non-DT boot, so it should be safe to move the check inside the
function from i.MX view.

Shawn

[PATCH] thermal: rcar: Remove binding docs for r8a7794

[Simon Horman]

The latest information that I have is that there is no thermal IP
block present on the r8a7794 SoC so remove the corresponding binding.

Cc: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
index e5ee3f159893..a8e52c8ccfcc 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
@@ -11,7 +11,6 @@ Required properties:
- "renesas,thermal-r8a7791" (R-Car M2-W)
- "renesas,thermal-r8a7792" (R-Car V2H)
- "renesas,thermal-r8a7793" (R-Car M2-N)
-   - "renesas,thermal-r8a7794" (R-Car E2)
 - reg  : Address range of the thermal registers.
  The 1st reg will be recognized as common register
  if it has "interrupts".
-- 
2.1.4

Re: [PATCH] drivers: sh: Use ARCH_RENESAS

[Simon Horman]

On Mon, Mar 28, 2016 at 09:16:51AM -0400, Rich Felker wrote:
> On Wed, Mar 02, 2016 at 09:25:54AM +0100, Geert Uytterhoeven wrote:
> > Hi Simon,
> > 
> > On Wed, Mar 2, 2016 at 2:43 AM, Simon Horman  
> > wrote:
> > > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
> > >
> > > This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> > > ARCH_RENESAS the motivation for which being that RENESAS seems to be a 
> > > more
> > > appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
> > >
> > > ARCH_RENESAS should cover all cases where both CONFIG_OF and
> > > ARCH_SHMOBILE are enabled.
> > >
> > > Signed-off-by: Simon Horman 
> > 
> > Acked-by: Geert Uytterhoeven 
> > 
> > If you intend to drop ARCH_SHMOBILE from arch/arm/mach-shmobile/Kconfig 
> > before
> > dropping the whole "if (...) { ... }" block below" (cfr. "drivers: sh: Stop
> > using the legacy clock domain on ARM",
> > http://www.spinics.net/lists/linux-renesas-soc/msg00869.html).
> > 
> > Note that the SH-people may resurrect (a variant of) the block when they 
> > start
> > migrating to DT and CCF.
> 
> I can't say for sure at this point, but I think instead of searching
> for a node by compatible I would want to represent the relationship
> between the nodes semantically in the device tree. We can address that
> when we get there, though. If we're stuck with device-provided device
> trees that don't fully represent the relationships we might have to
> keep kludges for searching.

Thanks for the feedback.

At this point I think it would be best to drop the block in question.
It should not be difficult to add it back if and when it is needed again.

Re: [PATCH v2 01/54] media: Add video processing entity functions

[Sakari Ailus]

Hi Laurent,

On Fri, Mar 25, 2016 at 12:43:35PM +0200, Laurent Pinchart wrote:
> Add composer, format converter and scaler functions, as well as generic
> video processing to be used when no other processing function is
> applicable.

How are these intended to be used?

Say, if a sub-device implements functionality that matches more than one of
these, do you pick one?

Supposedly you control at least some of this functionality using the
selections API, and frankly, I think the way it's currently defined in the
spec worked okay-ish for the devices at hand at the time, but defining that
the order of processing from the sink towards the source is sink crop, sink
compose and then source crop is not generic. We should have a better way to
tell this, using a similar API which is used to control the functionality,
just as is done with V4L2 controls.

> 
> Signed-off-by: Laurent Pinchart 
> ---
>  Documentation/DocBook/media/v4l/media-types.xml | 34 
> +
>  include/uapi/linux/media.h  |  8 ++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/Documentation/DocBook/media/v4l/media-types.xml 
> b/Documentation/DocBook/media/v4l/media-types.xml
> index 5e3f20fdcf17..a6e171e80bce 100644
> --- a/Documentation/DocBook/media/v4l/media-types.xml
> +++ b/Documentation/DocBook/media/v4l/media-types.xml
> @@ -121,6 +121,40 @@
>   MEDIA_ENT_F_AUDIO_MIXER
>   Audio Mixer Function Entity.
> 
> +   
> + MEDIA_ENT_F_PROC_VIDEO_GENERIC
> + Generic video processing, when no other processing function
> +is applicable.
> + 
> +   
> + MEDIA_ENT_F_PROC_VIDEO_COMPOSER
> + Video composer (blender). An entity capable of video
> +composing must have at least two sink pads and one source
> +pad, and composes input video frames onto output video
> +frames. Composition can be performed using alpha blending,
> +color keying, raster operations (ROP), stitching or any other
> +mean.
> + 
> +   
> +   
> + MEDIA_ENT_F_PROC_VIDEO_CONVERTER
> + Video format converter. An entity capable of video format
> +conversion must have at least one sink pad and one source
> +pad, and convert the format of pixels received on its sink
> +pad(s) to a different format output on its source pad(s).
> + 
> +   
> +   
> + MEDIA_ENT_F_PROC_VIDEO_SCALER
> + Video scaler. An entity capable of video scaling must have
> +at least one sink pad and one source pad, and scaling the
> +video frame(s) received on its sink pad(s) to a different
> +resolution output on its source pad(s). The range of
> +supported scaling ratios is entity-specific and can differ
> +between the horizontal and vertical directions. In particular
> +scaling can be supported in one direction only.
> + 
> +   
>   
>
>  
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index df59edee25d1..884ec1cae09d 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -95,6 +95,14 @@ struct media_device_info {
>  #define MEDIA_ENT_F_AUDIO_MIXER  (MEDIA_ENT_F_BASE + 0x03003)
>  
>  /*
> + * Processing entities
> + */
> +#define MEDIA_ENT_F_PROC_VIDEO_GENERIC   (MEDIA_ENT_F_BASE + 
> 0x4001)
> +#define MEDIA_ENT_F_PROC_VIDEO_COMPOSER  (MEDIA_ENT_F_BASE + 
> 0x4002)
> +#define MEDIA_ENT_F_PROC_VIDEO_CONVERTER (MEDIA_ENT_F_BASE + 0x4003)
> +#define MEDIA_ENT_F_PROC_VIDEO_SCALER(MEDIA_ENT_F_BASE + 
> 0x4004)
> +
> +/*
>   * Connectors
>   */
>  /* It is a responsibility of the entity drivers to add connectors and links 
> */

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v8 net-next] ravb: Add dma queue interrupt support

[Yoshihiro Kaneko]

Hello.

2016-03-27 22:02 GMT+09:00 Sergei Shtylyov :
> Hello.
>
>
> On 03/22/2016 06:22 PM, Yoshihiro Kaneko wrote:
>
>> From: Kazuya Mizuguchi 
>>
>> This patch supports the following interrupts.
>>
>> - One interrupt for multiple (timestamp, error, gPTP)
>> - One interrupt for emac
>> - Four interrupts for dma queue (best effort rx/tx, network control rx/tx)
>>
>> This patch improve efficiency of the interrupt handler by adding the
>> interrupt handler corresponding to each interrupt source described
>> above. Additionally, it reduces the number of times of the access to
>> EthernetAVB IF.
>> Also this patch prevent this driver depends on the whim of a boot loader.
>>
>> [ykaneko0...@gmail.com: define bit names of registers]
>> [ykaneko0...@gmail.com: add comment for gen3 only registers]
>> [ykaneko0...@gmail.com: fix coding style]
>> [ykaneko0...@gmail.com: update changelog]
>> [ykaneko0...@gmail.com: gen3: fix initialization of interrupts]
>> [ykaneko0...@gmail.com: gen3: fix clearing interrupts]
>> [ykaneko0...@gmail.com: gen3: add helper function for request_irq()]
>> [ykaneko0...@gmail.com: gen3: remove IRQF_SHARED flag for request_irq()]
>> [ykaneko0...@gmail.com: revert ravb_close() and ravb_ptp_stop()]
>> [ykaneko0...@gmail.com: avoid calling free_irq() to non-hooked interrupts]
>> [ykaneko0...@gmail.com: make NC/BE interrupt handler a function]
>> [ykaneko0...@gmail.com: make timestamp interrupt handler a function]
>> [ykaneko0...@gmail.com: timestamp interrupt is handled in multiple
>>   interrupt handler instead of dma queue interrupt handler]
>> Signed-off-by: Kazuya Mizuguchi 
>> Signed-off-by: Yoshihiro Kaneko 
>
> [...]
>
> Acked-by: Sergei Shtylyov 

Many thanks for your review and much help!

>
> MBR, Sergei
>

Thanks,
kaneko

Re: [PATCH] drivers: sh: Use ARCH_RENESAS

[Rich Felker]

On Wed, Mar 02, 2016 at 09:25:54AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Wed, Mar 2, 2016 at 2:43 AM, Simon Horman  
> wrote:
> > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
> >
> > This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> > ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
> > appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
> >
> > ARCH_RENESAS should cover all cases where both CONFIG_OF and
> > ARCH_SHMOBILE are enabled.
> >
> > Signed-off-by: Simon Horman 
> 
> Acked-by: Geert Uytterhoeven 
> 
> If you intend to drop ARCH_SHMOBILE from arch/arm/mach-shmobile/Kconfig before
> dropping the whole "if (...) { ... }" block below" (cfr. "drivers: sh: Stop
> using the legacy clock domain on ARM",
> http://www.spinics.net/lists/linux-renesas-soc/msg00869.html).
> 
> Note that the SH-people may resurrect (a variant of) the block when they start
> migrating to DT and CCF.

I can't say for sure at this point, but I think instead of searching
for a node by compatible I would want to represent the relationship
between the nodes semantically in the device tree. We can address that
when we get there, though. If we're stuck with device-provided device
trees that don't fully represent the relationships we might have to
keep kludges for searching.

Rich

Re: [PATCH 0/4 v3] drm: Introduce drm_connector_register_all() helper

[Alexey Brodkin]

Hi Daniel,

On Wed, 2016-03-23 at 11:37 +0100, Daniel Vetter wrote:
> On Wed, Mar 23, 2016 at 11:42:53AM +0300, Alexey Brodkin wrote:
> > 
> > As a pair to already existing drm_connector_unplug_all()
> > (which we'll rename in this series to drm_connector_unregister_all())
> > we're adding generic implementation of what is already done in some drivers
> > for registering all connectors.
> > 
> > After implementation of that new helper we're updating 2 drivers
> > that used to use it's own implementation:
> >  [1] atmel_hlcdc
> >  [2] rcar_du
> > 
> > And one driver that uses unregister():
> >  [1] udl
> > 
> > Other drivers still use load() callback and so should be first modified so
> > their load() gets called from their probe() explicitly.
> > 
> > Build- and run-tested on yet to be upstreamed ARC PGU (part of AXS10x 
> > board).
> > 
> > Changes v2 -> v3:
> >  * Added acks for 1, 3 and 4 patches
> >  * Updated kerneldoc descriptins of both register_ and unregister_all()
> >  * Updated commit messages (mostly spellos and grammar issues)
> > 
> > Changes v1 -> v2:
> >  * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
> >  * Use drm_for_each_connector() instead of list_for_each_entry()
> >  * Updated kerneldoc for drm_dev_register()
> > 
> > Alexey Brodkin (4):
> >   drm: Rename drm_connector_unplug_all() to
> > drm_connector_unregister_all()
> >   drm: Introduce drm_connector_register_all() helper
> >   drm: atmel_hldc: Use generic drm_connector_register_all() helper
> >   drm: rcar-du: Use generic drm_connector_register_all() helper
> lgtm overall, but merge window is happening so don't want to throw 4.7
> patches into drm-misc. So will let these soak for a while more, please
> ping me after -rc1 is out that I don't forget them.

As you asked I'm pinging you with request to apply that series.

Also would be very nice if you take a look at that comment from
David Herrmann before application of that series:
http://article.gmane.org/gmane.comp.video.dri.devel/149708/match=re+patch+2+4+v3+drm+introduce+drm_connector_register_al
l+helper

-Alexey