Re: [PATCH/RFC 1/9] clk: shmobile: r8a7795: Add FCP clocks
Hi Morimoto-sa, On Thursday 03 March 2016 07:19:20 Kuninori Morimoto wrote: > Hi Laurent > > >> It seems FCP clock is based on each SoC > >> In H3 ES1 case, it is using > >> > >> - s2d2 (for 200MHz) > >> - s2d1 (for 400MHz) > > > > Thank you for the information. Do you mean that different FCP instances > > use different clocks ? If so, could you tell us which clock is used by > > each instance in th H3 ES1 ? > > Sorry for my confusable mail. > All FCP on H3 ES1 is using above, > but, M3 or E3 will use different clock. > > Is this more clear ? Does it mean that every FCP instance uses both the S2D2 and the S2D1 clocks as functional clocks on H3 ES1 ? -- Regards, Laurent Pinchart
Re: [PATCH/RFC 1/9] clk: shmobile: r8a7795: Add FCP clocks
Hi Laurent > > It seems FCP clock is based on each SoC > > In H3 ES1 case, it is using > > - s2d2 (for 200MHz) > > - s2d1 (for 400MHz) > > Thank you for the information. Do you mean that different FCP instances use > different clocks ? If so, could you tell us which clock is used by each > instance in th H3 ES1 ? Sorry for my confusable mail. All FCP on H3 ES1 is using above, but, M3 or E3 will use different clock. Is this more clear ?
Re: [PATCH/RFC 1/9] clk: shmobile: r8a7795: Add FCP clocks
Hi Morimoto-san, On Thursday 03 March 2016 00:17:54 Kuninori Morimoto wrote: > Hi Laurent > > >>> The parent clock isn't documented in the datasheet, use S2D1 as a best > >>> guess for now. > >> > >> Would you be able to find out what the parent clock is for the FCP and > >> LVDS (patch 2/9) clocks ? > > It seems FCP clock is based on each SoC > In H3 ES1 case, it is using > - s2d2 (for 200MHz) > - s2d1 (for 400MHz) Thank you for the information. Do you mean that different FCP instances use different clocks ? If so, could you tell us which clock is used by each instance in th H3 ES1 ? -- Regards, Laurent Pinchart
[PATCH] dmaengine: rcar-dmac: clear pertinence number of channels
From: Kuninori Morimoto DMACHCLR clears each channels, but its channel number is based on its SoC or IP. Current driver is using fixed 0x7fff (= for 14ch), it is not good match for Gen3 or Gen2 Audio DMAC. This patch fixes it Signed-off-by: Kuninori Morimoto --- drivers/dma/sh/rcar-dmac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c index 57a6dfc9..02b86c6 100644 --- a/drivers/dma/sh/rcar-dmac.c +++ b/drivers/dma/sh/rcar-dmac.c @@ -422,7 +422,7 @@ static int rcar_dmac_init(struct rcar_dmac *dmac) u16 dmaor; /* Clear all channels and enable the DMAC globally. */ - rcar_dmac_write(dmac, RCAR_DMACHCLR, 0x7fff); + rcar_dmac_write(dmac, RCAR_DMACHCLR, GENMASK(dmac->n_channels - 1, 0)); rcar_dmac_write(dmac, RCAR_DMAOR, RCAR_DMAOR_PRI_FIXED | RCAR_DMAOR_DME); -- 1.9.1
Re: [PATCH] clk: shmobile: Remove ARCH_SHMOBILE_MULTI
On Thu, Feb 25, 2016 at 03:44:34PM -0800, Stephen Boyd wrote:
> On 02/23, Simon Horman wrote:
> > On Tue, Feb 23, 2016 at 09:19:27AM +0100, Geert Uytterhoeven wrote:
> > > CC The New Mike ;-)
> > >
> > > On Tue, Feb 23, 2016 at 1:57 AM, Simon Horman
> > > wrote:
> > > > As of 9b5ba0df4ea4 ("ARM: shmobile: Introduce ARCH_RENESAS") all
> > > > platforms
> > > > that use Renesas clock drivers now select ARCH_RENESAS. As it is
> > > > present in
> > > > drivers/clk/Makefile ARCH_SHMOBILE_MULTI may now be removed.
> > > >
> > > > 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.
> > > >
> > > > Signed-off-by: Simon Horman
> > >
> > > Acked-by: Geert Uytterhoeven
> > >
>
> Applied to clk-next
>
> > > > drivers/clk/Makefile | 1 -
> > > > 1 file changed, 1 deletion(-)
> > > >
> > > > Based on clk-next
> > > >
> > > > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> > > > index bae4be6501df..b19af449d2f3 100644
> > > > --- a/drivers/clk/Makefile
> > > > +++ b/drivers/clk/Makefile
> > > > @@ -70,7 +70,6 @@ obj-$(CONFIG_COMMON_CLK_PXA) += pxa/
> > > > obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/
> > > > obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
> > > > obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/
> > > > -obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += shmobile/
> > >
> > > Should we rename clk/shmobile/ to clk/renesas/?
> > > Or is that too much of a hassle?
> >
> > I think it is a good idea. And I suspect it shouldn't be too difficult if
> > we coordinate things with Mike to handle any in-flight patches for that
> > directory.
>
> Feel free to send the patch.
Done :)
Re: [PATCH 6/6] watchdog: tangox_wdt: test clock rate to avoid division by 0
On Wed, Mar 02, 2016 at 11:33:37PM +0100, Wolfram Sang wrote: > From: Wolfram Sang > > The clk API may return 0 on clk_get_rate, so we should check the result before > using it as a divisor. > > Signed-off-by: Wolfram Sang > --- > > Should go individually via subsystem tree. > > drivers/watchdog/tangox_wdt.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/watchdog/tangox_wdt.c b/drivers/watchdog/tangox_wdt.c > index 709c1ed6fd79b9..cc702718ae4dbb 100644 > --- a/drivers/watchdog/tangox_wdt.c > +++ b/drivers/watchdog/tangox_wdt.c > @@ -139,6 +139,8 @@ static int tangox_wdt_probe(struct platform_device *pdev) > return err; > > dev->clk_rate = clk_get_rate(dev->clk); > + if (!dev->clk_rate) > + return -EINVAL; May be a nitpick, but clk_disable_unprepare() is missing. Guenter > > dev->wdt.parent = &pdev->dev; > dev->wdt.info = &tangox_wdt_info; > -- > 2.7.0 >
Re: [PATCH 5/6] watchdog: atlas7_wdt: test clock rate to avoid division by 0
On Wed, Mar 02, 2016 at 11:33:36PM +0100, Wolfram Sang wrote:
> From: Wolfram Sang
>
> The clk API may return 0 on clk_get_rate, so we should check the result before
> using it as a divisor.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Guenter Roeck
> ---
>
> Should go individually via subsystem tree.
>
> drivers/watchdog/atlas7_wdt.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/watchdog/atlas7_wdt.c b/drivers/watchdog/atlas7_wdt.c
> index df6d9242a31958..ed80734befae16 100644
> --- a/drivers/watchdog/atlas7_wdt.c
> +++ b/drivers/watchdog/atlas7_wdt.c
> @@ -154,6 +154,11 @@ static int atlas7_wdt_probe(struct platform_device *pdev)
> writel(0, wdt->base + ATLAS7_WDT_CNT_CTRL);
>
> wdt->tick_rate = clk_get_rate(clk);
> + if (!wdt->tick_rate) {
> + ret = -EINVAL;
> + goto err1;
> + }
> +
> wdt->clk = clk;
> atlas7_wdd.min_timeout = 1;
> atlas7_wdd.max_timeout = UINT_MAX / wdt->tick_rate;
> --
> 2.7.0
>
[PATCH] clk: renesas: move drivers to renesas directory
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.
Along with the above mentioned Kconfig changes it seems appropriate
to also rename directories that only hold drivers for such SoCs.
Signed-off-by: Simon Horman
---
drivers/clk/Makefile | 2 +-
drivers/clk/{shmobile => renesas}/Makefile | 0
drivers/clk/{shmobile => renesas}/clk-div6.c | 0
drivers/clk/{shmobile => renesas}/clk-div6.h | 0
drivers/clk/{shmobile => renesas}/clk-emev2.c| 0
drivers/clk/{shmobile => renesas}/clk-mstp.c | 0
drivers/clk/{shmobile => renesas}/clk-r8a73a4.c | 0
drivers/clk/{shmobile => renesas}/clk-r8a7740.c | 0
drivers/clk/{shmobile => renesas}/clk-r8a7778.c | 0
drivers/clk/{shmobile => renesas}/clk-r8a7779.c | 0
drivers/clk/{shmobile => renesas}/clk-rcar-gen2.c| 0
drivers/clk/{shmobile => renesas}/clk-rz.c | 0
drivers/clk/{shmobile => renesas}/clk-sh73a0.c | 0
drivers/clk/{shmobile => renesas}/r8a7795-cpg-mssr.c | 0
drivers/clk/{shmobile => renesas}/renesas-cpg-mssr.c | 0
drivers/clk/{shmobile => renesas}/renesas-cpg-mssr.h | 0
16 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/clk/{shmobile => renesas}/Makefile (100%)
rename drivers/clk/{shmobile => renesas}/clk-div6.c (100%)
rename drivers/clk/{shmobile => renesas}/clk-div6.h (100%)
rename drivers/clk/{shmobile => renesas}/clk-emev2.c (100%)
rename drivers/clk/{shmobile => renesas}/clk-mstp.c (100%)
rename drivers/clk/{shmobile => renesas}/clk-r8a73a4.c (100%)
rename drivers/clk/{shmobile => renesas}/clk-r8a7740.c (100%)
rename drivers/clk/{shmobile => renesas}/clk-r8a7778.c (100%)
rename drivers/clk/{shmobile => renesas}/clk-r8a7779.c (100%)
rename drivers/clk/{shmobile => renesas}/clk-rcar-gen2.c (100%)
rename drivers/clk/{shmobile => renesas}/clk-rz.c (100%)
rename drivers/clk/{shmobile => renesas}/clk-sh73a0.c (100%)
rename drivers/clk/{shmobile => renesas}/r8a7795-cpg-mssr.c (100%)
rename drivers/clk/{shmobile => renesas}/renesas-cpg-mssr.c (100%)
rename drivers/clk/{shmobile => renesas}/renesas-cpg-mssr.h (100%)
Based on clk-next
Patch pruduced using git format-patch -M
This produces a patch without the diff of each renamed file
which results in a ~204K patch. Let me know if you would prefer that
or a pull-request.
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 08c0003a7254..46869d696e4d 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -70,7 +70,7 @@ obj-$(CONFIG_COMMON_CLK_PXA) += pxa/
obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/
obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/
-obj-$(CONFIG_ARCH_RENESAS) += shmobile/
+obj-$(CONFIG_ARCH_RENESAS) += renesas/
obj-$(CONFIG_ARCH_SIRF)+= sirf/
obj-$(CONFIG_ARCH_SOCFPGA) += socfpga/
obj-$(CONFIG_PLAT_SPEAR) += spear/
diff --git a/drivers/clk/shmobile/Makefile b/drivers/clk/renesas/Makefile
similarity index 100%
rename from drivers/clk/shmobile/Makefile
rename to drivers/clk/renesas/Makefile
diff --git a/drivers/clk/shmobile/clk-div6.c b/drivers/clk/renesas/clk-div6.c
similarity index 100%
rename from drivers/clk/shmobile/clk-div6.c
rename to drivers/clk/renesas/clk-div6.c
diff --git a/drivers/clk/shmobile/clk-div6.h b/drivers/clk/renesas/clk-div6.h
similarity index 100%
rename from drivers/clk/shmobile/clk-div6.h
rename to drivers/clk/renesas/clk-div6.h
diff --git a/drivers/clk/shmobile/clk-emev2.c b/drivers/clk/renesas/clk-emev2.c
similarity index 100%
rename from drivers/clk/shmobile/clk-emev2.c
rename to drivers/clk/renesas/clk-emev2.c
diff --git a/drivers/clk/shmobile/clk-mstp.c b/drivers/clk/renesas/clk-mstp.c
similarity index 100%
rename from drivers/clk/shmobile/clk-mstp.c
rename to drivers/clk/renesas/clk-mstp.c
diff --git a/drivers/clk/shmobile/clk-r8a73a4.c
b/drivers/clk/renesas/clk-r8a73a4.c
similarity index 100%
rename from drivers/clk/shmobile/clk-r8a73a4.c
rename to drivers/clk/renesas/clk-r8a73a4.c
diff --git a/drivers/clk/shmobile/clk-r8a7740.c
b/drivers/clk/renesas/clk-r8a7740.c
similarity index 100%
rename from drivers/clk/shmobile/clk-r8a7740.c
rename to drivers/clk/renesas/clk-r8a7740.c
diff --git a/drivers/clk/shmobile/clk-r8a7778.c
b/drivers/clk/renesas/clk-r8a7778.c
similarity index 100%
rename from drivers/clk/shmobile/clk-r8a7778.c
rename to drivers/clk/renesas/clk-r8a7778.c
diff --git a/drivers/clk/shmobile/clk-r8a7779.c
b/drivers/clk/renesas/clk-r8a7779.c
similarity index 100%
rename from drivers/clk/shmobile/clk-r8a7779.c
rename to drivers/clk/renesas/clk-r8a7779.c
diff --git a/drivers/clk/shmobile/clk-rcar-gen2.c
b/drivers/clk/renesas/clk-rcar-gen2.c
similarity index 100%
rename from drivers/
[PATCH] media: sh_mobile_ceu_camera, rcar_vin: Use ARCH_RENESAS
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. Signed-off-by: Simon Horman --- drivers/media/platform/soc_camera/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Based on media-tree/master diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig index f2776cd415ca..20ad48458cff 100644 --- a/drivers/media/platform/soc_camera/Kconfig +++ b/drivers/media/platform/soc_camera/Kconfig @@ -36,7 +36,7 @@ config VIDEO_PXA27x config VIDEO_RCAR_VIN tristate "R-Car Video Input (VIN) support" depends on VIDEO_DEV && SOC_CAMERA - depends on ARCH_SHMOBILE || COMPILE_TEST + depends on ARCH_RENESAS || COMPILE_TEST depends on HAS_DMA select VIDEOBUF2_DMA_CONTIG select SOC_CAMERA_SCALE_CROP @@ -53,7 +53,7 @@ config VIDEO_SH_MOBILE_CSI2 config VIDEO_SH_MOBILE_CEU tristate "SuperH Mobile CEU Interface driver" depends on VIDEO_DEV && SOC_CAMERA && HAS_DMA && HAVE_CLK - depends on ARCH_SHMOBILE || SUPERH || COMPILE_TEST + depends on ARCH_RENESAS || SUPERH || COMPILE_TEST depends on HAS_DMA select VIDEOBUF2_DMA_CONTIG select SOC_CAMERA_SCALE_CROP -- 2.1.4
[PATCH] bus: simple-pm-bus: Use ARCH_RENESAS
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. Signed-off-by: Simon Horman --- drivers/bus/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) v4.5-rc1 diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index 129d47bcc5fc..c10c6def1565 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -110,7 +110,7 @@ config OMAP_OCP2SCP config SIMPLE_PM_BUS bool "Simple Power-Managed Bus Driver" depends on OF && PM - depends on ARCH_SHMOBILE || COMPILE_TEST + depends on ARCH_RENESAS || COMPILE_TEST help Driver for transparent busses that don't need a real driver, but where the bus controller is part of a PM domain, or under the control -- 2.1.4
RE: [PATCH] usb: renesas_usbhs: gadget: fix giveback status code in usbhsg_pipe_disable()
Hi Felipe, Oops, I completely forgot this patch. Would you review this patch? Or should I resend it? I confirmed that this patch could be applied on your latest testing/fixes branch. Best regards, Yoshihiro Shimoda > -Original Message- > From: Yoshihiro Shimoda > Sent: Friday, December 25, 2015 8:26 PM > To: gre...@linuxfoundation.org; ba...@ti.com > Cc: linux-...@vger.kernel.org; linux...@vger.kernel.org; Yoshihiro Shimoda > > Subject: [PATCH] usb: renesas_usbhs: gadget: fix giveback status code in > usbhsg_pipe_disable() > > A udc driver should set the giveback status to -ESHUTDOWN in > usb_ep_disable(). Otherwise, a gadget driver (e.g. g_serial) might > request next data wrongly and it is possible to cause kernel panic. > > Signed-off-by: Yoshihiro Shimoda > --- > This patch is based on Felipe's usb.git / testing/fixes branch. > (commit id = 5072cfc40a80cea3749fd3413b3896630d8c787e) > > drivers/usb/renesas_usbhs/mod_gadget.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c > b/drivers/usb/renesas_usbhs/mod_gadget.c > index 657f967..664b263 100644 > --- a/drivers/usb/renesas_usbhs/mod_gadget.c > +++ b/drivers/usb/renesas_usbhs/mod_gadget.c > @@ -561,7 +561,7 @@ static int usbhsg_pipe_disable(struct usbhsg_uep *uep) > if (!pkt) > break; > > - usbhsg_queue_pop(uep, usbhsg_pkt_to_ureq(pkt), -ECONNRESET); > + usbhsg_queue_pop(uep, usbhsg_pkt_to_ureq(pkt), -ESHUTDOWN); > } > > usbhs_pipe_disable(pipe); > -- > 1.9.1
[PATCH] ata: sata_rcar: Use ARCH_RENESAS
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. Signed-off-by: Simon Horman --- drivers/ata/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Based on libata/master diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 861643ea91b5..f1f83e9bf425 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -355,7 +355,7 @@ config SATA_PROMISE config SATA_RCAR tristate "Renesas R-Car SATA support" - depends on ARCH_SHMOBILE || COMPILE_TEST + depends on ARCH_RENESAS || COMPILE_TEST help This option enables support for Renesas R-Car Serial ATA. -- 2.1.4
Re: [PATCH] drivers: sh: Use ARCH_RENESAS
On Thu, Mar 03, 2016 at 09:07:13AM +0900, Simon Horman 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).
>
> At this point that is my intention.
I have queued this patch up for v4.6.
[snip]
[PATCH v2] Input: sh_keysc - Remove dependency on SUPERH
A dependency on ARCH_SHMOBILE seems to be the best option for sh_keysc: * For Super H based SoCs: sh_keysc is used on SH_MIGOR, SH_ECOVEC, SH_KFR2R09, SH_7722_SOLUTION_ENGINE, and SH_7724_SOLUTION_ENGINE, which depend on either CPU_SUBTYPE_SH7722 or CPU_SUBTYPE_SH7724, and both select ARCH_SHMOBILE. * For ARM Based SoCs: Since the removal of legacy (non-multiplatform) support this driver has not been used by any Renesas ARM based SoCs. The Renesas ARM based SoCs currently select ARCH_SHMOBILE, however, it is planned that this will no longer be the case. 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. Signed-off-by: Simon Horman --- Based on v4.5-rc1 v2 * Drop dependency on SUPERH rather than the dependency on ARCH_SHMOBILE as suggested by Geert Uytterhoeven --- drivers/input/keyboard/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig index ddd8148d51d7..509608c95994 100644 --- a/drivers/input/keyboard/Kconfig +++ b/drivers/input/keyboard/Kconfig @@ -560,7 +560,7 @@ config KEYBOARD_SUNKBD config KEYBOARD_SH_KEYSC tristate "SuperH KEYSC keypad support" - depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST + depends on ARCH_SHMOBILE || COMPILE_TEST help Say Y here if you want to use a keypad attached to the KEYSC block on SuperH processors such as sh7722 and sh7343. -- 2.1.4
[PATCH v2 1/2] phy: rcar-gen2: add fallback binding
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
descendant of the former or vice versa.
We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.
For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme being adopted for
drivers for Renesas SoCs.
Signed-off-by: Simon Horman
---
v2
* Use renesas,rcar-gen2-usb-phy rather than renesas,usb-phy-gen2 as
the new compatibility string to fit in with the preferred scheme
for new compatibility string names.
---
Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt | 8 +++-
drivers/phy/phy-rcar-gen2.c | 1 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
index d564ba4f1cf6..feb1c3c102c2 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
@@ -7,6 +7,12 @@ Required properties:
- compatible: "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC.
"renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC.
"renesas,usb-phy-r8a7794" if the device is a part of R8A7794 SoC.
+ "renesas,rcar-gen2-usb-phy" for a generic R-Car Gen2 compatible
device.
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first
+ followed by the generic version.
+
- reg: offset and length of the register block.
- #address-cells: number of address cells for the USB channel subnodes, must
be <1>.
@@ -34,7 +40,7 @@ the USB channel; see the selector meanings below:
Example (Lager board):
usb-phy@e6590100 {
- compatible = "renesas,usb-phy-r8a7790";
+ compatible =
"renesas,usb-phy-r8a7790","renesas,rcar-gen2-usb-phy";
reg = <0 0xe6590100 0 0x100>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/drivers/phy/phy-rcar-gen2.c b/drivers/phy/phy-rcar-gen2.c
index c7a05996d5c1..97d4dd6ea924 100644
--- a/drivers/phy/phy-rcar-gen2.c
+++ b/drivers/phy/phy-rcar-gen2.c
@@ -195,6 +195,7 @@ static const struct of_device_id
rcar_gen2_phy_match_table[] = {
{ .compatible = "renesas,usb-phy-r8a7790" },
{ .compatible = "renesas,usb-phy-r8a7791" },
{ .compatible = "renesas,usb-phy-r8a7794" },
+ { .compatible = "renesas,rcar-gen2-usb-phy" },
{ }
};
MODULE_DEVICE_TABLE(of, rcar_gen2_phy_match_table);
--
2.1.4
[PATCH v2 2/2] phy: rcar-gen3-usb2: add fallback binding
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
descendant of the former or vice versa.
We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.
For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme being adopted for
drivers for Renesas SoCs.
Signed-off-by: Simon Horman
---
v2
* Use renesas,rcar-gen3-usb-phy rather than renesas,usb-phy-gen3 as
the new compatibility string to fit in with the preferred scheme
for new compatibility string names.
---
Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 10 --
drivers/phy/phy-rcar-gen3-usb2.c | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
index eaf7e9b7ce6b..86826ca2fdef 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -6,6 +6,12 @@ This file provides information on what the device node for the
R-Car generation
Required properties:
- compatible: "renesas,usb2-phy-r8a7795" if the device is a part of an R8A7795
SoC.
+ "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 compatible
device.
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first
+ followed by the generic version.
+
- reg: offset and length of the partial USB 2.0 Host register block.
- clocks: clock phandle and specifier pair(s).
- #phy-cells: see phy-bindings.txt in the same directory, must be <0>.
@@ -19,14 +25,14 @@ channel as USB OTG:
Example (R-Car H3):
usb-phy@ee080200 {
- compatible = "renesas,usb2-phy-r8a7795";
+ compatible =
"renesas,usb2-phy-r8a7795","renesas,rcar-gen3-usb2-phy";
reg = <0 0xee080200 0 0x700>;
interrupts = ;
clocks = <&mstp7_clks R8A7795_CLK_EHCI0>;
};
usb-phy@ee0a0200 {
- compatible = "renesas,usb2-phy-r8a7795";
+ compatible =
"renesas,usb2-phy-r8a7795","renesas,rcar-gen3-usb2-phy";
reg = <0 0xee0a0200 0 0x700>;
clocks = <&mstp7_clks R8A7795_CLK_EHCI0>;
};
diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
index bc4f7dd821aa..257be74f93f5 100644
--- a/drivers/phy/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -251,6 +251,7 @@ static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void
*_ch)
static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
{ .compatible = "renesas,usb2-phy-r8a7795" },
+ { .compatible = "renesas,rcar-gen3-usb2-phy" },
{ }
};
MODULE_DEVICE_TABLE(of, rcar_gen3_phy_usb2_match_table);
--
2.1.4
[PATCH v2 0/2] phy: rcar-gen2, rcar-gen3-usb2: add fallback binding
Add fallback compatibility strings for rcar phy drivers. In the case of Renesas R-Car hardware we know that there are generations of SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than r8a7791 but that doesn't imply that the latter is a descendant of the former or vice versa. We can, however, by examining the documentation and behaviour of the hardware at run-time observe that the current driver implementation appears to be compatible with the IP blocks on SoCs within a given generation. For the above reasons and convenience when enabling new SoCs a per-generation fallback compatibility string scheme being adopted for drivers for Renesas SoCs. Changes since v1: * Update new compatibility strings to match the preferred scheme for ordering elements * Rebase Based on linux-phy/next Simon Horman (2): phy: rcar-gen2: add fallback binding phy: rcar-gen3-usb2: add fallback binding Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt | 8 +++- Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 10 -- drivers/phy/phy-rcar-gen2.c | 1 + drivers/phy/phy-rcar-gen3-usb2.c | 1 + 4 files changed, 17 insertions(+), 3 deletions(-) -- 2.1.4
Re: [PATCH v2] media: platform: rcar_jpu, sh_vou, vsp1: Use ARCH_RENESAS
On Wed, Mar 02, 2016 at 12:32:39PM +0100, Hans Verkuil wrote: > Hi Simon, > > Note that the patch subject still mentions sh_vou. > > Otherwise: > > Acked-by: Hans Verkuil [snip] On Wed, Mar 02, 2016 at 04:17:10PM +0300, Sergei Shtylyov wrote: [snip] > >v2 > >* Do not update VIDEO_SH_VOU to use ARCH_RENESAS as this is > > used by some SH-based platforms and is not used by any ARM-based platforms > > so a dependency on ARCH_SHMOBILE is correct for that driver > >You forgot to remove it from the subject though. [snip] Thanks, I have posted v3 with sh_vou removed from the subject line.
[PATCH v3] media: platform: rcar_jpu, vsp1: Use ARCH_RENESAS
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. Acked-by: Geert Uytterhoeven Acked-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Simon Horman --- Based on media-tree/master v3 * Update subject to not refer to sh_vou * Added acks from Laurent Pinchart and Hans Verkuil v2 * Do not update VIDEO_SH_VOU to use ARCH_RENESAS as this is used by some SH-based platforms and is not used by any ARM-based platforms so a dependency on ARCH_SHMOBILE is correct for that driver * Added Geert Uytterhoeven's Ack --- drivers/media/platform/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 201f5c296a95..84e041c0a70e 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -238,7 +238,7 @@ config VIDEO_SH_VEU config VIDEO_RENESAS_JPU tristate "Renesas JPEG Processing Unit" depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA - depends on ARCH_SHMOBILE || COMPILE_TEST + depends on ARCH_RENESAS || COMPILE_TEST select VIDEOBUF2_DMA_CONTIG select V4L2_MEM2MEM_DEV ---help--- @@ -250,7 +250,7 @@ config VIDEO_RENESAS_JPU config VIDEO_RENESAS_VSP1 tristate "Renesas VSP1 Video Processing Engine" depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA - depends on (ARCH_SHMOBILE && OF) || COMPILE_TEST + depends on (ARCH_RENESAS && OF) || COMPILE_TEST select VIDEOBUF2_DMA_CONTIG ---help--- This is a V4L2 driver for the Renesas VSP1 video processing engine. -- 2.1.4
Re: [PATCH/RFC 1/9] clk: shmobile: r8a7795: Add FCP clocks
Hi Laurent > > > The parent clock isn't documented in the datasheet, use S2D1 as a best > > > guess for now. > > > > Would you be able to find out what the parent clock is for the FCP and LVDS > > (patch 2/9) clocks ? It seems FCP clock is based on each SoC In H3 ES1 case, it is using - s2d2 (for 200MHz) - s2d1 (for 400MHz)
Re: [PATCH 1/2] phy: rcar-gen2: add fallback binding
On Wed, Mar 02, 2016 at 10:37:31AM +0100, Geert Uytterhoeven wrote: > On Wed, Mar 2, 2016 at 3:37 AM, Simon Horman > wrote: > > In the case of Renesas R-Car hardware we know that there are generations of > > SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the > > relationship between IP blocks might be. For example, I believe that > > r8a7790 is older than r8a7791 but that doesn't imply that the latter is a > > descendant of the former or vice versa. > > > > We can, however, by examining the documentation and behaviour of the > > hardware at run-time observe that the current driver implementation appears > > to be compatible with the IP blocks on SoCs within a given generation. > > > > For the above reasons and convenience when enabling new SoCs a > > per-generation fallback compatibility string scheme being adopted for > > drivers for Renesas SoCs. > > > > Signed-off-by: Simon Horman > > > --- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt > > +++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt > > @@ -7,6 +7,12 @@ Required properties: > > - compatible: "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 > > SoC. > > "renesas,usb-phy-r8a7791" if the device is a part of R8A7791 > > SoC. > > "renesas,usb-phy-r8a7794" if the device is a part of R8A7794 > > SoC. > > + "renesas,usb-phy-gen2" for a generic R-Car Gen2 compatible > > device. > > "renesas,rcar-gen2-usb-phy"? I seem to always get these backwards first go :( I'll update this and the following patch as you suggest.
Re: [PATCH] phy: rcar-gen3-usb2, rcar-gen2: Use ARCH_RENESAS
On Wed, Mar 02, 2016 at 10:36:33AM +0100, Geert Uytterhoeven wrote:
> On Wed, Mar 2, 2016 at 3:25 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.
> >
> > Signed-off-by: Simon Horman
>
> Acked-by: Geert Uytterhoeven
>
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -113,14 +113,14 @@ config PHY_MIPHY365X
> >
> > config PHY_RCAR_GEN2
> > tristate "Renesas R-Car generation 2 USB PHY driver"
> > - depends on ARCH_SHMOBILE
> > + depends on ARCH_RENESAS
> > depends on GENERIC_PHY
> > help
> > Support for USB PHY found on Renesas R-Car generation 2 SoCs.
> >
> > config PHY_RCAR_GEN3_USB2
> > tristate "Renesas R-Car generation 3 USB 2.0 PHY driver"
> > - depends on OF && ARCH_SHMOBILE
> > + depends on OF && ARCH_RENESAS
>
> FWIW, you may want to drop the dependency on OF, as this is implied by
> ARCH_RENESAS.
> Or you can handle that when adding/testing COMPILE_TEST support ;-)
So the ideal setup would be as follows?
depends on ARCH_RENESAS || (OF && COMPILE_TEST)
If so I think I would like to update this patch to:
depends on ARCH_RENESAS
And then deal with COMPILE_TEST separately: I should probably
sweep the tree for Renesas related drivers that do have a COMPILE_TEST
dependency.
> > select GENERIC_PHY
> > help
> > Support for USB 2.0 PHY found on Renesas R-Car generation 3 SoCs.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH] Remove ARCH_SHMOBILE
On Wed, Mar 02, 2016 at 04:18:48PM +0300, Sergei Shtylyov wrote: > I think you forgot a proper prefix in the subject... Indeed, sorry about that.
Re: [PATCH] drivers: sh: Use ARCH_RENESAS
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).
At this point that is my intention.
> Note that the SH-people may resurrect (a variant of) the block when they start
> migrating to DT and CCF.
Yes, I considered that too.
> > ---
> > drivers/sh/pm_runtime.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Based on v4.5-rc6
> >
> > diff --git a/drivers/sh/pm_runtime.c b/drivers/sh/pm_runtime.c
> > index a9bac3bf20de..aa2ce227e3eb 100644
> > --- a/drivers/sh/pm_runtime.c
> > +++ b/drivers/sh/pm_runtime.c
> > @@ -34,7 +34,7 @@ static struct pm_clk_notifier_block platform_bus_notifier
> > = {
> >
> > static int __init sh_pm_runtime_init(void)
> > {
> > - if (IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_ARCH_SHMOBILE)) {
> > + if (IS_ENABLED(CONFIG_ARCH_RENESAS)) {
> > if (!of_find_compatible_node(NULL, NULL,
> > "renesas,cpg-mstp-clocks"))
> > return 0;
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH] iommu/ipmmu-vmsa: Add r8a7795 DT binding
On Thu, Mar 03, 2016 at 12:46:30AM +0900, Magnus Damm wrote: > On Wed, Mar 2, 2016 at 11:55 PM, Joerg Roedel wrote: > > On Mon, Feb 29, 2016 at 11:33:09PM +0900, Magnus Damm wrote: > >> From: Magnus Damm > >> > >> Update the IPMMU DT binding documentation to include the r8a7795 compat > >> string as well as the "renesas,ipmmu-main" property that on r8a7795 will > >> be used to describe the topology and the relationship between the various > >> cache IPMMU instances and the main IPMMU. > >> > >> Signed-off-by: Magnus Damm > >> --- > >> > >> Written against linux-next tag next-20160229 > >> > >> Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 15 > >> -- > >> 1 file changed, 13 insertions(+), 2 deletions(-) > > > > Through which tree should this go? > > Unless anyone objects may I suggest going through your tree please! FWIW that would be my preferred option.
Re: [PATCH 2/2] net: ethernet: renesas: sh_eth: don't open code of_device_get_match_data()
On Wed, Mar 02, 2016 at 07:46:24AM +0100, Wolfram Sang wrote:
> On Wed, Mar 02, 2016 at 10:21:34AM +0900, Simon Horman wrote:
> > On Tue, Mar 01, 2016 at 05:37:59PM +0100, Wolfram Sang wrote:
> > > From: Wolfram Sang
> > >
> > > This change will also make Coverity happy by avoiding a theoretical NULL
> > > pointer dereference; yet another reason is to use the above helper
> > > function
> > > to tighten the code and make it more readable.
> > >
> > > Signed-off-by: Wolfram Sang
> > > ---
> > >
> > > Tested on a Lager board.
> > >
> > > drivers/net/ethernet/renesas/sh_eth.c | 10 +++---
> > > 1 file changed, 3 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/renesas/sh_eth.c
> > > b/drivers/net/ethernet/renesas/sh_eth.c
> > > index 0a150b2289146f..8b6c07fe3d407d 100644
> > > --- a/drivers/net/ethernet/renesas/sh_eth.c
> > > +++ b/drivers/net/ethernet/renesas/sh_eth.c
> > > @@ -3056,15 +3056,11 @@ static int sh_eth_drv_probe(struct
> > > platform_device *pdev)
> > > mdp->ether_link_active_low = pd->ether_link_active_low;
> > >
> > > /* set cpu data */
> > > - if (id) {
> > > + if (id)
> > > mdp->cd = (struct sh_eth_cpu_data *)id->driver_data;
> > > - } else {
> > > - const struct of_device_id *match;
> > > + else
> > > + mdp->cd = (struct sh_eth_cpu_data
> > > *)of_device_get_match_data(&pdev->dev);
> >
> > Is the cast needed here? of_device_get_match_data returns void *
>
> The compiler complains about a const mismatch without the cast. To keep
> things simple, I decided to leave the cast.
Ok, that makes sense.
Reviewed-by: Simon Horman
Re: [PATCH 4/6] pwm: pwm-lpc18xx-sct: test clock rate to avoid division by 0
On Wed, Mar 02, 2016 at 11:44:02PM +0100, Joachim Eastwood wrote:
> Hi Wolfram,
>
> On 2 March 2016 at 23:33, Wolfram Sang wrote:
> > From: Wolfram Sang
> >
> > The clk API may return 0 on clk_get_rate, so we should check the result
> > before
> > using it as a divisor.
> >
> > Signed-off-by: Wolfram Sang
> > ---
> >
> > Should go individually via subsystem tree.
> >
> > drivers/pwm/pwm-lpc18xx-sct.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
> > index 9163085101bc94..6487962c355c03 100644
> > --- a/drivers/pwm/pwm-lpc18xx-sct.c
> > +++ b/drivers/pwm/pwm-lpc18xx-sct.c
> > @@ -360,6 +360,8 @@ static int lpc18xx_pwm_probe(struct platform_device
> > *pdev)
> > }
> >
> > lpc18xx_pwm->clk_rate = clk_get_rate(lpc18xx_pwm->pwm_clk);
> > + if (!lpc18xx_pwm->clk_rate)
> > + return -EINVAL;
>
> This needs to be:
> if (!lpc18xx_pwm->clk_rate) {
> ret = -EINVAL;
> goto disable_pwmclk;
> }
Yes, that slipped through. Thanks!
> I would also prefer an explicit check against 0 here. ie.:
Well, I like the reading "if not rate then error"
Will send V2 now...
signature.asc
Description: PGP signature
Re: [PATCH 4/6] pwm: pwm-lpc18xx-sct: test clock rate to avoid division by 0
Hi Wolfram,
On 2 March 2016 at 23:33, Wolfram Sang wrote:
> From: Wolfram Sang
>
> The clk API may return 0 on clk_get_rate, so we should check the result before
> using it as a divisor.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Should go individually via subsystem tree.
>
> drivers/pwm/pwm-lpc18xx-sct.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
> index 9163085101bc94..6487962c355c03 100644
> --- a/drivers/pwm/pwm-lpc18xx-sct.c
> +++ b/drivers/pwm/pwm-lpc18xx-sct.c
> @@ -360,6 +360,8 @@ static int lpc18xx_pwm_probe(struct platform_device *pdev)
> }
>
> lpc18xx_pwm->clk_rate = clk_get_rate(lpc18xx_pwm->pwm_clk);
> + if (!lpc18xx_pwm->clk_rate)
> + return -EINVAL;
This needs to be:
if (!lpc18xx_pwm->clk_rate) {
ret = -EINVAL;
goto disable_pwmclk;
}
I would also prefer an explicit check against 0 here. ie.:
'lpc18xx_pwm->clk_rate == 0'
A dev_err() message would also be nice to have.
regards,
Joachim Eastwood
[PATCH 3/6] pwm: pwm-img: test clock rate to avoid division by 0
From: Wolfram Sang
The clk API may return 0 on clk_get_rate, so we should check the result before
using it as a divisor.
Signed-off-by: Wolfram Sang
---
Should go individually via subsystem tree.
drivers/pwm/pwm-img.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/pwm/pwm-img.c b/drivers/pwm/pwm-img.c
index 8a029f9bc18cb0..2fb30deee34570 100644
--- a/drivers/pwm/pwm-img.c
+++ b/drivers/pwm/pwm-img.c
@@ -237,6 +237,11 @@ static int img_pwm_probe(struct platform_device *pdev)
}
clk_rate = clk_get_rate(pwm->pwm_clk);
+ if (!clk_rate) {
+ dev_err(&pdev->dev, "pwm clock has no frequency\n");
+ ret = -EINVAL;
+ goto disable_pwmclk;
+ }
/* The maximum input clock divider is 512 */
val = (u64)NSEC_PER_SEC * 512 * pwm->data->max_timebase;
--
2.7.0
[PATCH 0/6] treewide: test clock rate to avoid division by 0
Here is the outcome of researching if the result of clk_get_rate() was directly used as a divisor without checking if it is 0. Inspired by a Coverity report. Wolfram Sang (6): ide: palm_bk3710: test clock rate to avoid division by 0 net: ethernet: renesas: ravb_main: test clock rate to avoid division by 0 pwm: pwm-img: test clock rate to avoid division by 0 pwm: pwm-lpc18xx-sct: test clock rate to avoid division by 0 watchdog: atlas7_wdt: test clock rate to avoid division by 0 watchdog: tangox_wdt: test clock rate to avoid division by 0 drivers/ide/palm_bk3710.c| 2 ++ drivers/net/ethernet/renesas/ravb_main.c | 3 +++ drivers/pwm/pwm-img.c| 5 + drivers/pwm/pwm-lpc18xx-sct.c| 2 ++ drivers/watchdog/atlas7_wdt.c| 5 + drivers/watchdog/tangox_wdt.c| 2 ++ 6 files changed, 19 insertions(+) -- 2.7.0
[PATCH 4/6] pwm: pwm-lpc18xx-sct: test clock rate to avoid division by 0
From: Wolfram Sang The clk API may return 0 on clk_get_rate, so we should check the result before using it as a divisor. Signed-off-by: Wolfram Sang --- Should go individually via subsystem tree. drivers/pwm/pwm-lpc18xx-sct.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c index 9163085101bc94..6487962c355c03 100644 --- a/drivers/pwm/pwm-lpc18xx-sct.c +++ b/drivers/pwm/pwm-lpc18xx-sct.c @@ -360,6 +360,8 @@ static int lpc18xx_pwm_probe(struct platform_device *pdev) } lpc18xx_pwm->clk_rate = clk_get_rate(lpc18xx_pwm->pwm_clk); + if (!lpc18xx_pwm->clk_rate) + return -EINVAL; mutex_init(&lpc18xx_pwm->res_lock); mutex_init(&lpc18xx_pwm->period_lock); -- 2.7.0
[PATCH 5/6] watchdog: atlas7_wdt: test clock rate to avoid division by 0
From: Wolfram Sang
The clk API may return 0 on clk_get_rate, so we should check the result before
using it as a divisor.
Signed-off-by: Wolfram Sang
---
Should go individually via subsystem tree.
drivers/watchdog/atlas7_wdt.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/watchdog/atlas7_wdt.c b/drivers/watchdog/atlas7_wdt.c
index df6d9242a31958..ed80734befae16 100644
--- a/drivers/watchdog/atlas7_wdt.c
+++ b/drivers/watchdog/atlas7_wdt.c
@@ -154,6 +154,11 @@ static int atlas7_wdt_probe(struct platform_device *pdev)
writel(0, wdt->base + ATLAS7_WDT_CNT_CTRL);
wdt->tick_rate = clk_get_rate(clk);
+ if (!wdt->tick_rate) {
+ ret = -EINVAL;
+ goto err1;
+ }
+
wdt->clk = clk;
atlas7_wdd.min_timeout = 1;
atlas7_wdd.max_timeout = UINT_MAX / wdt->tick_rate;
--
2.7.0
[PATCH 6/6] watchdog: tangox_wdt: test clock rate to avoid division by 0
From: Wolfram Sang The clk API may return 0 on clk_get_rate, so we should check the result before using it as a divisor. Signed-off-by: Wolfram Sang --- Should go individually via subsystem tree. drivers/watchdog/tangox_wdt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/watchdog/tangox_wdt.c b/drivers/watchdog/tangox_wdt.c index 709c1ed6fd79b9..cc702718ae4dbb 100644 --- a/drivers/watchdog/tangox_wdt.c +++ b/drivers/watchdog/tangox_wdt.c @@ -139,6 +139,8 @@ static int tangox_wdt_probe(struct platform_device *pdev) return err; dev->clk_rate = clk_get_rate(dev->clk); + if (!dev->clk_rate) + return -EINVAL; dev->wdt.parent = &pdev->dev; dev->wdt.info = &tangox_wdt_info; -- 2.7.0
[PATCH 2/6] net: ethernet: renesas: ravb_main: test clock rate to avoid division by 0
From: Wolfram Sang The clk API may return 0 on clk_get_rate, so we should check the result before using it as a divisor. Signed-off-by: Wolfram Sang --- Should go individually via subsystem tree. drivers/net/ethernet/renesas/ravb_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c index 88656ceb6e2946..ce1954a6a12726 100644 --- a/drivers/net/ethernet/renesas/ravb_main.c +++ b/drivers/net/ethernet/renesas/ravb_main.c @@ -1691,6 +1691,9 @@ static int ravb_set_gti(struct net_device *ndev) rate = clk_get_rate(clk); clk_put(clk); + if (!rate) + return -EINVAL; + inc = 10ULL << 20; do_div(inc, rate); -- 2.7.0
[PATCH 1/6] ide: palm_bk3710: test clock rate to avoid division by 0
From: Wolfram Sang The clk API may return 0 on clk_get_rate, so we should check the result before using it as a divisor. Signed-off-by: Wolfram Sang --- Should go individually via subsystem tree. drivers/ide/palm_bk3710.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/ide/palm_bk3710.c b/drivers/ide/palm_bk3710.c index 8012e43bf8f618..46427ea01753b4 100644 --- a/drivers/ide/palm_bk3710.c +++ b/drivers/ide/palm_bk3710.c @@ -325,6 +325,8 @@ static int __init palm_bk3710_probe(struct platform_device *pdev) clk_enable(clk); rate = clk_get_rate(clk); + if (!rate) + return -EINVAL; /* NOTE: round *down* to meet minimum timings; we count in clocks */ ideclk_period = 10UL / rate; -- 2.7.0
Re: [GIT PULL] Second Round of Renesas ARM Based SoC DT Fixes for v4.5
On Wednesday 02 March 2016 10:05:38 Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these second round of Renesas ARM based SoC DT fixes for v4.5. > > This pull request is based on the previous round of > such requests, tagged as renesas-dt-fixes-for-v4.5, > which you have already pulled. > > If this pull-request is too late for v4.5 then please consider it for v4.6. I've added it to both the next/dt and the fixes branch now. At the moment it's the only bug fix we have queued up for 4.5, if anything else comes up it will definitely be in there, otherwise we'll decide by the end of the week. My feeling is that we'll likely send this. > HS-USB DT support was added to the porter board in v4.5-rc1. > Unfortunately it was developed against an early revision of the > board and newer revisions do not include the Maxim Integrated MAX3355 OTG > chip and thus there should not be a renesas,enable-gpio property. > > It is my understanding at this time that the early-revision boards in > question have not been observed in the wild. ok. Thanks for the detailed background info. Arnd
Re: [PATCH/RFC 0/4] media: soc_camera: rcar_vin: Add UDS and NV16 scaling support
Hi Kaneko-san, On 2016-03-03 02:26:41 +0900, Yoshihiro Kaneko wrote: > Hi Hans, > > 2016-02-29 22:27 GMT+09:00 Hans Verkuil : > > Huh, you must have missed Niklas's work the rcar-vin driver: > > > > http://www.spinics.net/lists/linux-media/msg97816.html > > > > I expect that the old soc-camera driver will be retired soon in favor of > > the new driver, so I don't want to accept patches for that one. > > > > I recommend that you check the new driver and see what (if anything) is > > needed > > to get this functionality in there and work with Niklas on this. > > > > This is all quite recent work, so it is not surprising that you missed it. > > Thank you for informing me! > I will check it. My plan is to look at VIN for Gen3 once Gen2 support is done. I have somewhat tried to keep the new driver prepared for Gen3. I have separating the Gen2 scaler och clipper out in its own corner since this will be different on Gen3. My understanding is however that Gen3 don't provide UDS blocks (scaler+clipper) to all VIN instances. And the VIN instances that have access to a UDS block have to share it with one other VIN instance (only one user at a time). How to describe this in DT in a good way I do not yet know. If you have any ideas here or know more I would be glad to hear it, I have not yet started any work for Gen3. My initial plan for Gen3 enablement is to ignore the UDS blocks all together. I feel there is enough to adapt VIN driver and get both the CSI2 and sensor driver to work to be able to test the whole chain without worrying about UDS too. > > > > > Regards, > > > > Hans > > Regards, > kaneko > > > > > On 02/29/2016 02:12 PM, Yoshihiro Kaneko wrote: > >> This series adds UDS support, NV16 scaling support and callback functions > >> to be required by a clipping process. > >> > >> This series is against the master branch of linuxtv.org/media_tree.git. > >> > >> Koji Matsuoka (3): > >> media: soc_camera: rcar_vin: Add get_selection callback function > >> media: soc_camera: rcar_vin: Add cropcap callback function > >> media: soc_camera: rcar_vin: Add NV16 scaling support > >> > >> Yoshihiko Mori (1): > >> media: soc_camera: rcar_vin: Add UDS support > >> > >> drivers/media/platform/soc_camera/rcar_vin.c | 220 > >> ++- > >> 1 file changed, 184 insertions(+), 36 deletions(-) > >> > > -- Regards, Niklas Söderlund
Re: [PATCH v2 8/9] ARM: shmobile: lager dts: Add entries for VIN HDMI input support
The new way of writing the subject prefix is "ARM: dts: lager: ..."
Re: [PATCH/RFC v6 net-next] ravb: Add dma queue interrupt support
On 03/02/2016 09:16 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 OK, you are very close now! Just a few comments... [...] diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c index c936682..22ef65d 100644 --- a/drivers/net/ethernet/renesas/ravb_main.c +++ b/drivers/net/ethernet/renesas/ravb_main.c [...] +static irqreturn_t ravb_rx_tx_interrupt(int irq, void *dev_id, int ravb_queue) Please, please shorten this 'ravb_queue'... I will fix it. Also, would make sense to rename it to ravb_dma_interrupt()... I have renamed it from ravb_dmaq_interrupt() in this version as you suggested in the previous review. Did you not mean it? Yes, I meant that, though perhaps got somewhat muddled up. Another variant is to call the current ravb_queue_interrupt() ravb_dma_interrupt_unlocked() (after adding the register reads there) calling this one ravb_dma_interrupt() but I don't insist on the former, ravb_queue_interrupt() is good enough as is; just rename this function please. [...] Unfortunately, I still can't do a full gen2 regression testing as both Alt and Porter boards don't work with the recent kernel due to AVB_MDIO stuck at 1... But perhaps such testing isn't even necessary. Thanks, kaneko MBR, Sergei
Re: [PATCH/RFC v5 net-next] ravb: Add dma queue interrupt support
Hello.
On 03/02/2016 09:32 PM, Yoshihiro Kaneko wrote:
From: Kazuya Mizuguchi
This patch supports the following interrupts.
- One interrupt for multiple (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: 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]
Signed-off-by: Kazuya Mizuguchi
Signed-off-by: Yoshihiro Kaneko
[...]
diff --git a/drivers/net/ethernet/renesas/ravb_main.c
b/drivers/net/ethernet/renesas/ravb_main.c
index c936682..1bec71e 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
[...]
@@ -725,31 +787,15 @@ static irqreturn_t ravb_interrupt(int irq, void
*dev_id)
/* Network control and best effort queue RX/TX */
for (q = RAVB_NC; q >= RAVB_BE; q--) {
- if (((ris0 & ric0) & BIT(q)) ||
- ((tis & tic) & BIT(q))) {
- if (napi_schedule_prep(&priv->napi[q]))
{
- /* Mask RX and TX interrupts */
- ric0 &= ~BIT(q);
- tic &= ~BIT(q);
- ravb_write(ndev, ric0, RIC0);
- ravb_write(ndev, tic, TIC);
- __napi_schedule(&priv->napi[q]);
- } else {
- netdev_warn(ndev,
- "ignoring interrupt,
rx status 0x%08x, rx mask 0x%08x,\n",
- ris0, ric0);
- netdev_warn(ndev,
- "
tx status 0x%08x, tx mask 0x%08x.\n",
- tis, tic);
- }
+ if (ravb_nc_be_interrupt(ndev, q, ris0, &ric0,
tis,
+&tic))
result = IRQ_HANDLED;
- }
}
Unroll this *for* loop please...
OK.
It was a bad idea actually, sorry...
OK, I will revert this part.
(But I think it is not that bad...)
I think the loop will scale better if we ever support the AVB queues...
[...]
@@ -767,6 +813,73 @@ static irqreturn_t ravb_interrupt(int irq, void
[...]
+static irqreturn_t ravb_dmaq_interrupt(int irq, void *dev_id, int
ravb_queue)
Perhaps, ravb_rx_tx_interrupt()?
Agreed.
And we still have ravb_dma_interrupt() unused, right?
Do you mean that there is an unused "ravb_dma_interrupt()" in this version?
I probably be misunderstanding something.
No, I meant that this name isn't used yet.
[...]
Thanks,
kaneko
MBR, Sergei
Re: [PATCH/RFC v5 net-next] ravb: Add dma queue interrupt support
2016-03-01 5:55 GMT+09:00 Sergei Shtylyov :
> On 02/28/2016 05:13 PM, Yoshihiro Kaneko wrote:
>
From: Kazuya Mizuguchi
This patch supports the following interrupts.
- One interrupt for multiple (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: 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]
Signed-off-by: Kazuya Mizuguchi
Signed-off-by: Yoshihiro Kaneko
>>>
>>>
>>>
>>> [...]
>>>
diff --git a/drivers/net/ethernet/renesas/ravb_main.c
b/drivers/net/ethernet/renesas/ravb_main.c
index c936682..1bec71e 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
>>>
>>>
>>> [...]
@@ -697,6 +726,39 @@ static void ravb_error_interrupt(struct net_device
*ndev)
}
}
+static int ravb_nc_be_interrupt(struct net_device *ndev, int
ravb_queue,
>>>
>>>
>>>
>>> I'd call this function e.g. ravb_queue_interrupt(). And make it
>>> return
>>> 'bool' or even 'irqreturn_t' directly. And I'd suggest a shorter name for
>>> the 'ravb_queue' parameter, like 'queue' or even 'q'...
>>
>>
>> Agreed.
>>
>>>
+ u32 ris0, u32 *ric0, u32 tis, u32 *tic)
>>>
>>>
>>>
>>> You don't seem to need 'ric0' and 'tic' past the call sites, so no
>>> real
>>> need to pass them by reference.
>>
>>
>> When Rx/Tx interrupt for NC and BE is issued at the same time,
>> this function is called twice (for NC, BE) from ravb_interrupt.
>> The interrupt mask of NC set in the first call will be reset in the next
>> call for BE. So it is necessary to keep the modified value of "ric0" and
>> "tic".
>
>
>OK, but we still can simplify this by reading these registers right in
> ravb_queue_interrupt()...
OK.
>
>
> [...]
@@ -725,31 +787,15 @@ static irqreturn_t ravb_interrupt(int irq, void
*dev_id)
/* Network control and best effort queue RX/TX */
for (q = RAVB_NC; q >= RAVB_BE; q--) {
- if (((ris0 & ric0) & BIT(q)) ||
- ((tis & tic) & BIT(q))) {
- if (napi_schedule_prep(&priv->napi[q]))
{
- /* Mask RX and TX interrupts */
- ric0 &= ~BIT(q);
- tic &= ~BIT(q);
- ravb_write(ndev, ric0, RIC0);
- ravb_write(ndev, tic, TIC);
- __napi_schedule(&priv->napi[q]);
- } else {
- netdev_warn(ndev,
- "ignoring interrupt,
rx status 0x%08x, rx mask 0x%08x,\n",
- ris0, ric0);
- netdev_warn(ndev,
- "
tx status 0x%08x, tx mask 0x%08x.\n",
- tis, tic);
- }
+ if (ravb_nc_be_interrupt(ndev, q, ris0, &ric0,
tis,
+&tic))
result = IRQ_HANDLED;
- }
}
>>>
>>>
>>>
>>> Unroll this *for* loop please...
>
>
>> OK.
>
>
>It was a bad idea actually, sorry...
OK, I will revert this part.
(But I think it is not that bad...)
>
> [...]
@@ -767,6 +813,73 @@ static irqreturn_t ravb_interrupt(int irq, void
>
> [...]
+static irqreturn_t ravb_dmaq_interrupt(int irq, void *dev_id, int
ravb_queue)
>>>
>>>
>>>
>>> Perhaps, ravb_rx_tx_interrupt()?
>>
>>
>> Agreed.
>
>
>And we still have ravb_dma_interrupt() unused,
Re: [PATCH/RFC v6 net-next] ravb: Add dma queue interrupt support
2016-03-01 5:30 GMT+09:00 Sergei Shtylyov :
> Hello.
>
>
> On 02/28/2016 06:41 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
>
>
>OK, you are very close now! Just a few comments...
>
> [...]
>>
>> diff --git a/drivers/net/ethernet/renesas/ravb_main.c
>> b/drivers/net/ethernet/renesas/ravb_main.c
>> index c936682..22ef65d 100644
>> --- a/drivers/net/ethernet/renesas/ravb_main.c
>> +++ b/drivers/net/ethernet/renesas/ravb_main.c
>
> [...]
>>
>> @@ -697,6 +726,47 @@ static void ravb_error_interrupt(struct net_device
>> *ndev)
>> }
>> }
>>
>> +static bool ravb_queue_interrupt(struct net_device *ndev, int q,
>> +u32 ris0, u32 *ric0, u32 tis, u32 *tic)
>> +{
>> + struct ravb_private *priv = netdev_priv(ndev);
>> +
>
>
>Perhaps it makes sense to read the RI[CS]0/TI[CS] here instead of passing
> them (by reference)?
OK, I will do.
>
> [...]
>
>> @@ -714,42 +784,21 @@ static irqreturn_t ravb_interrupt(int irq, void
>> *dev_id)
>> u32 ric0 = ravb_read(ndev, RIC0);
>> u32 tis = ravb_read(ndev, TIS);
>> u32 tic = ravb_read(ndev, TIC);
>> - int q;
>>
>> /* Timestamp updated */
>> - if (tis & TIS_TFUF) {
>> - ravb_write(ndev, ~TIS_TFUF, TIS);
>> - ravb_get_tx_tstamp(ndev);
>> + if (ravb_timestamp_interrupt(ndev, tis))
>> result = IRQ_HANDLED;
>> - }
>>
>> /* Network control and best effort queue RX/TX */
>> - for (q = RAVB_NC; q >= RAVB_BE; q--) {
>> - if (((ris0 & ric0) & BIT(q)) ||
>> - ((tis & tic) & BIT(q))) {
>> - if (napi_schedule_prep(&priv->napi[q])) {
>> - /* Mask RX and TX interrupts */
>> - ric0 &= ~BIT(q);
>> - tic &= ~BIT(q);
>> - ravb_write(ndev, ric0, RIC0);
>> - ravb_write(ndev, tic, TIC);
>> - __napi_schedule(&priv->napi[q]);
>> - } else {
>> - netdev_warn(ndev,
>> - "ignoring interrupt,
>> rx status 0x%08x, rx mask 0x%08x,\n",
>> - ris0, ric0);
>> - netdev_warn(ndev,
>> - "
>> tx status 0x%08x, tx mask 0x%08x.\n",
>> - tis, tic);
>> - }
>> - result = IRQ_HANDLED;
>> - }
>> - }
>> + if (ravb_queue_interrupt(ndev, RAVB_NC, ris0, &ric0, tis,
>> &tic))
>> + result = IRQ_HANDLED;
>> + if (ravb_queue_interrupt(ndev, RAVB_BE, ris0, &ric0, tis,
>> &tic))
>> + result = IRQ_HANDLED;
>
>
>Hmm, perhaps unrolling wasn't such a great idea... we can't use || here
> as it would be short-circuited. :-(
>
> [...]
>>
>> +static irqreturn_t ravb_rx_tx_interrupt(int irq, void *dev_id, int
>> ravb_queue)
>
>
>Please, please shorten this 'ravb_queue'...
I will fix it.
>Also, would
Re: [PATCH] net: sh_eth: avoid NULL pointer dereference in ring setup
On 03/02/2016 08:11 PM, Wolfram Sang wrote: Reported-by: coverity (CID 1056464) Signed-off-by: Wolfram Sang Will you respin or should I? Please go ahead. You have more knowledge about this driver, so you will be faster. Not necessarily -- I have other bug to chase right now. :-) Reported-by: Wolfram Sang Thanks for reporting, anyway. MBR, Sergei
Re: [PATCH 2/6] ASoC: rsrc-card: add convert channels support
On Thu, Feb 25, 2016 at 05:51:44AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > Renesas sound device has CTU (= Channel Transfer Unit), and > sound card needs its support. > > Signed-off-by: Kuninori Morimoto > --- > .../bindings/sound/renesas,rsrc-card.txt | 1 + > sound/soc/sh/rcar/rsrc-card.c | 22 > -- > 2 files changed, 17 insertions(+), 6 deletions(-) > > diff --git a/Documentation/devicetree/bindings/sound/renesas,rsrc-card.txt > b/Documentation/devicetree/bindings/sound/renesas,rsrc-card.txt > index 2b2caa2..5abebf7 100644 > --- a/Documentation/devicetree/bindings/sound/renesas,rsrc-card.txt > +++ b/Documentation/devicetree/bindings/sound/renesas,rsrc-card.txt > @@ -30,6 +30,7 @@ Optional subnode properties: > - frame-inversion: bool property. Add this if the > dai-link uses frame clock inversion. > - convert-rate : platform specified sampling > rate convert > +- convert-channels : platform specified channel size > convert This needs a better description (as did convert-rate). What is the type? What are valid values? > - audio-prefix : see audio-routing > - audio-routing : A list of the connections > between audio components. > Each entry is a pair of strings, the > first being the connection's sink,
Re: [PATCH/RFC 0/4] media: soc_camera: rcar_vin: Add UDS and NV16 scaling support
Hi Hans, 2016-02-29 22:27 GMT+09:00 Hans Verkuil : > Huh, you must have missed Niklas's work the rcar-vin driver: > > http://www.spinics.net/lists/linux-media/msg97816.html > > I expect that the old soc-camera driver will be retired soon in favor of > the new driver, so I don't want to accept patches for that one. > > I recommend that you check the new driver and see what (if anything) is needed > to get this functionality in there and work with Niklas on this. > > This is all quite recent work, so it is not surprising that you missed it. Thank you for informing me! I will check it. > > Regards, > > Hans Regards, kaneko > > On 02/29/2016 02:12 PM, Yoshihiro Kaneko wrote: >> This series adds UDS support, NV16 scaling support and callback functions >> to be required by a clipping process. >> >> This series is against the master branch of linuxtv.org/media_tree.git. >> >> Koji Matsuoka (3): >> media: soc_camera: rcar_vin: Add get_selection callback function >> media: soc_camera: rcar_vin: Add cropcap callback function >> media: soc_camera: rcar_vin: Add NV16 scaling support >> >> Yoshihiko Mori (1): >> media: soc_camera: rcar_vin: Add UDS support >> >> drivers/media/platform/soc_camera/rcar_vin.c | 220 >> ++- >> 1 file changed, 184 insertions(+), 36 deletions(-) >> >
[PATCH v2 1/9] v4l: subdev: Add pad config allocator and init
From: Laurent Pinchart
Add a new subdev operation to initialize a subdev pad config array, and
a helper function to allocate and initialize the array. This can be used
by bridge drivers to implement try format based on subdev pad
operations.
Signed-off-by: Laurent Pinchart
Acked-by: Vaibhav Hiremath
Acked-by: Hans Verkuil
---
drivers/media/v4l2-core/v4l2-subdev.c | 19 ++-
include/media/v4l2-subdev.h | 10 ++
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
b/drivers/media/v4l2-core/v4l2-subdev.c
index d630838..f32ac0d 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -35,7 +35,7 @@
static int subdev_fh_init(struct v4l2_subdev_fh *fh, struct v4l2_subdev *sd)
{
#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
- fh->pad = kzalloc(sizeof(*fh->pad) * sd->entity.num_pads, GFP_KERNEL);
+ fh->pad = v4l2_subdev_alloc_pad_config(sd);
if (fh->pad == NULL)
return -ENOMEM;
#endif
@@ -569,6 +569,23 @@ int v4l2_subdev_link_validate(struct media_link *link)
sink, link, &source_fmt, &sink_fmt);
}
EXPORT_SYMBOL_GPL(v4l2_subdev_link_validate);
+
+struct v4l2_subdev_pad_config *v4l2_subdev_alloc_pad_config(struct v4l2_subdev
*sd)
+{
+ struct v4l2_subdev_pad_config *cfg;
+
+ if (!sd->entity.num_pads)
+ return NULL;
+
+ cfg = kcalloc(sd->entity.num_pads, sizeof(*cfg), GFP_KERNEL);
+ if (!cfg)
+ return NULL;
+
+ v4l2_subdev_call(sd, pad, init_cfg, cfg);
+
+ return cfg;
+}
+EXPORT_SYMBOL_GPL(v4l2_subdev_alloc_pad_config);
#endif /* CONFIG_MEDIA_CONTROLLER */
void v4l2_subdev_init(struct v4l2_subdev *sd, const struct v4l2_subdev_ops
*ops)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index b273cf9..e1e25fa 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -604,6 +604,8 @@ struct v4l2_subdev_pad_config {
* may be adjusted by the subdev driver to device
capabilities.
*/
struct v4l2_subdev_pad_ops {
+ void (*init_cfg)(struct v4l2_subdev *sd,
+struct v4l2_subdev_pad_config *cfg);
int (*enum_mbus_code)(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_mbus_code_enum *code);
@@ -798,7 +800,15 @@ int v4l2_subdev_link_validate_default(struct v4l2_subdev
*sd,
struct v4l2_subdev_format *source_fmt,
struct v4l2_subdev_format *sink_fmt);
int v4l2_subdev_link_validate(struct media_link *link);
+
+struct v4l2_subdev_pad_config *v4l2_subdev_alloc_pad_config(struct v4l2_subdev
*sd);
+
+static inline void v4l2_subdev_free_pad_config(struct v4l2_subdev_pad_config
*cfg)
+{
+ kfree(cfg);
+}
#endif /* CONFIG_MEDIA_CONTROLLER */
+
void v4l2_subdev_init(struct v4l2_subdev *sd,
const struct v4l2_subdev_ops *ops);
--
2.6.4
[PATCH v2 4/9] media: rcar_vin: Use correct pad number in try_fmt
Fix rcar_vin_try_fmt's use of an inappropriate pad number when calling
the subdev set_fmt function - for the ADV7612, IDs should be non-zero.
Signed-off-by: William Towle
Reviewed-by: Rob Taylor
Acked-by: Hans Verkuil
[uli: adapted to rcar-vin rewrite]
Signed-off-by: Ulrich Hecht
---
drivers/media/platform/rcar-vin/rcar-dma.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
b/drivers/media/platform/rcar-vin/rcar-dma.c
index c267309..15a67f7 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -329,7 +329,7 @@ static int __rvin_dma_try_format_sensor(struct rvin_dev
*vin,
struct rvin_sensor *sensor)
{
struct v4l2_subdev *sd;
- struct v4l2_subdev_pad_config pad_cfg;
+ struct v4l2_subdev_pad_config *pad_cfg;
struct v4l2_subdev_format format = {
.which = which,
};
@@ -337,12 +337,18 @@ static int __rvin_dma_try_format_sensor(struct rvin_dev
*vin,
sd = vin_to_sd(vin);
+ pad_cfg = v4l2_subdev_alloc_pad_config(sd);
+ if (pad_cfg == NULL)
+ return -ENOMEM;
+
v4l2_fill_mbus_format(&format.format, pix, vin->sensor.code);
+ format.pad = vin->src_pad_idx;
+
ret = v4l2_device_call_until_err(sd->v4l2_dev, 0, pad, set_fmt,
-&pad_cfg, &format);
+pad_cfg, &format);
if (ret < 0)
- return ret;
+ goto cleanup;
v4l2_fill_pix_format(pix, &format.format);
@@ -351,6 +357,8 @@ static int __rvin_dma_try_format_sensor(struct rvin_dev
*vin,
vin_dbg(vin, "Sensor format: %ux%u\n", sensor->width, sensor->height);
+cleanup:
+ v4l2_subdev_free_pad_config(pad_cfg);
return 0;
}
--
2.6.4
[PATCH v2 5/9] media: rcar-vin: pad-aware driver initialisation
Add detection of source pad number for drivers aware of the media controller
API, so that rcar-vin can create device nodes to support modern drivers such
as adv7604.c (for HDMI on Lager) and the converted adv7180.c (for composite)
underneath.
Building rcar_vin gains a dependency on CONFIG_MEDIA_CONTROLLER, in
line with requirements for building the drivers associated with it.
Signed-off-by: William Towle
Signed-off-by: Rob Taylor
[uli: adapted to rcar-vin rewrite]
Signed-off-by: Ulrich Hecht
---
drivers/media/platform/rcar-vin/rcar-dma.c | 16
drivers/media/platform/rcar-vin/rcar-vin.h | 1 +
2 files changed, 17 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 15a67f7..3d957dc 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -1008,6 +1008,9 @@ int rvin_dma_on(struct rvin_dev *vin)
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
struct v4l2_mbus_framefmt *mf = &fmt.format;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ int pad_idx;
+#endif
int ret;
sd = vin_to_sd(vin);
@@ -1040,6 +1043,19 @@ int rvin_dma_on(struct rvin_dev *vin)
return ret;
}
+ vin->src_pad_idx = 0;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ for (pad_idx = 0; pad_idx < sd->entity.num_pads; pad_idx++)
+ if (sd->entity.pads[pad_idx].flags
+ == MEDIA_PAD_FL_SOURCE)
+ break;
+ if (pad_idx >= sd->entity.num_pads)
+ goto remove_device;
+
+ vin->src_pad_idx = pad_idx;
+#endif
+ fmt.pad = vin->src_pad_idx;
+
vin->format.field = V4L2_FIELD_ANY;
/* Try to improve our guess of a reasonable window format */
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
b/drivers/media/platform/rcar-vin/rcar-vin.h
index f07cd7c..c6f6e44 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -121,6 +121,7 @@ struct rvin_dev {
struct video_device vdev;
struct v4l2_device v4l2_dev;
+ int src_pad_idx;/* For media-controller drivers */
struct v4l2_ctrl_handler ctrl_handler;
struct v4l2_async_notifier notifier;
struct rvin_graph_entity entity;
--
2.6.4
[PATCH v2 7/9] media: rcar-vin: initialize EDID data
Initializes the decoder subdevice with a fixed EDID blob.
Signed-off-by: Ulrich Hecht
---
drivers/media/platform/rcar-vin/rcar-dma.c | 46 ++
1 file changed, 46 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 4596eda..f5d93bc 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -1070,6 +1070,41 @@ error:
return ret;
}
+static u8 edid[256] = {
+ 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
+ 0x48, 0xAE, 0x9C, 0x27, 0x00, 0x00, 0x00, 0x00,
+ 0x19, 0x12, 0x01, 0x03, 0x80, 0x00, 0x00, 0x78,
+ 0x0E, 0x00, 0xB2, 0xA0, 0x57, 0x49, 0x9B, 0x26,
+ 0x10, 0x48, 0x4F, 0x2F, 0xCF, 0x00, 0x31, 0x59,
+ 0x45, 0x59, 0x61, 0x59, 0x81, 0x99, 0x01, 0x01,
+ 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3A,
+ 0x80, 0x18, 0x71, 0x38, 0x2D, 0x40, 0x58, 0x2C,
+ 0x46, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1E,
+ 0x00, 0x00, 0x00, 0xFD, 0x00, 0x31, 0x55, 0x18,
+ 0x5E, 0x11, 0x00, 0x0A, 0x20, 0x20, 0x20, 0x20,
+ 0x20, 0x20, 0x00, 0x00, 0x00, 0xFC, 0x00, 0x43,
+ 0x20, 0x39, 0x30, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A,
+ 0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0x10,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x68,
+ 0x02, 0x03, 0x1a, 0xc0, 0x48, 0xa2, 0x10, 0x04,
+ 0x02, 0x01, 0x21, 0x14, 0x13, 0x23, 0x09, 0x07,
+ 0x07, 0x65, 0x03, 0x0c, 0x00, 0x10, 0x00, 0xe2,
+ 0x00, 0x2a, 0x01, 0x1d, 0x00, 0x80, 0x51, 0xd0,
+ 0x1c, 0x20, 0x40, 0x80, 0x35, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x1e, 0x8c, 0x0a, 0xd0, 0x8a,
+ 0x20, 0xe0, 0x2d, 0x10, 0x10, 0x3e, 0x96, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x18, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xd7
+};
+
int rvin_dma_on(struct rvin_dev *vin)
{
struct v4l2_subdev *sd;
@@ -1159,6 +1194,17 @@ int rvin_dma_on(struct rvin_dev *vin)
v4l2_info(&vin->v4l2_dev, "Device registered as /dev/video%d\n",
vin->vdev.num);
+ {
+ struct v4l2_subdev_edid rvin_edid = {
+ .pad = 0,
+ .start_block = 0,
+ .blocks = 2,
+ .edid = edid,
+ };
+ v4l2_subdev_call(sd, pad, set_edid,
+ &rvin_edid);
+ }
+
remove_device:
rvin_remove_device(vin);
--
2.6.4
[PATCH v2 6/9] media: rcar-vin: add DV timings support
Adds ioctls DV_TIMINGS_CAP, ENUM_DV_TIMINGS, G_DV_TIMINGS, S_DV_TIMINGS,
and QUERY_DV_TIMINGS.
Signed-off-by: Ulrich Hecht
---
drivers/media/platform/rcar-vin/rcar-dma.c | 69 ++
1 file changed, 69 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 3d957dc..4596eda 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -644,12 +644,17 @@ static int rvin_enum_input(struct file *file, void *priv,
struct v4l2_input *i)
{
struct rvin_dev *vin = video_drvdata(file);
+ struct v4l2_subdev *sd = vin_to_sd(vin);
if (i->index != 0)
return -EINVAL;
i->type = V4L2_INPUT_TYPE_CAMERA;
i->std = vin->vdev.tvnorms;
+
+ if (v4l2_subdev_has_op(sd, pad, dv_timings_cap))
+ i->capabilities = V4L2_IN_CAP_DV_TIMINGS;
+
strlcpy(i->name, "Camera", sizeof(i->name));
return 0;
@@ -692,6 +697,64 @@ static int rvin_g_std(struct file *file, void *priv,
v4l2_std_id *a)
return v4l2_subdev_call(sd, video, g_std, a);
}
+static int rvin_enum_dv_timings(struct file *file, void *priv_fh,
+ struct v4l2_enum_dv_timings *timings)
+{
+ struct rvin_dev *vin = video_drvdata(file);
+ struct v4l2_subdev *sd = vin_to_sd(vin);
+
+ timings->pad = 0;
+ return v4l2_subdev_call(sd,
+ pad, enum_dv_timings, timings);
+}
+
+static int rvin_s_dv_timings(struct file *file, void *priv_fh,
+ struct v4l2_dv_timings *timings)
+{
+ struct rvin_dev *vin = video_drvdata(file);
+ struct v4l2_subdev *sd = vin_to_sd(vin);
+ int err;
+
+ err = v4l2_subdev_call(sd,
+ video, s_dv_timings, timings);
+ if (!err) {
+ vin->sensor.width = timings->bt.width;
+ vin->sensor.height = timings->bt.height;
+ }
+ return err;
+}
+
+static int rvin_g_dv_timings(struct file *file, void *priv_fh,
+ struct v4l2_dv_timings *timings)
+{
+ struct rvin_dev *vin = video_drvdata(file);
+ struct v4l2_subdev *sd = vin_to_sd(vin);
+
+ return v4l2_subdev_call(sd,
+ video, g_dv_timings, timings);
+}
+
+static int rvin_query_dv_timings(struct file *file, void *priv_fh,
+ struct v4l2_dv_timings *timings)
+{
+ struct rvin_dev *vin = video_drvdata(file);
+ struct v4l2_subdev *sd = vin_to_sd(vin);
+
+ return v4l2_subdev_call(sd,
+ video, query_dv_timings, timings);
+}
+
+static int rvin_dv_timings_cap(struct file *file, void *priv_fh,
+ struct v4l2_dv_timings_cap *cap)
+{
+ struct rvin_dev *vin = video_drvdata(file);
+ struct v4l2_subdev *sd = vin_to_sd(vin);
+
+ cap->pad = 0;
+ return v4l2_subdev_call(sd,
+ pad, dv_timings_cap, cap);
+}
+
static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
.vidioc_querycap= rvin_querycap,
.vidioc_try_fmt_vid_cap = rvin_try_fmt_vid_cap,
@@ -706,6 +769,12 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
.vidioc_g_input = rvin_g_input,
.vidioc_s_input = rvin_s_input,
+ .vidioc_dv_timings_cap = rvin_dv_timings_cap,
+ .vidioc_enum_dv_timings = rvin_enum_dv_timings,
+ .vidioc_g_dv_timings= rvin_g_dv_timings,
+ .vidioc_s_dv_timings= rvin_s_dv_timings,
+ .vidioc_query_dv_timings= rvin_query_dv_timings,
+
.vidioc_querystd= rvin_querystd,
.vidioc_g_std = rvin_g_std,
.vidioc_s_std = rvin_s_std,
--
2.6.4
[PATCH v2 8/9] ARM: shmobile: lager dts: Add entries for VIN HDMI input support
From: William Towle
Add DT entries for vin0, vin0_pins, and adv7612.
Signed-off-by: William Towle
Signed-off-by: Rob Taylor
[uli: added interrupt, renamed endpoint]
Signed-off-by: Ulrich Hecht
---
arch/arm/boot/dts/r8a7790-lager.dts | 40 -
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index aa6ca92..a5f727c 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -414,7 +414,12 @@
renesas,function = "usb2";
};
- vin1_pins: vin {
+ vin0_pins: vin0 {
+ renesas,groups = "vin0_data24", "vin0_sync", "vin0_clkenb",
"vin0_clk";
+ renesas,function = "vin0";
+ };
+
+ vin1_pins: vin1 {
renesas,groups = "vin1_data8", "vin1_clk";
renesas,function = "vin1";
};
@@ -590,6 +595,20 @@
reg = <0x12>;
};
+ hdmi-in@4c {
+ compatible = "adi,adv7612";
+ reg = <0x4c>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ remote = <&vin0>;
+
+ port {
+ adv7612: endpoint {
+ remote-endpoint = <&vin0ep0>;
+ };
+ };
+ };
+
composite-in@20 {
compatible = "adi,adv7180";
reg = <0x20>;
@@ -705,6 +724,25 @@
status = "okay";
};
+/* HDMI video input */
+&vin0 {
+ pinctrl-0 = <&vin0_pins>;
+ pinctrl-names = "default";
+
+ status = "ok";
+
+ port {
+ vin0ep0: endpoint {
+ remote-endpoint = <&adv7612>;
+ bus-width = <24>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ pclk-sample = <1>;
+ data-active = <1>;
+ };
+ };
+};
+
/* composite video input */
&vin1 {
pinctrl-0 = <&vin1_pins>;
--
2.6.4
[PATCH v2 9/9] ARM: shmobile: lager dts: specify default-input for ADV7612
From: Ian Molton
Set the 'default-input' property for ADV7612, enabling image and video
capture without the need to have userspace specifying routing.
(This version places the property in the adv7612 node, in line with
Ian's documentation)
Signed-off-by: Ian Molton
Signed-off-by: William Towle
Signed-off-by: Ulrich Hecht
---
arch/arm/boot/dts/r8a7790-lager.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index a5f727c..eed0974 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -601,6 +601,7 @@
interrupt-parent = <&gpio1>;
interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
remote = <&vin0>;
+ default-input = <0>;
port {
adv7612: endpoint {
--
2.6.4
[PATCH v2 3/9] adv7604: fix SPA register location for ADV7612
SPA location LSB register is at 0x70.
Signed-off-by: Ulrich Hecht
---
drivers/media/i2c/adv7604.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 2097c48..1680c0e 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2110,7 +2110,8 @@ static int adv76xx_set_edid(struct v4l2_subdev *sd,
struct v4l2_edid *edid)
rep_write(sd, 0x76, spa_loc & 0xff);
rep_write_clr_set(sd, 0x77, 0x40, (spa_loc & 0x100) >> 2);
} else {
- /* FIXME: Where is the SPA location LSB register ? */
+ /* ADV7612 Software Manual Rev. A, p. 15 */
+ rep_write(sd, 0x70, spa_loc & 0xff);
rep_write_clr_set(sd, 0x71, 0x01, (spa_loc & 0x100) >> 8);
}
--
2.6.4
[PATCH v2 2/9] media: adv7604: automatic "default-input" selection
From: William Towle
Add logic such that the "default-input" property becomes unnecessary
for chips that only have one suitable input (ADV7611 by design, and
ADV7612 due to commit 7111cddd "[media] media: adv7604: reduce support
to first (digital) input").
Additionally, Ian's documentation in commit bf9c8227 ("[media] media:
adv7604: ability to read default input port from DT") states that the
"default-input" property should reside directly in the node for
adv7612. Hence, also adjust the parsing to make the implementation
consistent with this.
Signed-off-by: William Towle
Signed-off-by: Ulrich Hecht
---
drivers/media/i2c/adv7604.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index f8dd750..2097c48 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2799,7 +2799,7 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
struct device_node *endpoint;
struct device_node *np;
unsigned int flags;
- u32 v;
+ u32 v = -1;
np = state->i2c_clients[ADV76XX_PAGE_IO]->dev.of_node;
@@ -2809,14 +2809,24 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
return -EINVAL;
v4l2_of_parse_endpoint(endpoint, &bus_cfg);
-
- if (!of_property_read_u32(endpoint, "default-input", &v))
- state->pdata.default_input = v;
- else
- state->pdata.default_input = -1;
-
of_node_put(endpoint);
+ if (of_property_read_u32(np, "default-input", &v)) {
+ /* not specified ... can we choose automatically? */
+ switch (state->info->type) {
+ case ADV7611:
+ v = 0;
+ break;
+ case ADV7612:
+ if (state->info->max_port == ADV76XX_PAD_HDMI_PORT_A)
+ v = 0;
+ /* else is unhobbled, leave unspecified */
+ default:
+ break;
+ }
+ }
+ state->pdata.default_input = v;
+
flags = bus_cfg.bus.parallel.flags;
if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
--
2.6.4
[PATCH v2 0/9] Lager board HDMI input support
Hi!
This series implements Lager HDMI input support on top of version 2 of
Niklas's herculean rewrite of the rcar-vin driver ("[PATCHv2] [media]
rcar-vin: add Renesas R-Car VIN driver").
A couple of the included patches are pushed or have been picked up elsewhere
already and are included here for ease of testing.
The EDID initialization blob has been lifted wholesale from the cobalt
driver, with only the vendor ID adjusted to "REN".
(Note for testing: To get up-to-date DV timings, you have to use a client
that does QUERY_DV_TIMINGS/S_DV_TIMINGS. Few do.)
CU
Uli
Ian Molton (1):
ARM: shmobile: lager dts: specify default-input for ADV7612
Laurent Pinchart (1):
v4l: subdev: Add pad config allocator and init
Ulrich Hecht (5):
adv7604: fix SPA register location for ADV7612
media: rcar_vin: Use correct pad number in try_fmt
media: rcar-vin: pad-aware driver initialisation
media: rcar-vin: add DV timings support
media: rcar-vin: initialize EDID data
William Towle (2):
media: adv7604: automatic "default-input" selection
ARM: shmobile: lager dts: Add entries for VIN HDMI input support
arch/arm/boot/dts/r8a7790-lager.dts| 41 +++-
drivers/media/i2c/adv7604.c| 27 --
drivers/media/platform/rcar-vin/rcar-dma.c | 145 -
drivers/media/platform/rcar-vin/rcar-vin.h | 1 +
drivers/media/v4l2-core/v4l2-subdev.c | 19 +++-
include/media/v4l2-subdev.h| 10 ++
6 files changed, 230 insertions(+), 13 deletions(-)
--
2.6.4
Re: [PATCH] net: sh_eth: avoid NULL pointer dereference in ring setup
> >Reported-by: coverity (CID 1056464) > >Signed-off-by: Wolfram Sang > >Will you respin or should I? Please go ahead. You have more knowledge about this driver, so you will be faster. Reported-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH] net: sh_eth: avoid NULL pointer dereference in ring setup
Hello. On 03/02/2016 06:26 PM, Wolfram Sang wrote: From: Wolfram Sang When allocating an skb fails, rxdesc is still NULL (or the previous ring index on further iterations of the loop). However, this pointer is dereferenced after the loop. This is intended. What we seem to actually need is a NULL check before that dereference. So, make sure rxdesc is updated immediately at the beginning of the loop. No, this seems wrong. We don't want an unfilled descriptor to be marked as last, we still need the previous one marked as last. Actually, 'rxdesc' shouldn't be "advanced" even before the second *break* as it is now. Reported-by: coverity (CID 1056464) Signed-off-by: Wolfram Sang Will you respin or should I? MBR, Sergei
Re: [PATCH] Remove ARCH_SHMOBILE
Hi Magnus,
On Wed, Mar 2, 2016 at 5:00 PM, Magnus Damm wrote:
> On Wed, Mar 2, 2016 at 6:30 PM, Geert Uytterhoeven
> wrote:
>> On Wed, Mar 2, 2016 at 2:55 AM, Simon Horman
>> wrote:
>>> --- a/drivers/input/keyboard/Kconfig
>>> +++ b/drivers/input/keyboard/Kconfig
>>> @@ -560,7 +560,7 @@ config KEYBOARD_SUNKBD
>>>
>>> config KEYBOARD_SH_KEYSC
>>> tristate "SuperH KEYSC keypad support"
>>> - depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
>>> + depends on SUPERH || COMPILE_TEST
>>
>> I think dropping the SUPERH dependency is the right approach here, as all
>> SuperH platforms using the driver select ARCH_SHMOBILE.
>
> Thanks, I agree!
>
>> "sh_keysc" is used on SH_MIGOR, SH_ECOVEC, SH_KFR2R09,
>> SH_7722_SOLUTION_ENGINE,
>> and SH_7724_SOLUTION_ENGINE, which depend on either CPU_SUBTYPE_SH7722 or
>> CPU_SUBTYPE_SH7724, and both select ARCH_SHMOBILE.
>>
>>> help
>>> Say Y here if you want to use a keypad attached to the KEYSC block
>>> on SuperH processors such as sh7722 and sh7343.
>>
>> FWIW, this has never been enabled on sh7343. But CPU_SUBTYPE_SH7343 also
>> selects ARCH_SHMOBILE, so we're safe.
>
> You are right that the SH architecture is the main consumer at this
> point. I do however vaguely recall ARM shmobile G3EVM and G4EVM
> including sh7367 and some other SoC also having a KEYSC hardware block
> included. Due to the iffy interrupt controller upstream support for
> those boards/socs were killed off quite some time ago while (not)
> migrating to DT. So I think this KEYSC driver is simply a left over
> from that time.
Note that sh73a0 also has keysc, but I don't think it's usable on kzm9g
(after a quick look at the schematics).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] Remove ARCH_SHMOBILE
On Wed, Mar 2, 2016 at 6:30 PM, Geert Uytterhoeven wrote: > On Wed, Mar 2, 2016 at 2:55 AM, Simon Horman > wrote: >> [PATCH] Remove ARCH_SHMOBILE > > Please use a more appropriate one-line summary. > >> Since the removal of legacy (non-multiplatform) support this driver has not >> been used by any Renesas ARM based SoCs. >> >> 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. >> >> Signed-off-by: Simon Horman >> --- >> drivers/input/keyboard/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> Based on v4.5-rc1 >> >> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig >> index ddd8148d51d7..984532c6e689 100644 >> --- a/drivers/input/keyboard/Kconfig >> +++ b/drivers/input/keyboard/Kconfig >> @@ -560,7 +560,7 @@ config KEYBOARD_SUNKBD >> >> config KEYBOARD_SH_KEYSC >> tristate "SuperH KEYSC keypad support" >> - depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST >> + depends on SUPERH || COMPILE_TEST > > I think dropping the SUPERH dependency is the right approach here, as all > SuperH platforms using the driver select ARCH_SHMOBILE. Thanks, I agree! > "sh_keysc" is used on SH_MIGOR, SH_ECOVEC, SH_KFR2R09, > SH_7722_SOLUTION_ENGINE, > and SH_7724_SOLUTION_ENGINE, which depend on either CPU_SUBTYPE_SH7722 or > CPU_SUBTYPE_SH7724, and both select ARCH_SHMOBILE. > >> help >> Say Y here if you want to use a keypad attached to the KEYSC block >> on SuperH processors such as sh7722 and sh7343. > > FWIW, this has never been enabled on sh7343. But CPU_SUBTYPE_SH7343 also > selects ARCH_SHMOBILE, so we're safe. You are right that the SH architecture is the main consumer at this point. I do however vaguely recall ARM shmobile G3EVM and G4EVM including sh7367 and some other SoC also having a KEYSC hardware block included. Due to the iffy interrupt controller upstream support for those boards/socs were killed off quite some time ago while (not) migrating to DT. So I think this KEYSC driver is simply a left over from that time. Cheers, / magnus
Re: [PATCH] iommu/ipmmu-vmsa: Add r8a7795 DT binding
On Wed, Mar 2, 2016 at 11:55 PM, Joerg Roedel wrote: > On Mon, Feb 29, 2016 at 11:33:09PM +0900, Magnus Damm wrote: >> From: Magnus Damm >> >> Update the IPMMU DT binding documentation to include the r8a7795 compat >> string as well as the "renesas,ipmmu-main" property that on r8a7795 will >> be used to describe the topology and the relationship between the various >> cache IPMMU instances and the main IPMMU. >> >> Signed-off-by: Magnus Damm >> --- >> >> Written against linux-next tag next-20160229 >> >> Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 15 >> -- >> 1 file changed, 13 insertions(+), 2 deletions(-) > > Through which tree should this go? Unless anyone objects may I suggest going through your tree please! / magnus
[PATCH] net: sh_eth: avoid NULL pointer dereference in ring setup
From: Wolfram Sang
When allocating an skb fails, rxdesc is still NULL (or the previous ring
index on further iterations of the loop). However, this pointer is
dereferenced after the loop. So, make sure rxdesc is updated immediately
at the beginning of the loop.
Reported-by: coverity (CID 1056464)
Signed-off-by: Wolfram Sang
---
drivers/net/ethernet/renesas/sh_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c
b/drivers/net/ethernet/renesas/sh_eth.c
index a2767336b7c545..d5f13d54099734 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -1120,6 +1120,7 @@ static void sh_eth_ring_format(struct net_device *ndev)
/* build Rx ring buffer */
for (i = 0; i < mdp->num_rx_ring; i++) {
+ rxdesc = &mdp->rx_ring[i];
/* skb */
mdp->rx_skbuff[i] = NULL;
skb = netdev_alloc_skb(ndev, skbuff_size);
@@ -1128,7 +1129,6 @@ static void sh_eth_ring_format(struct net_device *ndev)
sh_eth_set_receive_align(skb);
/* RX descriptor */
- rxdesc = &mdp->rx_ring[i];
/* The size of the buffer is a multiple of 32 bytes. */
buf_len = ALIGN(mdp->rx_buf_sz, 32);
rxdesc->len = cpu_to_le32(buf_len << 16);
--
2.7.0
Re: [PATCH] iommu/ipmmu-vmsa: Add r8a7795 DT binding
On Mon, Feb 29, 2016 at 11:33:09PM +0900, Magnus Damm wrote: > From: Magnus Damm > > Update the IPMMU DT binding documentation to include the r8a7795 compat > string as well as the "renesas,ipmmu-main" property that on r8a7795 will > be used to describe the topology and the relationship between the various > cache IPMMU instances and the main IPMMU. > > Signed-off-by: Magnus Damm > --- > > Written against linux-next tag next-20160229 > > Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 15 > -- > 1 file changed, 13 insertions(+), 2 deletions(-) Through which tree should this go?
Re: [PATCH] Remove ARCH_SHMOBILE
I think you forgot a proper prefix in the subject...
Re: [PATCH v2] media: platform: rcar_jpu, sh_vou, vsp1: Use ARCH_RENESAS
Hello. On 3/2/2016 4:14 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. Acked-by: Geert Uytterhoeven Signed-off-by: Simon Horman --- Based on media-tree/master v2 * Do not update VIDEO_SH_VOU to use ARCH_RENESAS as this is used by some SH-based platforms and is not used by any ARM-based platforms so a dependency on ARCH_SHMOBILE is correct for that driver You forgot to remove it from the subject though. * Added Geert Uytterhoeven's Ack [...] MBR, Sergei
Re: [PATCH] arm64: dts: r8a7795: Add CAN FD support
Hello.
On 3/2/2016 10:29 AM, Ramesh Shanmugasundaram wrote:
Adds CAN FD controller node for r8a7795.
Note: CAN FD controller register base address specified in R-Car Gen3
Hardware User Manual v0.5E is incorrect. The correct address is:
CAN FD - 0xe66c
Signed-off-by: Ramesh Shanmugasundaram
---
Hi All,
This patch is based on linux-next (tag:next-20160225) with the
following
patches applied on top.
[PATCH v2] arm64: dts: r8a7795: Add CAN external clock support
[PATCH] arm64: dts: r8a7795: Add CAN support
The respective CAN subsystem changes are submitted separately here
(https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg013
88.html)
Thanks,
Ramesh
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index a88f8d8..5049ba6 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -553,6 +553,30 @@
status = "disabled";
};
+ canfd: canfd@e66c {
The node name should still be "can@e66c", I think.
Thanks for the review.
The SoC has CAN controller too
Yes, I figured. BTW, is the CAN-FD identical to the older CAN on the
hardware level? I haven't see you posting the CAN-FD driver yet...
and hence I chose this node name to differentiate. A grep of canfd on sysfs would tell if the
controller is enabled. The channels on "net" would still be named "canx".
I'll change it if you still feel "can@e66c" is more appropriate.
It is -- the node names should be generic and ePAPR even has the "can"
name listed explicitly in the section 2.2.2.
Thanks,
Ramesh
MBR, Sergei
Re: [PATCH v2] media: platform: rcar_jpu, sh_vou, vsp1: Use ARCH_RENESAS
Hi Simon, Note that the patch subject still mentions sh_vou. Otherwise: Acked-by: Hans Verkuil Regards, Hans On 03/02/16 12:00, Laurent Pinchart wrote: > Hi Simon, > > Thank you for the patch. > > On Wednesday 02 March 2016 10:14:51 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. >> >> Acked-by: Geert Uytterhoeven >> Signed-off-by: Simon Horman > > Acked-by: Laurent Pinchart > >> --- >> Based on media-tree/master >> >> v2 >> * Do not update VIDEO_SH_VOU to use ARCH_RENESAS as this is >> used by some SH-based platforms and is not used by any ARM-based platforms >> so a dependency on ARCH_SHMOBILE is correct for that driver >> * Added Geert Uytterhoeven's Ack >> --- >> drivers/media/platform/Kconfig | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig >> index 201f5c296a95..84e041c0a70e 100644 >> --- a/drivers/media/platform/Kconfig >> +++ b/drivers/media/platform/Kconfig >> @@ -238,7 +238,7 @@ config VIDEO_SH_VEU >> config VIDEO_RENESAS_JPU >> tristate "Renesas JPEG Processing Unit" >> depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA >> -depends on ARCH_SHMOBILE || COMPILE_TEST >> +depends on ARCH_RENESAS || COMPILE_TEST >> select VIDEOBUF2_DMA_CONTIG >> select V4L2_MEM2MEM_DEV >> ---help--- >> @@ -250,7 +250,7 @@ config VIDEO_RENESAS_JPU >> config VIDEO_RENESAS_VSP1 >> tristate "Renesas VSP1 Video Processing Engine" >> depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA >> -depends on (ARCH_SHMOBILE && OF) || COMPILE_TEST >> +depends on (ARCH_RENESAS && OF) || COMPILE_TEST >> select VIDEOBUF2_DMA_CONTIG >> ---help--- >>This is a V4L2 driver for the Renesas VSP1 video processing engine. >
Re: [PATCH 4/8] drivers/pinctrl: make sh-pfc/core.c explicitly non-modular
On Mon, Feb 29, 2016 at 9:48 PM, Paul Gortmaker
wrote:
> The Kconfig / Makefile currently controlling compilation of this code is:
>
> drivers/pinctrl/sh-pfc/Makefile:obj-$(CONFIG_PINCTRL_SH_PFC)+= sh-pfc.o
> drivers/pinctrl/sh-pfc/Makefile:sh-pfc-objs = core.o
> pinctrl.o
>
> drivers/pinctrl/sh-pfc/Kconfig:config PINCTRL_SH_PFC
> drivers/pinctrl/sh-pfc/Kconfig: def_bool y
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.
>
> Since module_init already wasn't being used in this code, the init
> ordering remains unchanged with this commit.
>
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
>
> We also delete the MODULE_LICENSE tag etc. since all that information
> was (or is now) contained at the top of the file in the comments.
>
> Cc: Laurent Pinchart
> Cc: Geert Uytterhoeven
> Cc: Linus Walleij
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: linux-g...@vger.kernel.org
> Signed-off-by: Paul Gortmaker
Acked-by: Geert Uytterhoeven
Linus: Feel free to take this with the other patches from the series.
Or do you prefer I queue it up in sh-pfc-for-v4.7?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/2] ASoC: sh: rcar: rsrc-card: don't open code of_device_get_match_data()
On Tue, Mar 01, 2016 at 05:39:20PM +0100, Wolfram Sang wrote: > Signed-off-by: Wolfram Sang Please ensure that your signoffs match the domain you're sending from, at least the domain part - I'm fairly sure you're the same person but it's not something I should need to think about. signature.asc Description: PGP signature
Re: [PATCH v2] media: platform: rcar_jpu, sh_vou, vsp1: Use ARCH_RENESAS
Hi Simon, Thank you for the patch. On Wednesday 02 March 2016 10:14:51 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. > > Acked-by: Geert Uytterhoeven > Signed-off-by: Simon Horman Acked-by: Laurent Pinchart > --- > Based on media-tree/master > > v2 > * Do not update VIDEO_SH_VOU to use ARCH_RENESAS as this is > used by some SH-based platforms and is not used by any ARM-based platforms > so a dependency on ARCH_SHMOBILE is correct for that driver > * Added Geert Uytterhoeven's Ack > --- > drivers/media/platform/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index 201f5c296a95..84e041c0a70e 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -238,7 +238,7 @@ config VIDEO_SH_VEU > config VIDEO_RENESAS_JPU > tristate "Renesas JPEG Processing Unit" > depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA > - depends on ARCH_SHMOBILE || COMPILE_TEST > + depends on ARCH_RENESAS || COMPILE_TEST > select VIDEOBUF2_DMA_CONTIG > select V4L2_MEM2MEM_DEV > ---help--- > @@ -250,7 +250,7 @@ config VIDEO_RENESAS_JPU > config VIDEO_RENESAS_VSP1 > tristate "Renesas VSP1 Video Processing Engine" > depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA > - depends on (ARCH_SHMOBILE && OF) || COMPILE_TEST > + depends on (ARCH_RENESAS && OF) || COMPILE_TEST > select VIDEOBUF2_DMA_CONTIG > ---help--- > This is a V4L2 driver for the Renesas VSP1 video processing engine. -- Regards, Laurent Pinchart
Re: [PATCH] can: rcar_canfd: Add Renesas R-Car CAN FD driver
On 03/02/2016 11:08 AM, Ramesh Shanmugasundaram wrote: I see no locking for the tx-path. >>> >>> I am not sure why locking is needed in tx-path? >> >> If the tx-path is shared between both channels you need locking as the >> networking subsystem may send one frame to each controller at the same >> time. > > Yes. Tx completion interrupt is shared by both channels but the Tx > FIFO, echo skbs, head, tail are maintained on a per channel basis. > Yes, net subsystem can send one frame to each channel at the same > time and the tx completion interrupt handler will traverse each > channel & update per channel context accordingly. Ok. Which instruction starts the transmit? Please add a comment to the code. You stop the tx_queue after this, so your code is racy, as the interrupt might happen in between. >>> However, looking at it again, I should move the incrementing of head >>> after the "sts" handing to be apt. What do you think? >> >> With one producer (one SW instance) and one consumer (the HW) you can >> write lockless code (if the HW allows it), but with two producers it's not >> possible. > > For a channel represented as netdev, there is still one producer (one > SW instance) isn't it? net acquires lock before calling xmit. The > consumer is tx completion interrupt handler which updates per channel > attributes only. Ok - I haven't looked at the code in depth yet. Now it's clear, that just the tx interrupt is shared. > Sorry if I am annoying. I have tested this with two channels > transmitting & receiving at the same time and it works fine. If I am > missing lock, I would like to understand it thoroughly before making > the change. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
RE: [PATCH] can: rcar_canfd: Add Renesas R-Car CAN FD driver
Hi Marc, > On 03/02/2016 09:41 AM, Ramesh Shanmugasundaram wrote: > >> Is the channel loopback mode configurable per channel? If so, please > >> remove the module parameter and make use of CAN_CTRLMODE_LOOPBACK to > >> configure it. > > > > The loopback setting is not truly a per channel attribute. It requires > > touching Rx rules which can be done only when the controller's global > > state is reset (during probe). > > CAN_CTRLMODE_LOOPBACK config option is possible only through .ndo_open > > of that channel but the global controller state needs to be > > operational by this time. As it is a global attribute & for the above > > reason, I choose the module option. > > I see, ok then. > > >>> CAN FD mode supports both Classical CAN & CAN FD frame formats. The > >>> controller supports ISO 11898-1:2015 CAN FD format only. > >>> > >>> This controller supports two channels and the driver can enable > >>> either or both of the channels. > >>> > >>> Driver uses Rx FIFOs (one per channel) for reception & Common FIFOs > >>> (one per channel) for transmission. Rx filter rules are configured > >>> to the minimum (one per channel) and it accepts Standard, Extended, > >>> Data & Remote Frame combinations. > >> > >> I see no locking for the tx-path. > > > > I am not sure why locking is needed in tx-path? > > If the tx-path is shared between both channels you need locking as the > networking subsystem may send one frame to each controller at the same > time. Yes. Tx completion interrupt is shared by both channels but the Tx FIFO, echo skbs, head, tail are maintained on a per channel basis. Yes, net subsystem can send one frame to each channel at the same time and the tx completion interrupt handler will traverse each channel & update per channel context accordingly. > > However, looking at it again, I should move the incrementing of head > > after the "sts" handing to be apt. What do you think? > > With one producer (one SW instance) and one consumer (the HW) you can > write lockless code (if the HW allows it), but with two producers it's not > possible. For a channel represented as netdev, there is still one producer (one SW instance) isn't it? net acquires lock before calling xmit. The consumer is tx completion interrupt handler which updates per channel attributes only. Sorry if I am annoying. I have tested this with two channels transmitting & receiving at the same time and it works fine. If I am missing lock, I would like to understand it thoroughly before making the change. Thanks for the help, Ramesh.
Re: [PATCH 2/2] phy: rcar-gen3-usb2: add fallback binding
On Wed, Mar 2, 2016 at 3:37 AM, Simon Horman wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Signed-off-by: Simon Horman
> --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> @@ -6,6 +6,12 @@ This file provides information on what the device node for
> the R-Car generation
> Required properties:
> - compatible: "renesas,usb2-phy-r8a7795" if the device is a part of an
> R8A7795
> SoC.
> + "renesas,usb2-phy-gen3" for a generic R-Car Gen3 compatible
> device.
"renesas,rcar-gen3-usb2-phy"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] phy: rcar-gen2: add fallback binding
On Wed, Mar 2, 2016 at 3:37 AM, Simon Horman wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Signed-off-by: Simon Horman
> --- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> @@ -7,6 +7,12 @@ Required properties:
> - compatible: "renesas,usb-phy-r8a7790" if the device is a part of R8A7790
> SoC.
> "renesas,usb-phy-r8a7791" if the device is a part of R8A7791
> SoC.
> "renesas,usb-phy-r8a7794" if the device is a part of R8A7794
> SoC.
> + "renesas,usb-phy-gen2" for a generic R-Car Gen2 compatible
> device.
"renesas,rcar-gen2-usb-phy"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] phy: rcar-gen3-usb2, rcar-gen2: Use ARCH_RENESAS
On Wed, Mar 2, 2016 at 3:25 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.
>
> Signed-off-by: Simon Horman
Acked-by: Geert Uytterhoeven
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -113,14 +113,14 @@ config PHY_MIPHY365X
>
> config PHY_RCAR_GEN2
> tristate "Renesas R-Car generation 2 USB PHY driver"
> - depends on ARCH_SHMOBILE
> + depends on ARCH_RENESAS
> depends on GENERIC_PHY
> help
> Support for USB PHY found on Renesas R-Car generation 2 SoCs.
>
> config PHY_RCAR_GEN3_USB2
> tristate "Renesas R-Car generation 3 USB 2.0 PHY driver"
> - depends on OF && ARCH_SHMOBILE
> + depends on OF && ARCH_RENESAS
FWIW, you may want to drop the dependency on OF, as this is implied by
ARCH_RENESAS.
Or you can handle that when adding/testing COMPILE_TEST support ;-)
> select GENERIC_PHY
> help
> Support for USB 2.0 PHY found on Renesas R-Car generation 3 SoCs.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] usb: gadget: renesas_usb3: Use ARCH_RENESAS
On Wed, Mar 2, 2016 at 3:17 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.
>
> Signed-off-by: Simon Horman
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] thermal: rcar: Use ARCH_RENESAS
On Wed, Mar 2, 2016 at 3:04 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.
>
> Signed-off-by: Simon Horman
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] Remove ARCH_SHMOBILE
Hi Simon,
On Wed, Mar 2, 2016 at 2:55 AM, Simon Horman wrote:
> [PATCH] Remove ARCH_SHMOBILE
Please use a more appropriate one-line summary.
> Since the removal of legacy (non-multiplatform) support this driver has not
> been used by any Renesas ARM based SoCs.
>
> 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.
>
> Signed-off-by: Simon Horman
> ---
> drivers/input/keyboard/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Based on v4.5-rc1
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index ddd8148d51d7..984532c6e689 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -560,7 +560,7 @@ config KEYBOARD_SUNKBD
>
> config KEYBOARD_SH_KEYSC
> tristate "SuperH KEYSC keypad support"
> - depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
> + depends on SUPERH || COMPILE_TEST
I think dropping the SUPERH dependency is the right approach here, as all
SuperH platforms using the driver select ARCH_SHMOBILE.
"sh_keysc" is used on SH_MIGOR, SH_ECOVEC, SH_KFR2R09, SH_7722_SOLUTION_ENGINE,
and SH_7724_SOLUTION_ENGINE, which depend on either CPU_SUBTYPE_SH7722 or
CPU_SUBTYPE_SH7724, and both select ARCH_SHMOBILE.
> help
> Say Y here if you want to use a keypad attached to the KEYSC block
> on SuperH processors such as sh7722 and sh7343.
FWIW, this has never been enabled on sh7343. But CPU_SUBTYPE_SH7343 also
selects ARCH_SHMOBILE, so we're safe.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] can: rcar_canfd: Add Renesas R-Car CAN FD driver
On 03/02/2016 09:41 AM, Ramesh Shanmugasundaram wrote: >> Is the channel loopback mode configurable per channel? If so, please >> remove the module parameter and make use of CAN_CTRLMODE_LOOPBACK to >> configure it. > > The loopback setting is not truly a per channel attribute. It > requires touching Rx rules which can be done only when the > controller's global state is reset (during probe). > CAN_CTRLMODE_LOOPBACK config option is possible only through > .ndo_open of that channel but the global controller state needs to be > operational by this time. As it is a global attribute & for the above > reason, I choose the module option. I see, ok then. >>> CAN FD mode supports both Classical CAN & CAN FD frame formats. The >>> controller supports ISO 11898-1:2015 CAN FD format only. >>> >>> This controller supports two channels and the driver can enable either >>> or both of the channels. >>> >>> Driver uses Rx FIFOs (one per channel) for reception & Common FIFOs >>> (one per channel) for transmission. Rx filter rules are configured to >>> the minimum (one per channel) and it accepts Standard, Extended, Data >>> & Remote Frame combinations. >> >> I see no locking for the tx-path. > > I am not sure why locking is needed in tx-path? If the tx-path is shared between both channels you need locking as the networking subsystem may send one frame to each controller at the same time. > However, looking at it again, I should move the incrementing of head > after the "sts" handing to be apt. What do you think? With one producer (one SW instance) and one consumer (the HW) you can write lockless code (if the HW allows it), but with two producers it's not possible. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH net-next] sh_eth, ravb: Use ARCH_RENESAS
On Wed, Mar 2, 2016 at 2:28 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.
>
> Signed-off-by: Simon Horman
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] pinctrl: sh-pfc: core: don't open code of_device_get_match_data()
On Tue, Mar 1, 2016 at 5:38 PM, Wolfram Sang wrote:
> From: Wolfram Sang
>
> This change will also make Coverity happy by avoiding a theoretical NULL
> pointer dereference; yet another reason is to use the above helper function
> to tighten the code and make it more readable.
>
> Signed-off-by: Wolfram Sang
Acked-by: Geert Uytterhoeven
Will queue in sh-pfc-for-v4.7.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] net: ethernet: renesas: ravb_main: don't open code of_device_get_match_data()
On Tue, Mar 1, 2016 at 5:37 PM, Wolfram Sang wrote:
> From: Wolfram Sang
>
> This change will also make Coverity happy by avoiding a theoretical NULL
> pointer dereference; yet another reason is to use the above helper function
> to tighten the code and make it more readable.
>
> Signed-off-by: Wolfram Sang
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/2] ASoC: sh: rcar: rsrc-card: don't open code of_device_get_match_data()
On Tue, Mar 1, 2016 at 5:39 PM, Wolfram Sang wrote:
> From: Wolfram Sang
>
> This change will also make Coverity happy by avoiding a theoretical NULL
> pointer dereference; yet another reason is to use the above helper function
> to tighten the code and make it more readable.
>
> Signed-off-by: Wolfram Sang
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] ASoC: sh: rcar: core: don't open code of_device_get_match_data()
On Tue, Mar 1, 2016 at 5:39 PM, Wolfram Sang wrote:
> From: Wolfram Sang
>
> This change will also make Coverity happy by avoiding a theoretical NULL
> pointer dereference; yet another reason is to use the above helper function
> to tighten the code and make it more readable.
>
> Signed-off-by: Wolfram Sang
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] gpu: drm: rcar-du: rcar_du_drv: don't open code of_device_get_match_data()
On Tue, Mar 1, 2016 at 5:37 PM, Wolfram Sang wrote:
> From: Wolfram Sang
>
> This change will also make Coverity happy by avoiding a theoretical NULL
> pointer dereference; yet another reason is to use the above helper function
> to tighten the code and make it more readable.
>
> Signed-off-by: Wolfram Sang
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] thermal: rcar_thermal: don't open code of_device_get_match_data()
On Tue, Mar 1, 2016 at 5:38 PM, Wolfram Sang wrote:
> From: Wolfram Sang
>
> This change will also make Coverity happy by avoiding a theoretical NULL
> pointer dereference; yet another reason is to use the above helper function
> to tighten the code and make it more readable.
>
> Signed-off-by: Wolfram Sang
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] i2c: rcar: don't open code of_device_get_match_data()
On Tue, Mar 1, 2016 at 5:36 PM, Wolfram Sang wrote:
> From: Wolfram Sang
>
> This change will also make Coverity happy by avoiding a theoretical NULL
> pointer dereference; yet another reason is to use the above helper function
> to tighten the code and make it more readable.
>
> Signed-off-by: Wolfram Sang
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] dmaengine: sh: shdmac: don't open code of_device_get_match_data()
On Tue, Mar 1, 2016 at 5:37 PM, Wolfram Sang wrote:
> From: Wolfram Sang
>
> This change will also make Coverity happy by avoiding a theoretical NULL
> pointer dereference; yet another reason is to use the above helper function
> to tighten the code and make it more readable.
>
> Signed-off-by: Wolfram Sang
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: [PATCH] can: rcar_canfd: Add Renesas R-Car CAN FD driver
Hi Oliver,
Thanks for the review.
> On 03/01/2016 10:34 AM, Ramesh Shanmugasundaram wrote:
> > This patch adds support for the CAN FD controller found in Renesas
> > R-Car SoCs. The controller operates in CAN FD mode by default. Two
> > test modes are available and can be enabled by the
> > "rcar_canfd.testmode" module parameter. Refer to Documentation/kernel-
> parameters.txt.
>
> (..)
>
> > +#ifdef CONFIG_DEBUG_FS
> > +#include
> > +
> > +static int rcar_canfd_showregs(struct seq_file *s, void *data) {
> > + struct rcar_canfd_channel *priv = s->private;
> > + u32 ch = priv->channel;
> > + u32 rf = ch + RCANFD_RFFIFO_IDX;
> > + u32 cf = RCANFD_CFFIFO_IDX;
> > + u32 val, offset, i;
> > +
> > + if (testmode)
> > + seq_printf(s, "RCANFD : testmode = %d\n", testmode);
> > + seq_printf(s, "RCANFD register dump: channel %u\n", ch);
> > + seq_printf(s, "%-40s: %x\n", "g: cfg",
> > + rcar_canfd_read(priv, RCANFD_GCFG));
>
> Why do you think you would need this kind of register dumps in debugfs?
>
> This could be interesting for development purposes - but in production
> drivers this is pretty unusual and needless.
I thought it would be useful when we add more features to the driver (e.g.
Gateway mode).
>
> I would sugest to remove either the testmode (already suggested by Marc)
> and this register dump stuff.
OK. I'll remove both.
Thanks,
Ramesh
RE: [PATCH] can: rcar_canfd: Add Renesas R-Car CAN FD driver
Hi Marc, Thanks for the review. > On 03/01/2016 10:34 AM, Ramesh Shanmugasundaram wrote: > > This patch adds support for the CAN FD controller found in Renesas > > R-Car SoCs. The controller operates in CAN FD mode by default. Two > > test modes are available and can be enabled by the > > "rcar_canfd.testmode" module parameter. Refer to Documentation/kernel- > parameters.txt. > > Is the channel loopback mode configurable per channel? If so, please > remove the module parameter and make use of CAN_CTRLMODE_LOOPBACK to > configure it. The loopback setting is not truly a per channel attribute. It requires touching Rx rules which can be done only when the controller's global state is reset (during probe). CAN_CTRLMODE_LOOPBACK config option is possible only through .ndo_open of that channel but the global controller state needs to be operational by this time. As it is a global attribute & for the above reason, I choose the module option. > > > CAN FD mode supports both Classical CAN & CAN FD frame formats. The > > controller supports ISO 11898-1:2015 CAN FD format only. > > > > This controller supports two channels and the driver can enable either > > or both of the channels. > > > > Driver uses Rx FIFOs (one per channel) for reception & Common FIFOs > > (one per channel) for transmission. Rx filter rules are configured to > > the minimum (one per channel) and it accepts Standard, Extended, Data > > & Remote Frame combinations. > > I see no locking for the tx-path. I am not sure why locking is needed in tx-path? However, looking at it again, I should move the incrementing of head after the "sts" handing to be apt. What do you think? Thanks, Ramesh
Re: [PATCH] drivers: sh: Use ARCH_RENESAS
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.
> ---
> drivers/sh/pm_runtime.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Based on v4.5-rc6
>
> diff --git a/drivers/sh/pm_runtime.c b/drivers/sh/pm_runtime.c
> index a9bac3bf20de..aa2ce227e3eb 100644
> --- a/drivers/sh/pm_runtime.c
> +++ b/drivers/sh/pm_runtime.c
> @@ -34,7 +34,7 @@ static struct pm_clk_notifier_block platform_bus_notifier =
> {
>
> static int __init sh_pm_runtime_init(void)
> {
> - if (IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_ARCH_SHMOBILE)) {
> + if (IS_ENABLED(CONFIG_ARCH_RENESAS)) {
> if (!of_find_compatible_node(NULL, NULL,
> "renesas,cpg-mstp-clocks"))
> return 0;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2] arm64: dts: r8a7795: Add CAN FD support
Adds CAN FD controller node for r8a7795.
Note: CAN FD controller register base address specified in R-Car Gen3
Hardware User Manual v0.5E is incorrect. The correct address is:
CAN FD - 0xe66c
Signed-off-by: Ramesh Shanmugasundaram
---
Thanks Sergei, Simon for the comments.
Changes since v1:
As suggested by Sergei, Simon
* Changed node name from canfd@ to can@
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index a88f8d8..9185688 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -553,6 +553,30 @@
status = "disabled";
};
+ canfd: can@e66c {
+ compatible = "renesas,r8a7795-canfd",
+"renesas,rcar-gen3-canfd";
+ reg = <0 0xe66c 0 0x8000>;
+ interrupts = ,
+ ;
+ clocks = <&cpg CPG_MOD 914>,
+ <&cpg CPG_CORE R8A7795_CLK_CANFD>,
+ <&can_clk>;
+ clock-names = "fck", "canfd", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A7795_CLK_CANFD>;
+ assigned-clock-rates = <4000>;
+ power-domains = <&cpg>;
+ status = "disabled";
+
+ channel0 {
+ status = "disabled";
+ };
+
+ channel1 {
+ status = "disabled";
+ };
+ };
+
hscif0: serial@e654 {
compatible = "renesas,hscif-r8a7795",
"renesas,rcar-gen3-hscif",
--
1.9.1
Re: [PATCH] tty: sh-sci: Use ARCH_RENESAS
On Wed, Mar 2, 2016 at 2:35 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.
>
> Signed-off-by: Simon Horman
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] iommu/ipmmu-vmsa: Add r8a7795 DT binding
Hi Magnus,
On Mon, Feb 29, 2016 at 3:33 PM, Magnus Damm wrote:
> From: Magnus Damm
>
> Update the IPMMU DT binding documentation to include the r8a7795 compat
> string as well as the "renesas,ipmmu-main" property that on r8a7795 will
> be used to describe the topology and the relationship between the various
> cache IPMMU instances and the main IPMMU.
>
> Signed-off-by: Magnus Damm
Thanks for your patch!
> ---
>
> Written against linux-next tag next-20160229
>
> Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 15
> --
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> --- 0001/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
> +++ work/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
> 2016-02-29 23:25:15.540513000 +0900
> @@ -7,23 +7,34 @@ connected to the IPMMU through a port ca
>
> Required Properties:
>
> - - compatible: Must contain SoC-specific and generic entries from below.
> + - compatible: Must contain SoC-specific and generic entry below in case
> +the device is compatible with the R-Car Gen2 VMSA-compatible IPMMU.
>
> - "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU.
> - "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU.
> - "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU.
> - "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU.
> - "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU.
> +- "renesas,ipmmu-r8a7795" for the R8A7795 (R-Car H3) IPMMU.
> - "renesas,ipmmu-vmsa" for generic R-Car Gen2 VMSA-compatible IPMMU.
>
>- reg: Base address and size of the IPMMU registers.
>- interrupts: Specifiers for the MMU fault interrupts. For instances that
> support secure mode two interrupts must be specified, for non-secure and
> secure mode, in that order. For instances that don't support secure mode
> a
> -single interrupt must be specified.
> +single interrupt must be specified. Not required for cache IPMMUs.
>
>- #iommu-cells: Must be 1.
>
> +Optional properties:
> +
> + - renesas,ipmmu-main: reference to the main IPMMU instance in two cells.
> +The first cell is a phandle to the main IPMMU and the second cell is
> +the interrupt bit number associated with the particular cache IPMMU
> device.
> +The interrupt bit number needs to match the main IPMMU IMSSTR register.
> +Only used by cache IPMMU instances.
> +
> +
I think it would be good to include an example of how the optional properties
should be used.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] arm64: dts: r8a7795: Add CAN FD support
On Wed, Mar 02, 2016 at 07:29:04AM +, Ramesh Shanmugasundaram wrote:
> Hi Sergei,
>
> > On 3/1/2016 1:04 PM, Ramesh Shanmugasundaram wrote:
> >
> > > Adds CAN FD controller node for r8a7795.
> > >
> > > Note: CAN FD controller register base address specified in R-Car Gen3
> > > Hardware User Manual v0.5E is incorrect. The correct address is:
> > >
> > > CAN FD - 0xe66c
> > >
> > > Signed-off-by: Ramesh Shanmugasundaram
> > >
> > > ---
> > > Hi All,
> > >
> > > This patch is based on linux-next (tag:next-20160225) with the
> > following
> > > patches applied on top.
> > >
> > > [PATCH v2] arm64: dts: r8a7795: Add CAN external clock support
> > > [PATCH] arm64: dts: r8a7795: Add CAN support
> > >
> > > The respective CAN subsystem changes are submitted separately here
> > > (https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg013
> > > 88.html)
> > >
> > > Thanks,
> > > Ramesh
> > > ---
> > > arch/arm64/boot/dts/renesas/r8a7795.dtsi | 24
> > > 1 file changed, 24 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > > b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > > index a88f8d8..5049ba6 100644
> > > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > > @@ -553,6 +553,30 @@
> > > status = "disabled";
> > > };
> > >
> > > + canfd: canfd@e66c {
> >
> > The node name should still be "can@e66c", I think.
>
> Thanks for the review.
>
> The SoC has CAN controller too and hence I chose this node name to
> differentiate. A grep of canfd on sysfs would tell if the controller is
> enabled. The channels on "net" would still be named "canx".
>
> I'll change it if you still feel "can@e66c" is more appropriate.
FWIW, "can@e66c" seems more appropriate to me.
