Re: [PATCH v3 01/13] drm: Don't include in
vmwgfx part: Reviewed-by: Sinclair Yeh On Tue, Nov 29, 2016 at 11:04:31AM +0200, Laurent Pinchart wrote: > used to define most of the in-kernel KMS API. It has > now been split into separate files for each object type, but still > includes most other KMS headers to avoid breaking driver compilation. > > As a step towards fixing that problem, remove the inclusion of > from and include it instead where > appropriate. Also remove the forward declarations of the drm_encoder and > drm_encoder_helper_funcs structures from as they're not > needed in the header. > > now has to include and contain a > forward declaration of struct drm_encoder in order to allow including it > as the first header in a compilation unit. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 1 + > drivers/gpu/drm/ast/ast_drv.h | 1 + > drivers/gpu/drm/bochs/bochs.h | 1 + > drivers/gpu/drm/cirrus/cirrus_drv.h | 1 + > drivers/gpu/drm/drm_connector.c | 1 + > drivers/gpu/drm/drm_crtc_helper.c | 1 + > drivers/gpu/drm/drm_edid.c | 1 + > drivers/gpu/drm/drm_mode_config.c | 1 + > drivers/gpu/drm/drm_of.c| 1 + > drivers/gpu/drm/drm_plane_helper.c | 1 + > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 2 ++ > drivers/gpu/drm/gma500/psb_intel_drv.h | 1 + > drivers/gpu/drm/i915/intel_drv.h| 1 + > drivers/gpu/drm/mgag200/mgag200_drv.h | 1 + > drivers/gpu/drm/nouveau/nouveau_connector.h | 1 + > drivers/gpu/drm/qxl/qxl_drv.h | 1 + > drivers/gpu/drm/radeon/radeon_mode.h| 1 + > drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 1 + > drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 1 + > drivers/gpu/drm/tegra/drm.h | 1 + > drivers/gpu/drm/vc4/vc4_drv.h | 2 ++ > drivers/gpu/drm/virtio/virtgpu_drv.h| 1 + > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 1 + > include/drm/drm_crtc.h | 3 --- > include/drm/drm_encoder.h | 3 +++ > include/drm/drm_encoder_slave.h | 1 + > include/drm/drm_modeset_helper_vtables.h| 1 + > 27 files changed, 30 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h > b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h > index 1e23334b07fb..fac06064a8f5 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h > @@ -32,6 +32,7 @@ > > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h > index 908011d2c8f5..6f3b6f50cf52 100644 > --- a/drivers/gpu/drm/ast/ast_drv.h > +++ b/drivers/gpu/drm/ast/ast_drv.h > @@ -28,6 +28,7 @@ > #ifndef __AST_DRV_H__ > #define __AST_DRV_H__ > > +#include > #include > > #include > diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h > index 32dfe418cc98..f626bab7f5e3 100644 > --- a/drivers/gpu/drm/bochs/bochs.h > +++ b/drivers/gpu/drm/bochs/bochs.h > @@ -4,6 +4,7 @@ > #include > #include > #include > +#include > #include > > #include > diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h > b/drivers/gpu/drm/cirrus/cirrus_drv.h > index 2188d6b61b3e..b59aeef4635a 100644 > --- a/drivers/gpu/drm/cirrus/cirrus_drv.h > +++ b/drivers/gpu/drm/cirrus/cirrus_drv.h > @@ -13,6 +13,7 @@ > > #include > > +#include > #include > > #include > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index b5c6a8ee831e..5f1e1f190d30 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -23,6 +23,7 @@ > #include > #include > #include > +#include > > #include "drm_crtc_internal.h" > #include "drm_internal.h" > diff --git a/drivers/gpu/drm/drm_crtc_helper.c > b/drivers/gpu/drm/drm_crtc_helper.c > index 5d2cb138eba6..b3fc23313cc3 100644 > --- a/drivers/gpu/drm/drm_crtc_helper.c > +++ b/drivers/gpu/drm/drm_crtc_helper.c > @@ -36,6 +36,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 7eec18925b70..a9e3cc3990c1 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -35,6 +35,7 @@ > #include > #include > #include > +#include > #include > > #define version_greater(edid, maj, min) \ > diff --git a/drivers/gpu/drm/drm_mode_config.c > b/drivers/gpu/drm/drm_mode_config.c > index 2735a5847ffa..09b1d8f267a6 100644 > --- a/drivers/gpu/drm/drm_mode_config.c > +++ b/drivers/gpu/drm/drm_mode_config.c > @@ -20,6 +20,7 @@ > * OF THIS SOFTWARE. > */ > > +#include > #include > #include > > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c > index 47848ed8ca48..b5f2f0fece99 100644 > --- a/drivers/gpu/drm/drm_of.c > +++ b/drivers/gpu/drm/drm_of.c > @
Re: [PATCH v2 3/3 pci/next] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar
On Fri, Dec 02, 2016 at 11:37:00AM +0100, Simon Horman wrote:
> Add fallback compatibility string for the R-Car Gen 3 family. This is in
> keeping with the both the existing fallback compatibility string for the
> R-Car Gen 2 family and the fallback scheme being adopted wherever
> appropriate for drivers for Renesas SoCs.
>
> Signed-off-by: Simon Horman
> ---
> v2
> * Move fallback binding to below SoC specific bindings it covers
> in implementation
> ---
> Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
> drivers/pci/host/pcie-rcar.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> index 6cf99690eef9..eee518db90b9 100644
> --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> @@ -7,6 +7,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
> "renesas,pcie-r8a7793" for the R8A7793 SoC;
> "renesas,pcie-r8a7795" for the R8A7795 SoC;
> "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
> + "renesas,pcie-rcar-gen3" 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
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index 85971bc276c6..72058bc7af5c 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -1078,6 +1078,8 @@ static const struct of_device_id rcar_pcie_of_match[] =
> {
> { .compatible = "renesas,pcie-rcar-gen2",
> .data = rcar_pcie_hw_init_gen2 },
> { .compatible = "renesas,pcie-r8a7795", .data = rcar_pcie_hw_init },
> + { .compatible = "renesas,pcie-rcar-gen3",
> + .data = rcar_pcie_hw_init_hw_init },
It looks like I failed to compile-test this.
s/rcar_pcie_hw_init_hw_init/rcar_pcie_hw_init/
> {},
> };
>
> --
> 2.7.0.rc3.207.g0ac5344
>
Re: [PATCH pci/next] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar
Hi Simon,
[auto build test ERROR on pci/next]
url:
https://github.com/0day-ci/linux/commits/Simon-Horman/PCI-rcar-Add-gen3-fallback-compatibility-string-for-pcie-rcar/20161203-030440
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> drivers/pci/host/pcie-rcar.c:1081:12: error: 'rcar_pcie_hw_init_hw_init'
>> undeclared here (not in a function)
.data = rcar_pcie_hw_init_hw_init },
^
vim +/rcar_pcie_hw_init_hw_init +1081 drivers/pci/host/pcie-rcar.c
1075.data = rcar_pcie_hw_init_gen2 },
1076 { .compatible = "renesas,pcie-r8a7790",
1077.data = rcar_pcie_hw_init_gen2 },
1078 { .compatible = "renesas,pcie-r8a7791",
1079.data = rcar_pcie_hw_init_gen2 },
1080 { .compatible = "renesas,pcie-rcar-gen3",
> 1081.data = rcar_pcie_hw_init_hw_init },
1082 { .compatible = "renesas,pcie-r8a7795", .data =
rcar_pcie_hw_init },
1083 {},
1084 };
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH v4 5/4] thermal: rcar_gen3_thermal: restrict to 64BIT
COMPILE_TEST triggers problems on 32 bit machines, so limit this driver to 64BIT for now. This is no loss because the hardware is only available on 64 bit SoCs anyhow. After we obtained more data from the hardware engineers, we will refactor the code to be usable with COMPILE_TEST. Signed-off-by: Wolfram Sang --- buildbot reported the problem and seems to be happy now. drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 3912d24a07b10f..edaed1282791bf 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -247,7 +247,7 @@ config RCAR_THERMAL config RCAR_GEN3_THERMAL tristate "Renesas R-Car Gen3 thermal driver" - depends on ARCH_RENESAS || COMPILE_TEST + depends on ARCH_RENESAS && 64BIT depends on HAS_IOMEM depends on OF help -- 2.10.2
Re: [RFC 2/3] dts: arm: genmai: Add MAXDESREF4x spidev
Hi Jacopo,
On Fri, Dec 2, 2016 at 4:43 PM, Jacopo Mondi wrote:
> Add device node for the MAX11100 evaluation board connected to Genmai's
> CN2.
> The evaluation kit is connected to 4 GPIO lines configured ad bitbanged
3 GPIO lines?
configured as
> SPI master interface
>
> Signed-off-by: Jacopo Mondi
> ---
> arch/arm/boot/dts/r7s72100-genmai.dts | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts
> b/arch/arm/boot/dts/r7s72100-genmai.dts
> index 233908b..89a1977 100644
> --- a/arch/arm/boot/dts/r7s72100-genmai.dts
> +++ b/arch/arm/boot/dts/r7s72100-genmai.dts
> @@ -46,6 +46,24 @@
> };
> };
>
> + spi-gpio {
> + compatible = "spi-gpio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
Why do you need pinctrl-names?
You have no pinctrl configuration.
> +
> + gpio-miso = <&port11 10 GPIO_ACTIVE_HIGH>;
> + gpio-sck = <&port11 9 GPIO_ACTIVE_HIGH>;
> + num-chipselects = <1>;
> + cs-gpios = <&port11 11 GPIO_ACTIVE_HIGH>;
> + status = "ok";
> +
> + maxrefdes4x {
Missing unit address "@0"
> + compatible = "linux,spidev";
These days you should use "maxim,max11100", and at that compatible
value to drivers/spi/spidev.c
> + reg = <0>;
> + spi-max-frequency = <24>;
> + };
> + };
> };
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] net: renesas: ravb: unintialized return value
From: Dan Carpenter
Date: Thu, 1 Dec 2016 23:57:44 +0300
> We want to set the other "err" variable here so that we can return it
> later. My version of GCC misses this issue but I caught it with a
> static checker.
>
> Fixes: 9f70eb339f52 ("net: ethernet: renesas: ravb: fix fixed-link phydev
> leaks")
> Signed-off-by: Dan Carpenter
Applied.
Re: [PATCH v3] sh_eth: remove unchecked interrupts for RZ/A1
From: Chris Brandt
Date: Thu, 1 Dec 2016 13:32:14 -0500
> When streaming a lot of data and the RZ/A1 can't keep up, some status bits
> will get set that are not being checked or cleared which cause the
> following messages and the Ethernet driver to stop working. This
> patch fixes that issue.
>
> irq 21: nobody cared (try booting with the "irqpoll" option)
> handlers:
> [] sh_eth_interrupt
> Disabling IRQ #21
>
> Fixes: db893473d313a4ad ("sh_eth: Add support for r7s72100")
> Signed-off-by: Chris Brandt
> Acked-by: Sergei Shtylyov
Applied and queued up for -stable, thanks.
[RFC 0/3] Enable and test MAXREFDES4# on Genmai board
Hello Magnus and Geert, list, this patch series enable the creation of a spidev device though which interface to a MAXREFDES4# MAX11100-ADC evaluation kit connected to Genmai CON2 expansion header. The series is not intended for inclusion but will probably serve as base for future integration of MAX11100 ADC driver. The series is based on branch "genmai-gpio-and-pfc" of Geert's tree at git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git and target Linux v3.18 The series fix a compilation error for RZ gpio driver and register a gpio based SPI master on CON2 pins. The test bed is setup as: P11_11 (CN2 pin 5) connected as CS P11_10 (CN2 pin 6) connected as MISO P11_9 (CN2 pin 7) connected as SCLK P11_8 (CN2 pin 8) connected as AIN The ADC input is connected to gpio port 11 pin 8 (gpio863) and ADC functionalities have been tested reading the results of successive analog-to-digital conversions and verifying they match the gpio863 output value. Thanks j Jacopo Mondi (3): gpio-rz: Port to v3.18 dts: arm: genmai: Add MAXDESREF4x spidev spidev: Add back "linux,spidev" as compatible arch/arm/boot/dts/r7s72100-genmai.dts | 22 ++ drivers/gpio/gpio-rz.c| 3 ++- drivers/spi/spidev.c | 1 + 3 files changed, 25 insertions(+), 1 deletion(-) -- 2.7.4
RE: [RFC 1/3] gpio-rz: Port to v3.18
Hi Jacopo, On 12/2/2016, Jacopo Mondi wrote: > > What tree/branch is this based off? > > > > Quoting the cover letter: > The series is based on branch "genmai-gpio-and-pfc" of Geert's tree at > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git > and target Linux v3.18 > > Thanks > j OK. That's what I thought. I didn't see a cover letter come through, just the 3 patches. Chris
Re: [RFC 1/3] gpio-rz: Port to v3.18
Hi Chris,
On 02/12/2016 17:23, Chris Brandt wrote:
On 12/2/2016, Jacopo Mondi wrote:
Fix invalid return value in gpio remove function
Signed-off-by: Jacopo Mondi
---
drivers/gpio/gpio-rz.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-rz.c b/drivers/gpio/gpio-rz.c index
a933dab..cb8f785 100644
--- a/drivers/gpio/gpio-rz.c
+++ b/drivers/gpio/gpio-rz.c
@@ -175,7 +175,8 @@ static int rz_gpio_remove(struct platform_device
*pdev) {
struct rz_gpio_priv *p = platform_get_drvdata(pdev);
- return gpiochip_remove(&p->gpio_chip);
+ gpiochip_remove(&p->gpio_chip);
+ return 0;
}
static const struct of_device_id rz_gpio_dt_ids[] = {
--
2.7.4
What tree/branch is this based off?
Quoting the cover letter:
The series is based on branch "genmai-gpio-and-pfc" of Geert's tree at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
and target Linux v3.18
Thanks
j
Chris
Re: [PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks
Hi Russell, On Friday 02 Dec 2016 16:08:17 Russell King - ARM Linux wrote: > On Fri, Dec 02, 2016 at 05:43:43PM +0200, Laurent Pinchart wrote: > > DW_HDMI_QUIRK_FC_INVIDCONF is indeed a bad name, I'll fix that. > > > > Do you know why this function needs to write to the HDMI_FC_INVIDCONF > > register four times in the normal case, and once only for IMX6DL ? > > (I don't have much time at present, I'm buried in ARM64 crud trying to > get a platform to boot, and working out how to debug an ARM64 platform > that even earlycon doesn't work on... no printascii() types of easy > debug facilities on ARM64 make this job several orders of magnitude > harder than it needs to be...) Thanks all the more for taking time to reply. > It prevents a magenta line down the left hand side of the screen, which > is caused when the frame composer in the HDMI Tx gets confused - > according to the errata, it does a load of maths when you write to the > frame composer registers, and sometimes it doesn't update properly. > > So, the four writes (and the number is critical) is there to persuade > the IP to do the maths with the right values so the internal timings > are correct. > > The rather confusing thing is - it's actually IMX6Q which has the more > severe errata, not IMX6DL - the workaround of four writes is applied > in the 6Q case. > > It's covered by ERR004308 in the IMX6Q Errata document (search for > IMX6DQCE). It isn't mentioned in the IMX6DL documentation, but it > seems that similar workaround of one write is necessary there. > > Some of this was determined by experimentation in conjunction with the > errata documentation - I remember it took a while to get it right so > that we didn't ever see the magenta line. That's interesting. I'll test the different options on my Renesas platform (no write, one write, four writes) and see what is needed. Could anyone perform the same tests on a Rockchip RK3288 system ? -- Regards, Laurent Pinchart
RE: [RFC 1/3] gpio-rz: Port to v3.18
On 12/2/2016, Jacopo Mondi wrote:
> Fix invalid return value in gpio remove function
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/gpio/gpio-rz.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-rz.c b/drivers/gpio/gpio-rz.c index
> a933dab..cb8f785 100644
> --- a/drivers/gpio/gpio-rz.c
> +++ b/drivers/gpio/gpio-rz.c
> @@ -175,7 +175,8 @@ static int rz_gpio_remove(struct platform_device
> *pdev) {
> struct rz_gpio_priv *p = platform_get_drvdata(pdev);
>
> - return gpiochip_remove(&p->gpio_chip);
> + gpiochip_remove(&p->gpio_chip);
> + return 0;
> }
>
> static const struct of_device_id rz_gpio_dt_ids[] = {
> --
> 2.7.4
What tree/branch is this based off?
Chris
Re: [PATCH 11/22] drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter
On Fri, Dec 02, 2016 at 05:51:18PM +0200, Laurent Pinchart wrote: > Hi Russell, > > On Friday 02 Dec 2016 14:18:08 Russell King - ARM Linux wrote: > > On Fri, Dec 02, 2016 at 01:43:26AM +0200, Laurent Pinchart wrote: > > > From: Kieran Bingham > > > > > > The current code hard codes the call of hdmi_phy_configure() to be 8bpp > > > and provides extraneous error checking to verify that this hardcoded > > > value is correct. > > > > > > Simplify the passing of the data by setting the parameter to be of the > > > enum type it represents rather than converting and then verifying the > > > value. This will allow the compiler to check the value is acceptable > > > based on the type, and remove the dead code that we currently have. > > > > I think you're expecting too much of the compiler there. There's no > > requirement for the compiler to check that an enum type is passed one > > of it's defined values. > > You're right. > > Given that the current driver hardcodes the resolution value to 8bpp, how > about just dropping the argument ? We can always add it back later if/when > needed. Definitely - there's no point having features in the driver which no one uses. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks
On Fri, Dec 02, 2016 at 05:43:43PM +0200, Laurent Pinchart wrote: > DW_HDMI_QUIRK_FC_INVIDCONF is indeed a bad name, I'll fix that. > > Do you know why this function needs to write to the HDMI_FC_INVIDCONF > register four times in the normal case, and once only for IMX6DL ? (I don't have much time at present, I'm buried in ARM64 crud trying to get a platform to boot, and working out how to debug an ARM64 platform that even earlycon doesn't work on... no printascii() types of easy debug facilities on ARM64 make this job several orders of magnitude harder than it needs to be...) It prevents a magenta line down the left hand side of the screen, which is caused when the frame composer in the HDMI Tx gets confused - according to the errata, it does a load of maths when you write to the frame composer registers, and sometimes it doesn't update properly. So, the four writes (and the number is critical) is there to persuade the IP to do the maths with the right values so the internal timings are correct. The rather confusing thing is - it's actually IMX6Q which has the more severe errata, not IMX6DL - the workaround of four writes is applied in the 6Q case. It's covered by ERR004308 in the IMX6Q Errata document (search for IMX6DQCE). It isn't mentioned in the IMX6DL documentation, but it seems that similar workaround of one write is necessary there. Some of this was determined by experimentation in conjunction with the errata documentation - I remember it took a while to get it right so that we didn't ever see the magenta line. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[RFC 3/3] spidev: Add back "linux,spidev" as compatible
spidev is not meant to be configured directly from DTS anymore.
Since we're prototyping, add the "linux,spidev" compatibility string
back
Signed-off-by: Jacopo Mondi
---
drivers/spi/spidev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 6941e04..e767265 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -690,6 +690,7 @@ static int spidev_remove(struct spi_device *spi)
}
static const struct of_device_id spidev_dt_ids[] = {
+ { .compatible = "linux,spidev" },
{ .compatible = "rohm,dh2228fv" },
{},
};
--
2.7.4
[RFC 2/3] dts: arm: genmai: Add MAXDESREF4x spidev
Add device node for the MAX11100 evaluation board connected to Genmai's
CN2.
The evaluation kit is connected to 4 GPIO lines configured ad bitbanged
SPI master interface
Signed-off-by: Jacopo Mondi
---
arch/arm/boot/dts/r7s72100-genmai.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts
b/arch/arm/boot/dts/r7s72100-genmai.dts
index 233908b..89a1977 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -46,6 +46,24 @@
};
};
+ spi-gpio {
+ compatible = "spi-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+
+ gpio-miso = <&port11 10 GPIO_ACTIVE_HIGH>;
+ gpio-sck = <&port11 9 GPIO_ACTIVE_HIGH>;
+ num-chipselects = <1>;
+ cs-gpios = <&port11 11 GPIO_ACTIVE_HIGH>;
+ status = "ok";
+
+ maxrefdes4x {
+ compatible = "linux,spidev";
+ reg = <0>;
+ spi-max-frequency = <24>;
+ };
+ };
};
&extal_clk {
@@ -123,3 +141,7 @@
spi-max-frequency = <500>;
};
};
+
+&port11 {
+ status = "okay";
+};
--
2.7.4
Re: [PATCH 11/22] drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter
Hi Russell,
On Friday 02 Dec 2016 14:18:08 Russell King - ARM Linux wrote:
> On Fri, Dec 02, 2016 at 01:43:26AM +0200, Laurent Pinchart wrote:
> > From: Kieran Bingham
> >
> > The current code hard codes the call of hdmi_phy_configure() to be 8bpp
> > and provides extraneous error checking to verify that this hardcoded
> > value is correct.
> >
> > Simplify the passing of the data by setting the parameter to be of the
> > enum type it represents rather than converting and then verifying the
> > value. This will allow the compiler to check the value is acceptable
> > based on the type, and remove the dead code that we currently have.
>
> I think you're expecting too much of the compiler there. There's no
> requirement for the compiler to check that an enum type is passed one
> of it's defined values.
You're right.
Given that the current driver hardcodes the resolution value to 8bpp, how
about just dropping the argument ? We can always add it back later if/when
needed.
> Try building this and see if it even produces a warning:
>
> enum foo {
> FOO_1,
> FOO_2,
> };
>
> int func(enum foo foo)
> {
> return foo;
> }
>
> int test_1(void)
> {
> return func(FOO_1);
> }
>
> int test_2(void)
> {
> return func(5);
> }
--
Regards,
Laurent Pinchart
Re: [PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks
Hi Russell,
On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote:
> On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote:
> > From: Kieran Bingham
> >
> > The dw-hdmi driver declares a dev_type to distinguish platform specific
> > changes. Replace this with a quirk field, so that the platform can
> > specify the required quirks for the driver, rather than the driver
> > becoming conditional on multiple platforms.
> >
> > As part of this, we rename the dw-hdmi 'spare' which is defined as the
> > SVSRET bit in later documentation.
>
> I'd really prefer that we did not go down the broken route of adding
> a set of "quirk" flags - look at what a mess SDHCI has become through
> allowing that kind of practice.
>
> I'd much rather we find a saner structure to this - and we know that
> the hardware has ID registers in it which can be used (so far) to
> identify the buggy hardware.
I'd much prefer something that would allow runtime identification of the
device and the corresponding actions to be taken. However, the amount of
documentation we have on the DWC HDMI TX IP core (and the associated PHY) is
pretty limited, given that Synopsys doesn't make the documentation available
publicly. Changes made to the IP core by integrators could complicate this
further. I'm trying to gather as much information as possible to make clean
the code up, for instance by trying to identify the PHYs used on the various
platforms we support. Progress is slow on that front, there isn't enough
leaked information available online :-) I haven't given up though, but I'll
need more time.
I don't like quirks much either. They are however already used today, even if
we trigger them through dev_type instead of quirk flags. This patch came from
a previous version found in a BSP that simply sprinkled several if (hdmi-
>dev_type == RCAR_HDMI) through the code. For instance,
- if (hdmi->dev_type == RK3288_HDMI)
+ if (hdmi->dev_type == RK3288_HDMI || hdmi->dev_type == RCAR_HDMI)
dw_hdmi_phy_enable_spare(hdmi, 1);
which I think is worse than flags as it would quickly degenerate to spaghetti
code.
For this specific case, we've managed to identify that on Renesas platforms
the bit set by this function is called SVSRET. Its usage isn't clear yet, but
I suspect it to control one of the PHY input control signals, like the other
bits in the same register. I'm trying to get more information to clean the
implementation further, hopefully with a way to determine whether the signal
is used based on PHY identification.
This is all work in progress, and if anyone has access to any documentation
and can provide additional information I'll be grateful.
> > Signed-off-by: Kieran Bingham
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/bridge/dw-hdmi.c| 14 ++
> > drivers/gpu/drm/bridge/dw-hdmi.h| 4 ++--
> > drivers/gpu/drm/imx/dw_hdmi-imx.c | 3 +--
> > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
> > include/drm/bridge/dw_hdmi.h| 12 +---
> > 5 files changed, 15 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/dw-hdmi.c index 06a44a2cdf3b..26607185722f
> > 100644
> > --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> > @@ -118,7 +118,6 @@ struct dw_hdmi {
> > struct drm_bridge bridge;
> > struct platform_device *audio;
> >
> > - enum dw_hdmi_devtype dev_type;
> > struct device *dev;
> > struct clk *isfr_clk;
> > struct clk *iahb_clk;
> > @@ -896,11 +895,11 @@ static void dw_hdmi_phy_enable_tmds(struct dw_hdmi
> > *hdmi, u8 enable)
> > HDMI_PHY_CONF0_ENTMDS_MASK);
> > }
> >
> > -static void dw_hdmi_phy_enable_spare(struct dw_hdmi *hdmi, u8 enable)
> > +static void dw_hdmi_phy_enable_svsret(struct dw_hdmi *hdmi, u8 enable)
> > {
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> > -HDMI_PHY_CONF0_SPARECTRL_OFFSET,
> > -HDMI_PHY_CONF0_SPARECTRL_MASK);
> > +HDMI_PHY_CONF0_SVSRET_OFFSET,
> > +HDMI_PHY_CONF0_SVSRET_MASK);
> > }
> >
> > static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> > @@ -1031,8 +1030,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> > dw_hdmi_phy_gen2_txpwron(hdmi, 1);
> > dw_hdmi_phy_gen2_pddq(hdmi, 0);
> >
> > - if (hdmi->dev_type == RK3288_HDMI)
> > - dw_hdmi_phy_enable_spare(hdmi, 1);
> > + if (pdata->quirks & DW_HDMI_QUIRK_PHY_SVSRET)
> > + dw_hdmi_phy_enable_svsret(hdmi, 1);
>
> If we get a proper split between the encoder and the PHY, this should be
> dealt with at the PHY side of the driver.
That's possible, and some other PHY-related setup code might be better placed
in the PHY side as well. My problem, as explained above, is that I don't have
enough information
[RFC 1/3] gpio-rz: Port to v3.18
Fix invalid return value in gpio remove function
Signed-off-by: Jacopo Mondi
---
drivers/gpio/gpio-rz.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-rz.c b/drivers/gpio/gpio-rz.c
index a933dab..cb8f785 100644
--- a/drivers/gpio/gpio-rz.c
+++ b/drivers/gpio/gpio-rz.c
@@ -175,7 +175,8 @@ static int rz_gpio_remove(struct platform_device *pdev)
{
struct rz_gpio_priv *p = platform_get_drvdata(pdev);
- return gpiochip_remove(&p->gpio_chip);
+ gpiochip_remove(&p->gpio_chip);
+ return 0;
}
static const struct of_device_id rz_gpio_dt_ids[] = {
--
2.7.4
Re: [PATCH v4 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
On Fri, Dec 2, 2016 at 3:25 PM, 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 it's 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 is being adopted for
> drivers for Renesas SoCs.
>
> Also:
> * Deprecate renesas,i2c-rcar. It seems poorly named as it is only
> compatible with R-Car Gen 1. It also appears unused in mainline.
> * Add some text to describe per-SoC bindings
>
> Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
> --- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> + "renesas,i2c-r8a7779" if the device is a part of a R8A7797 SoC.
R8A7779
Sorry for not noticing before.
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 v2 2/3 pci/next] PCI: rcar: Use gen2 fallback compatibility last
On Fri, Dec 2, 2016 at 11:36 AM, Simon Horman
wrote:
> Fallback compatibility strings should be used only if more specific ones
> are matched and the order of compatibility strings in the corresponding
> struct of_device_id should implement this.
>
> This does not have a run-time effect as current all relevant compatibility
> strings result in the same initialisation.
>
> Signed-off-by: Simon Horman
Reviewed-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
[PATCH v4 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
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 it's 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 is being adopted for
drivers for Renesas SoCs.
Also:
* Deprecate renesas,i2c-rcar. It seems poorly named as it is only
compatible with R-Car Gen 1. It also appears unused in mainline.
* Add some text to describe per-SoC bindings
Signed-off-by: Simon Horman
---
v4
* Correct grammar in changelog
v3
* Consistently use renesas,- for new compat strings
* Drop RFC designation
v2
* Include accidently omitted i2c-rcar.c portion of patch
---
Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 32 ++
drivers/i2c/busses/i2c-rcar.c | 5 +++-
2 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
index 239632a0d709..50c378ccb8e7 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
@@ -1,17 +1,25 @@
I2C for R-Car platforms
Required properties:
-- compatible: Must be one of
- "renesas,i2c-rcar"
- "renesas,i2c-r8a7778"
- "renesas,i2c-r8a7779"
- "renesas,i2c-r8a7790"
- "renesas,i2c-r8a7791"
- "renesas,i2c-r8a7792"
- "renesas,i2c-r8a7793"
- "renesas,i2c-r8a7794"
- "renesas,i2c-r8a7795"
- "renesas,i2c-r8a7796"
+- compatible:
+ "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
+ "renesas,i2c-r8a7779" if the device is a part of a R8A7797 SoC.
+ "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
+ "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
+ "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
+ "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
+ "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
+ "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
+ "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
+ "renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device.
+ "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 compatible device.
+ "renesas,rcar-gen3-i2c" for a generic R-Car Gen3 compatible device.
+ "renesas,i2c-rcar" (deprecated)
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first followed
+ by the generic version.
+
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt specifier.
@@ -33,7 +41,7 @@ Examples :
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7791";
+ compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 726615e54f2a..622def6b43e2 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -793,7 +793,6 @@ static const struct i2c_algorithm rcar_i2c_algo = {
};
static const struct of_device_id rcar_i2c_dt_ids[] = {
- { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7778", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7779", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7790", .data = (void *)I2C_RCAR_GEN2 },
@@ -803,6 +802,10 @@ static const struct of_device_id rcar_i2c_dt_ids[] = {
{ .compatible = "renesas,i2c-r8a7794", .data = (void *)I2C_RCAR_GEN2 },
{ .compatible = "renesas,i2c-r8a7795", .data = (void *)I2C_RCAR_GEN3 },
{ .compatible = "renesas,i2c-r8a7796", .data = (void *)I2C_RCAR_GEN3 },
+ { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
// Deprecated
+ { .compatible = "renesas,rcar-gen1-i2c", .data = (void *)I2C_RCAR_GEN1
},
+ { .compatible = "renesas,rcar-gen2-i2c", .data = (void *)I2C_RCAR_GEN2
},
+ { .compatible = "renesas,rcar-gen3-i2c", .data = (void *)I2C_RCAR_GEN3
},
{},
};
MODULE_DEVICE_TABLE(of, rcar_i2c_dt_ids);
--
2.7.0.rc3.207.g0ac5344
Re: [PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks
On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote:
> From: Kieran Bingham
>
> The dw-hdmi driver declares a dev_type to distinguish platform specific
> changes. Replace this with a quirk field, so that the platform can
> specify the required quirks for the driver, rather than the driver
> becoming conditional on multiple platforms.
>
> As part of this, we rename the dw-hdmi 'spare' which is defined as the
> SVSRET bit in later documentation.
I'd really prefer that we did not go down the broken route of adding
a set of "quirk" flags - look at what a mess SDHCI has become through
allowing that kind of practice.
I'd much rather we find a saner structure to this - and we know that
the hardware has ID registers in it which can be used (so far) to
identify the buggy hardware.
>
> Signed-off-by: Kieran Bingham
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c| 14 ++
> drivers/gpu/drm/bridge/dw-hdmi.h| 4 ++--
> drivers/gpu/drm/imx/dw_hdmi-imx.c | 3 +--
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
> include/drm/bridge/dw_hdmi.h| 12 +---
> 5 files changed, 15 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 06a44a2cdf3b..26607185722f 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -118,7 +118,6 @@ struct dw_hdmi {
> struct drm_bridge bridge;
>
> struct platform_device *audio;
> - enum dw_hdmi_devtype dev_type;
> struct device *dev;
> struct clk *isfr_clk;
> struct clk *iahb_clk;
> @@ -896,11 +895,11 @@ static void dw_hdmi_phy_enable_tmds(struct dw_hdmi
> *hdmi, u8 enable)
>HDMI_PHY_CONF0_ENTMDS_MASK);
> }
>
> -static void dw_hdmi_phy_enable_spare(struct dw_hdmi *hdmi, u8 enable)
> +static void dw_hdmi_phy_enable_svsret(struct dw_hdmi *hdmi, u8 enable)
> {
> hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> - HDMI_PHY_CONF0_SPARECTRL_OFFSET,
> - HDMI_PHY_CONF0_SPARECTRL_MASK);
> + HDMI_PHY_CONF0_SVSRET_OFFSET,
> + HDMI_PHY_CONF0_SVSRET_MASK);
> }
>
> static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> @@ -1031,8 +1030,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> dw_hdmi_phy_gen2_txpwron(hdmi, 1);
> dw_hdmi_phy_gen2_pddq(hdmi, 0);
>
> - if (hdmi->dev_type == RK3288_HDMI)
> - dw_hdmi_phy_enable_spare(hdmi, 1);
> + if (pdata->quirks & DW_HDMI_QUIRK_PHY_SVSRET)
> + dw_hdmi_phy_enable_svsret(hdmi, 1);
If we get a proper split between the encoder and the PHY, this should be
dealt with at the PHY side of the driver.
>
> /*Wait for PHY PLL lock */
> msec = 5;
> @@ -1348,7 +1347,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
> hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ, HDMI_MC_SWRSTZ);
>
> val = hdmi_readb(hdmi, HDMI_FC_INVIDCONF);
> - if (hdmi->dev_type == IMX6DL_HDMI) {
> + if (hdmi->plat_data->quirks & DW_HDMI_QUIRK_FC_INVIDCONF) {
> hdmi_writeb(hdmi, val, HDMI_FC_INVIDCONF);
> return;
> }
This is a bug found on iMX6DL versions of the IP - I don't have a 6DL
board powered up at the moment to grab its revision information, but
it would be nice to make that conditional on the revision. From what
I gather, it's a workaround issued by Synopsis rather than specific
to the (ex)FSL implementation.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Re: [PATCH 11/22] drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter
On Fri, Dec 02, 2016 at 01:43:26AM +0200, Laurent Pinchart wrote:
> From: Kieran Bingham
>
> The current code hard codes the call of hdmi_phy_configure() to be 8bpp
> and provides extraneous error checking to verify that this hardcoded
> value is correct.
>
> Simplify the passing of the data by setting the parameter to be of the
> enum type it represents rather than converting and then verifying the
> value. This will allow the compiler to check the value is acceptable
> based on the type, and remove the dead code that we currently have.
I think you're expecting too much of the compiler there. There's no
requirement for the compiler to check that an enum type is passed one
of it's defined values.
Try building this and see if it even produces a warning:
enum foo {
FOO_1,
FOO_2,
};
int func(enum foo foo)
{
return foo;
}
int test_1(void)
{
return func(FOO_1);
}
int test_2(void)
{
return func(5);
}
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Re: [PATCH 12/22] drm: bridge: dw-hdmi: Abstract the platform PHY configuration
Hi Jose,
On Friday 02 Dec 2016 11:15:19 Jose Abreu wrote:
> On 01-12-2016 23:43, Laurent Pinchart wrote:
> > From: Kieran Bingham
> >
> > Platforms implement the dw-hdmi with a separate PHY entity. It is
> > configured over it's own I2C bus. To allow for different PHY's to be
> > configured from the dw-hdmi driver, abstract the actual programming of
> > the PHY to its own functions, as configured by the platform.
> >
> > Signed-off-by: Kieran Bingham
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/bridge/dw-hdmi.c| 79 +++-
> > drivers/gpu/drm/imx/dw_hdmi-imx.c | 2 +
> > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 +
> > include/drm/bridge/dw_hdmi.h| 12 +
> > 4 files changed, 63 insertions(+), 31 deletions(-)
[snip]
> > diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> > index e551b457c100..fa7655836c81 100644
> > --- a/include/drm/bridge/dw_hdmi.h
> > +++ b/include/drm/bridge/dw_hdmi.h
> > @@ -52,6 +52,10 @@ struct dw_hdmi_plat_data {
> > const struct dw_hdmi_mpll_config *mpll_cfg;
> > const struct dw_hdmi_curr_ctrl *cur_ctr;
> > const struct dw_hdmi_phy_config *phy_config;
> > + int (*configure_phy)(struct dw_hdmi *hdmi,
> > +const struct dw_hdmi_plat_data *pdata,
> > +unsigned long mpixelclock,
> > +enum dw_hdmi_resolution resolution);
>
> I think the name of this callback here is a little bit misleading
> because you are only configuring the phy pll. Maybe
> .configure_phy_pll() would be more suitable.
Isn't there more than the PLL ? For instance register TXTERM configures the
transmission line termination.
> > enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
> >
> >struct drm_display_mode *mode);
> >
> > };
--
Regards,
Laurent Pinchart
Re: [PATCH 0/4] ARM, arm64: dts: Use usb-phy fallback bindings
On Thu, Dec 01, 2016 at 03:47:57PM +0100, Geert Uytterhoeven wrote: > On Thu, Dec 1, 2016 at 3:25 PM, Simon Horman > wrote: > > this short series makes use of fallback bindings for Renesas R-Car PHY > > drivers in the DT of SoCs which already use those drivers. > > > > Simon Horman (4): > > ARM: dts: r8a7790: Use renesas,rcar-gen2-usb-phy fallback binding > > ARM: dts: r8a7791: Use renesas,rcar-gen2-usb-phy fallback binding > > ARM: dts: r8a7794: Use renesas,rcar-gen2-usb-phy fallback binding > > arm64: dts: r8a7795: Use renesas,rcar-gen3-usb2-phy fallback binding > > Reviewed-by: Geert Uytterhoeven Thanks, I have queued these up for v4.11.
Re: [PATCH 06/12] usb: dwc3: omap: Replace the extcon API
Hi Felipe, 2016-12-02 18:03 GMT+09:00 Felipe Balbi : > > Hi, > > Chanwoo Choi writes: >> Hi Felipe, >> >> On 2016년 11월 30일 19:36, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Chanwoo Choi writes: This patch uses the resource-managed extcon API for extcon_register_notifier() and replaces the deprecated extcon API as following: - extcon_get_cable_state_() -> extcon_get_state() Signed-off-by: Chanwoo Choi >>> >>> Acked-by: Felipe Balbi >>> >> >> Thanks for your review. >> >> Each patch has no any dependency among patches. >> So, If possible, could you pick the patch6/8/9/10/11/12 on your tree? > > my tree is closed for v4.10, I can pick it up for v4.11 Thanks for your pickup to 4.11. -- Best Regards, Chanwoo Choi
Re: R-Car gen3 PLL0/2/4 frequencies incorrect?
Hi Sergei,
On Sun, Oct 30, 2016 at 7:36 PM, Sergei Shtylyov
wrote:
> drivers/clk/renesas/rcar-gen3-cpg.c seems to forget that the PLL0/2/4 all
> have a fixed divisor (2) while it multiplies PLLxCR.STC with 2 for the
> 'mult' variable (see the manual). All the dependent frequencies this should
> be reported greater x2 than the actual ones...
The actual frequencies in /sys/kernel/debug/clk/clk_summary are correct, though,
considering MD14=MD13=MD19=M17=1 (for a 33. MHz EXTAL), while
Salvator-X has a 16. MHz EXTAL.
Perhaps you missed the extal divider?
Note that I have measured MSIOF clock signal frequencies before, and they
matched Linux' point of view.
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 1/2] serial: sh-sci: Fix early deassertion of dedicated RTS
If a UART has dedicated RTS/CTS pins, there are some issues:
1. When changing hardware control flow, the new AUTORTS state is not
immediately reflected in the hardware, but only when RTS is raised.
However, the serial core doesn't call .set_mctrl() after
.set_termios(), hence AUTORTS may only become effective when the port
is closed, and reopened later.
Note that this problem does not happen when manually using stty to
change CRTSCTS, as AUTORTS will work fine on next open.
2. When hardware control flow is disabled (or AUTORTS is not yet
effective), changing any serial port configuration deasserts RTS, as
.set_termios() calls sci_init_pins().
To fix both issues, call .set_mctrl() from .set_termios() when dedicated
RTS/CTS pins are present, to refresh the AUTORTS or RTS state.
This is similar to what other drivers supporting AUTORTS do (e.g.
omap-serial).
Reported-by: Baumann, Christoph (C.) (issue 1)
Fixes: 33f50ffc253854cf ("serial: sh-sci: Fix support for hardware-assisted
RTS/CTS")
Signed-off-by: Geert Uytterhoeven
---
Tested on r8a7791/koelsch with HSCIF1 (GPIO hardware flow control),
and HSCIF2 and SCIFB0 (dedicated hardware flow control).
A simple test program (basically "cat" with CRTSCTS configuration
capability) can be found at https://github.com/geertu/sercat
Without this patch the following will fail:
1. sercat -f /dev/hscif2 &
seq 100 120 | sercat -f -w /dev/hscif1 # hangs
2. seq 200 220 | sercat -f -w /dev/hscif2 &
sercat -f /dev/hscif1 # no data received
---
drivers/tty/serial/sh-sci.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 91e7dddbf72cd3de..c503db1900f003ed 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2340,6 +2340,10 @@ static void sci_set_termios(struct uart_port *port,
struct ktermios *termios,
serial_port_out(port, SCFCR, ctrl);
}
+ if (port->flags & UPF_HARD_FLOW) {
+ /* Refresh (Auto) RTS */
+ sci_set_mctrl(port, port->mctrl);
+ }
scr_val |= s->cfg->scscr & ~(SCSCR_CKE1 | SCSCR_CKE0);
dev_dbg(port->dev, "SCSCR 0x%x\n", scr_val);
--
1.9.1
[PATCH 0/2] serial: sh-sci: Assorted flow control fixes
Hi Greg, Jiri,
This patch series fixes two issues related to hardware flow control on
Renesas SCIF UARTs.
Thanks!
Geert Uytterhoeven (2):
serial: sh-sci: Fix early deassertion of dedicated RTS
serial: sh-sci: Fix hang in sci_reset()
drivers/tty/serial/sh-sci.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
--
1.9.1
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 2/2] serial: sh-sci: Fix hang in sci_reset()
When the .set_termios() callback resets the UART, it first waits until
all characters in the transmit FIFO have been transmitted, to prevent a
port configuration change from impacting these characters.
However, if the previous user of the UART had dedicated RTS/CTS hardware
flow control enabled, these characters may have been stuck in the FIFO
due to CTS not being asserted. When the new user opens the port,
.set_termios() is called while transmission is still disabled, leading
to an infinite loop:
NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
This has been observed with SCIFA (on r8a7740/armadillo) and SCIFB (on
r8a7791/koelsch).
The issue does not seem to happen when using:
- GPIO RTS/CTS hardware flow control,
- No hardware flow control,
- HSCIF (on r8a7791/koelsch).
To fix this, wait for the draining of the transmit FIFO only if
transmission is already enabled.
Signed-off-by: Geert Uytterhoeven
---
To reproduce:
stty -echo < /dev/scifb0
stty crtscts < /dev/scifb0
echo hello > /dev/scifb0# returns early (wrote to FIFO)
echo hello > /dev/scifb0# hangs
drivers/tty/serial/sh-sci.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index c503db1900f003ed..db5de80c5399a7bd 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2137,9 +2137,11 @@ static void sci_reset(struct uart_port *port)
const struct plat_sci_reg *reg;
unsigned int status;
- do {
- status = serial_port_in(port, SCxSR);
- } while (!(status & SCxSR_TEND(port)));
+ if (serial_port_in(port, SCSCR) & SCSCR_TE) {
+ do {
+ status = serial_port_in(port, SCxSR);
+ } while (!(status & SCxSR_TEND(port)));
+ }
serial_port_out(port, SCSCR, 0x00); /* TE=0, RE=0, CKE1=0 */
--
1.9.1
Re: [PATCH v2] sh_eth: remove unchecked interrupts
Hi Chris,
On Thu, Dec 1, 2016 at 7:53 PM, Chris Brandt wrote:
> On 12/1/2016, Sergei Shtylyov wrote:
>>
>> On 12/01/2016 05:42 PM, Geert Uytterhoeven wrote:
>>
>> >> --- a/drivers/net/ethernet/renesas/sh_eth.c
>> >> +++ b/drivers/net/ethernet/renesas/sh_eth.c
>> >> @@ -518,7 +518,7 @@ static struct sh_eth_cpu_data r7s72100_data = {
>> >>
>> >> .ecsr_value = ECSR_ICD,
>> >> .ecsipr_value = ECSIPR_ICDIP,
>> >> - .eesipr_value = 0xff7f009f,
>> >> + .eesipr_value = 0xe77f009f,
>> >
>> > Comment not directly related to the merits of this patch: the EESIPR
>> > bit definitions seem to be identical to those for EESR, so we can get
>> > rid of the hardcoded values here?
>>
>> Do you mean using the @define's? We have EESIPR bits also declared,
>> see enum DMAC_IM_BIT,
Yes, that's what I meant.
Unfortunately the DMAC_IM_BIT enum doesn't cover all bits.
> Is your idea to get rid of .eesipr_value for devices that have values
> that are the same as .eesr_err_check?
>
>
> For example in sh_eth_dev_init():
>
> sh_eth_modify(ndev, EESR, 0, 0);
> mdp->irq_enabled = true;
> - sh_eth_write(ndev, mdp->cd->eesipr_value, EESIPR);
> + if (mdp->cd->eesipr_value)
> + sh_eth_write(ndev, mdp->cd->eesipr_value, EESIPR);
> + else
> + sh_eth_write(ndev, mdp->cd->eesr_err_check, EESIPR);
No, my intention was to just get rid of the hardcoded values when
initializing .eesipr_value.
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 v2 1/3 pci/next] PCI: rcar-gen2: Use gen2 fallback compatibility last
On Fri, Dec 2, 2016 at 11:36 AM, Simon Horman
wrote:
> Fallback compatibility strings should be used only if more specific ones
> are matched and the order of compatibility strings in the corresponding
> struct of_device_id should implement this.
>
> This does not have a run-time effect as current all relevant compatibility
> strings result in the same initialisation.
>
> Signed-off-by: Simon Horman
Reviewed-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 v2 3/3 pci/next] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar
On Fri, Dec 2, 2016 at 11:37 AM, Simon Horman
wrote:
> Add fallback compatibility string for the R-Car Gen 3 family. This is in
> keeping with the both the existing fallback compatibility string for the
> R-Car Gen 2 family and the fallback scheme being adopted wherever
> appropriate for drivers for Renesas SoCs.
>
> Signed-off-by: Simon Horman
Reviewed-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 12/22] drm: bridge: dw-hdmi: Abstract the platform PHY configuration
Hi Laurent,
On 01-12-2016 23:43, Laurent Pinchart wrote:
> From: Kieran Bingham
>
> Platforms implement the dw-hdmi with a separate PHY entity. It is
> configured over it's own I2C bus. To allow for different PHY's to be
> configured from the dw-hdmi driver, abstract the actual programming of
> the PHY to its own functions, as configured by the platform.
>
> Signed-off-by: Kieran Bingham
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c| 79
> ++---
> drivers/gpu/drm/imx/dw_hdmi-imx.c | 2 +
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 +
> include/drm/bridge/dw_hdmi.h| 12 +
> 4 files changed, 63 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 074ceb1e4897..06a44a2cdf3b 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -867,8 +867,8 @@ static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi,
> int msec)
> return true;
> }
>
> -static void hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
> - unsigned char addr)
> +void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
> +unsigned char addr)
> {
> hdmi_writeb(hdmi, 0xFF, HDMI_IH_I2CMPHY_STAT0);
> hdmi_writeb(hdmi, addr, HDMI_PHY_I2CM_ADDRESS_ADDR);
> @@ -880,6 +880,7 @@ static void hdmi_phy_i2c_write(struct dw_hdmi *hdmi,
> unsigned short data,
> HDMI_PHY_I2CM_OPERATION_ADDR);
> hdmi_phy_wait_i2c_done(hdmi, 1000);
> }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
>
> static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
> {
> @@ -930,38 +931,61 @@ static void dw_hdmi_phy_sel_interface_control(struct
> dw_hdmi *hdmi, u8 enable)
>HDMI_PHY_CONF0_SELDIPIF_MASK);
> }
>
> -static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> - enum dw_hdmi_resolution res_idx, int cscon)
> +int dw_hdmi_phy_configure_synopsys(struct dw_hdmi *hdmi,
> +const struct dw_hdmi_plat_data *pdata,
> +unsigned long mpixelclock,
> +enum dw_hdmi_resolution resolution)
> +
> {
> - u8 val, msec;
> - const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
> const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
> const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
> const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
>
> /* PLL/MPLL Cfg - always match on final entry */
> for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - mpll_config->mpixelclock)
> + if (mpixelclock <= mpll_config->mpixelclock)
> break;
>
> for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - curr_ctrl->mpixelclock)
> + if (mpixelclock <= curr_ctrl->mpixelclock)
> break;
>
> for (; phy_config->mpixelclock != ~0UL; phy_config++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - phy_config->mpixelclock)
> + if (mpixelclock <= phy_config->mpixelclock)
> break;
>
> if (mpll_config->mpixelclock == ~0UL ||
> curr_ctrl->mpixelclock == ~0UL ||
> - phy_config->mpixelclock == ~0UL) {
> - dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
> - hdmi->hdmi_data.video_mode.mpixelclock);
> + phy_config->mpixelclock == ~0UL)
> return -EINVAL;
> - }
> +
> + dw_hdmi_phy_i2c_write(hdmi, mpll_config->res[resolution].cpce, 0x06);
> + dw_hdmi_phy_i2c_write(hdmi, mpll_config->res[resolution].gmp, 0x15);
> +
> + /* CURRCTRL */
> + dw_hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[resolution], 0x10);
> +
> + dw_hdmi_phy_i2c_write(hdmi, 0x, 0x13); /* PLLPHBYCTRL */
> + dw_hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
> +
> + dw_hdmi_phy_i2c_write(hdmi, phy_config->term, 0x19); /* TXTERM */
> + dw_hdmi_phy_i2c_write(hdmi, phy_config->sym_ctr, 0x09); /* CKSYMTXCTRL
> */
> + dw_hdmi_phy_i2c_write(hdmi, phy_config->vlev_ctr, 0x0E); /* VLEVCTRL */
> +
> + /* REMOVE CLK TERM */
> + dw_hdmi_phy_i2c_write(hdmi, 0x8000, 0x05); /* CKCALCTRL */
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_configure_synopsys);
> +
> +static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> + enum dw_hdmi_resolution resolution, int cscon)
> +{
> + const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
> + unsigned long mpixelclock = hdmi->hdmi_data.video_mode.mpixelclock;
> + u8 val, msec;
> + i
Re: [PATCH 00/22] R-Car Gen3 HDMI output support
Hi Laurent, On 01-12-2016 23:43, Laurent Pinchart wrote: > Hello, > > This patch series implements support for the HDMI output on Renesas R-Car Gen3 > SoCs, and more specifically on the R-Car H3. > > R-Car Gen3 SoCs include one or multiple Synopsys DWC HDMI TX controllers. The > series thus starts with 13 cleanup or feature patches for the dw-hdmi driver. > Patches 01/22 to 05/22 are small miscellaneous cleanups. Patch 06/22 fixes a > crash when the HPD interrupt is generated before the bridge gets attached to a > DRM device. > > Patch 07/22 then starts refactoring the API towards platform glue by moving > common I/O and clock resource allocation to common code. Patches 08/22 and > 09/22 continue by moving connector creation to the bridge attach operation to > comply with the DRM bridge API. Patch 10/22 implements a new API for platform > glue to register the bridge with the DRM core, for platform that doesn't use > the component framework. Patches 11/22 to 13/22 finally abstract PHY setup to > allow platforms to implement configuration for custom PHYs. > > The next three patches add glue code for the DWC HDMI on Renesas R-Car Gen3 > platforms. Patch 14/22 rework the DWC HDMI DT bindings to make them more > modular, and patch 15/22 makes use of them to document the R-Car Gen DWC HDMI > TX DT bindings. Patch 16/22 then implements the platform glue code. > > The next three patches implement support for the R8A7795 HDMI outputs in the > R-Car DU driver. Patch 17/22 fixes a bug that makes the driver defer probe > forever if an encoder is disabled. Patch 18/22 implement DPLL support to > generate more precise clocks required by the HDMI controller, and patch 19/22 > then enables the two HDMI output on the R-Car H3 SoC. > > The last three patches enable the HDMI outputs on the H3 Salvator-X board by > adding the HDMI encoders to the R-Car H3 DT (20/22), adding HDMI connectors > and enabling the encoders (21/22) and adding the external dot clocks (22/22). > > The code has been tested on a Renesas Salvator-X H3 board, and modifications > to the dw-hdmi Freescale and Rockchip platform glues have been compile-tested. > > More improvements to the dw-hdmi driver would be beneficial. The PHY > modularization is based on the limited understanding of the HDMI PHYs used on > the three supported platforms and will possibly be enhanced later when adding > support for more platforms. The DT bindings would also benefit from a > standardized definition of the ports, and the reg-io-width property could > possibly be deprecated in favour of encoding the information in platform glue > code. The patch series is however big enough as is to be submitted for review > and merge before the dw-hdmi driver achieves perfection. > > Kieran Bingham (4): > drm: bridge: dw-hdmi: Remove unused function parameter > drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter > drm: bridge: dw-hdmi: Abstract the platform PHY configuration > drm: bridge: dw-hdmi: Replace device type with platform quirks > > Koji Matsuoka (4): > drm: rcar-du: Add Gen3 HDMI encoder support > drm: rcar-du: Add DPLL support > drm: rcar-du: Add HDMI outputs to R8A7795 device description > arm64: dts: r8a7795: salvator-x: Enable HDMI outputs > > Laurent Pinchart (13): > drm: bridge: dw-hdmi: Merge __hdmi_phy_i2c_write and > hdmi_phy_i2c_write > drm: bridge: dw-hdmi: Remove unneeded arguments to bind/unbind > functions > drm: bridge: dw-hdmi: Embed drm_bridge in struct dw_hdmi > drm: bridge: dw-hdmi: Remove encoder field from struct dw_hdmi > drm: bridge: dw-hdmi: Don't forward HPD events to DRM core before > attach > drm: bridge: dw-hdmi: Move IRQ and IO resource allocation to common > code > drm: bridge: dw-hdmi: Reorder functions to prepare for next commit > drm: bridge: dw-hdmi: Create connector in the bridge attach operation > drm: bridge: dw-hdmi: Implement DRM bridge registration > dt-bindings: display: dw-hdmi: Clean up DT bindings documentation > dt-bindings: display: renesas: Add R-Car Gen3 HDMI TX DT bindings > drm: rcar-du: Skip disabled outputs > arm64: dts: r8a7795: salvator-x: Add DU1 and DU2 external dot clocks > > Ulrich Hecht (1): > arm64: dts: r8a7795: Add HDMI encoder support > > .../devicetree/bindings/display/bridge/dw_hdmi.txt | 85 ++--- > .../bindings/display/bridge/renesas,dw-hdmi.txt| 75 + > .../devicetree/bindings/display/imx/hdmi.txt | 51 +-- > .../bindings/display/rockchip/dw_hdmi-rockchip.txt | 43 ++- > MAINTAINERS| 1 + > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 73 + > arch/arm64/boot/dts/renesas/r8a7795.dtsi | 50 +++ > drivers/gpu/drm/bridge/dw-hdmi.c | 364 > - > drivers/gpu/drm/bridge/dw-hdmi.h | 4 +- > drivers/gpu/drm/imx/dw_hdmi-imx.c | 19 +- > drivers/gpu/drm/rcar-du/Kconfig
[PATCH v2 1/3 pci/next] PCI: rcar-gen2: Use gen2 fallback compatibility last
Fallback compatibility strings should be used only if more specific ones
are matched and the order of compatibility strings in the corresponding
struct of_device_id should implement this.
This does not have a run-time effect as current all relevant compatibility
strings result in the same initialisation.
Signed-off-by: Simon Horman
---
v2
* New patch
Signed-off-by: Simon Horman
---
drivers/pci/host/pci-rcar-gen2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-rcar-gen2.c b/drivers/pci/host/pci-rcar-gen2.c
index 1eeefa4df64c..85348590848b 100644
--- a/drivers/pci/host/pci-rcar-gen2.c
+++ b/drivers/pci/host/pci-rcar-gen2.c
@@ -430,10 +430,10 @@ static int rcar_pci_probe(struct platform_device *pdev)
}
static struct of_device_id rcar_pci_of_match[] = {
- { .compatible = "renesas,pci-rcar-gen2", },
{ .compatible = "renesas,pci-r8a7790", },
{ .compatible = "renesas,pci-r8a7791", },
{ .compatible = "renesas,pci-r8a7794", },
+ { .compatible = "renesas,pci-rcar-gen2", },
{ },
};
--
2.7.0.rc3.207.g0ac5344
[PATCH v2 3/3 pci/next] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar
Add fallback compatibility string for the R-Car Gen 3 family. This is in
keeping with the both the existing fallback compatibility string for the
R-Car Gen 2 family and the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.
Signed-off-by: Simon Horman
---
v2
* Move fallback binding to below SoC specific bindings it covers
in implementation
---
Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
drivers/pci/host/pcie-rcar.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt
b/Documentation/devicetree/bindings/pci/rcar-pci.txt
index 6cf99690eef9..eee518db90b9 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -7,6 +7,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
"renesas,pcie-r8a7793" for the R8A7793 SoC;
"renesas,pcie-r8a7795" for the R8A7795 SoC;
"renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
+ "renesas,pcie-rcar-gen3" 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
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 85971bc276c6..72058bc7af5c 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -1078,6 +1078,8 @@ static const struct of_device_id rcar_pcie_of_match[] = {
{ .compatible = "renesas,pcie-rcar-gen2",
.data = rcar_pcie_hw_init_gen2 },
{ .compatible = "renesas,pcie-r8a7795", .data = rcar_pcie_hw_init },
+ { .compatible = "renesas,pcie-rcar-gen3",
+ .data = rcar_pcie_hw_init_hw_init },
{},
};
--
2.7.0.rc3.207.g0ac5344
[PATCH v2 0/3 pci/next] PCI: rcar, rcar-gen2: Bindings cleanups
Hi, this short series makes some bindings cleanups to the Renesas PCI drivers. Simon Horman (3): PCI: rcar-gen2: Use gen2 fallback compatibility last PCI: rcar: Use gen2 fallback compatibility last PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 + drivers/pci/host/pci-rcar-gen2.c | 2 +- drivers/pci/host/pcie-rcar.c | 6 -- 3 files changed, 6 insertions(+), 3 deletions(-) -- 2.7.0.rc3.207.g0ac5344
[PATCH v2 2/3 pci/next] PCI: rcar: Use gen2 fallback compatibility last
Fallback compatibility strings should be used only if more specific ones
are matched and the order of compatibility strings in the corresponding
struct of_device_id should implement this.
This does not have a run-time effect as current all relevant compatibility
strings result in the same initialisation.
Signed-off-by: Simon Horman
---
v2
* New patch
---
drivers/pci/host/pcie-rcar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 62700d1896f4..85971bc276c6 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -1071,12 +1071,12 @@ static int rcar_pcie_parse_map_dma_ranges(struct
rcar_pcie *pcie,
static const struct of_device_id rcar_pcie_of_match[] = {
{ .compatible = "renesas,pcie-r8a7779", .data = rcar_pcie_hw_init_h1 },
- { .compatible = "renesas,pcie-rcar-gen2",
- .data = rcar_pcie_hw_init_gen2 },
{ .compatible = "renesas,pcie-r8a7790",
.data = rcar_pcie_hw_init_gen2 },
{ .compatible = "renesas,pcie-r8a7791",
.data = rcar_pcie_hw_init_gen2 },
+ { .compatible = "renesas,pcie-rcar-gen2",
+ .data = rcar_pcie_hw_init_gen2 },
{ .compatible = "renesas,pcie-r8a7795", .data = rcar_pcie_hw_init },
{},
};
--
2.7.0.rc3.207.g0ac5344
Re: [patch] net: renesas: ravb: unintialized return value
On Thu, Dec 01, 2016 at 11:57:44PM +0300, Dan Carpenter wrote:
> We want to set the other "err" variable here so that we can return it
> later. My version of GCC misses this issue but I caught it with a
> static checker.
> Fixes: 9f70eb339f52 ("net: ethernet: renesas: ravb: fix fixed-link phydev
> leaks")
> Signed-off-by: Dan Carpenter
Thanks for catching this.
Reviewed-by: Johan Hovold
Johan
Re: [PATCH pci/next] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar
On Fri, Dec 02, 2016 at 10:19:21AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Thu, Dec 1, 2016 at 5:28 PM, Simon Horman
> wrote:
> > Add fallback compatibility string for the R-Car Gen 3 family. This is in
> > keeping with the both the existing fallback compatibility string for the
> > R-Car Gen 2 family and the fallback scheme being adopted wherever
> > appropriate for drivers for Renesas SoCs.
> >
> > Signed-off-by: Simon Horman
> > ---
> > Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
> > drivers/pci/host/pcie-rcar.c | 2 ++
> > 2 files changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> > b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> > index 6cf99690eef9..eee518db90b9 100644
> > --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> > @@ -7,6 +7,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
> > "renesas,pcie-r8a7793" for the R8A7793 SoC;
> > "renesas,pcie-r8a7795" for the R8A7795 SoC;
> > "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible
> > device.
> > + "renesas,pcie-rcar-gen3" 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
> > diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> > index 62700d1896f4..962aa3942107 100644
> > --- a/drivers/pci/host/pcie-rcar.c
> > +++ b/drivers/pci/host/pcie-rcar.c
> > @@ -1077,6 +1077,8 @@ static const struct of_device_id rcar_pcie_of_match[]
> > = {
> > .data = rcar_pcie_hw_init_gen2 },
> > { .compatible = "renesas,pcie-r8a7791",
> > .data = rcar_pcie_hw_init_gen2 },
> > + { .compatible = "renesas,pcie-rcar-gen3",
> > + .data = rcar_pcie_hw_init_hw_init },
>
> The family-specific handling should be inserted after the SoC-specific
> handling.
> Currently it doesn't matter, as both are handled exactly the same, but
> it may avoid future mistakes.
>
> BTW, can you please fix that for the existing entry for Gen2, too?
Sure, will do.
Re: [PATCH pci/next] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar
Hi Simon,
On Thu, Dec 1, 2016 at 5:28 PM, Simon Horman wrote:
> Add fallback compatibility string for the R-Car Gen 3 family. This is in
> keeping with the both the existing fallback compatibility string for the
> R-Car Gen 2 family and the fallback scheme being adopted wherever
> appropriate for drivers for Renesas SoCs.
>
> Signed-off-by: Simon Horman
> ---
> Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
> drivers/pci/host/pcie-rcar.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> index 6cf99690eef9..eee518db90b9 100644
> --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> @@ -7,6 +7,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
> "renesas,pcie-r8a7793" for the R8A7793 SoC;
> "renesas,pcie-r8a7795" for the R8A7795 SoC;
> "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible
> device.
> + "renesas,pcie-rcar-gen3" 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
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index 62700d1896f4..962aa3942107 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -1077,6 +1077,8 @@ static const struct of_device_id rcar_pcie_of_match[] =
> {
> .data = rcar_pcie_hw_init_gen2 },
> { .compatible = "renesas,pcie-r8a7791",
> .data = rcar_pcie_hw_init_gen2 },
> + { .compatible = "renesas,pcie-rcar-gen3",
> + .data = rcar_pcie_hw_init_hw_init },
The family-specific handling should be inserted after the SoC-specific
handling.
Currently it doesn't matter, as both are handled exactly the same, but
it may avoid future mistakes.
BTW, can you please fix that for the existing entry for Gen2, too?
Thanks!
> { .compatible = "renesas,pcie-r8a7795", .data = rcar_pcie_hw_init },
> {},
> };
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 06/12] usb: dwc3: omap: Replace the extcon API
Hi, Chanwoo Choi writes: > Hi Felipe, > > On 2016년 11월 30일 19:36, Felipe Balbi wrote: >> >> Hi, >> >> Chanwoo Choi writes: >>> This patch uses the resource-managed extcon API for >>> extcon_register_notifier() >>> and replaces the deprecated extcon API as following: >>> - extcon_get_cable_state_() -> extcon_get_state() >>> >>> Signed-off-by: Chanwoo Choi >> >> Acked-by: Felipe Balbi >> > > Thanks for your review. > > Each patch has no any dependency among patches. > So, If possible, could you pick the patch6/8/9/10/11/12 on your tree? my tree is closed for v4.10, I can pick it up for v4.11 -- balbi
Re: [PATCH v3 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
On Fri, Dec 2, 2016 at 9:10 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
it's
> 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
is being
> drivers for Renesas SoCs.
>
> Also:
> * Deprecate renesas,i2c-rcar. It seems poorly named as it is only
> compatible with R-Car Gen 1. It also appears unused in mainline.
> * Add some text to describe per-SoC bindings
>
> Signed-off-by: Simon Horman
Reviewed-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
[PATCH v3 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
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.
Also:
* Deprecate renesas,i2c-rcar. It seems poorly named as it is only
compatible with R-Car Gen 1. It also appears unused in mainline.
* Add some text to describe per-SoC bindings
Signed-off-by: Simon Horman
---
v3
* Consistently use renesas,- for new compat strings
* Drop RFC designation
v2
* Include accidently omitted i2c-rcar.c portion of patch
---
Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 32 ++
drivers/i2c/busses/i2c-rcar.c | 5 +++-
2 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
index 239632a0d709..50c378ccb8e7 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
@@ -1,17 +1,25 @@
I2C for R-Car platforms
Required properties:
-- compatible: Must be one of
- "renesas,i2c-rcar"
- "renesas,i2c-r8a7778"
- "renesas,i2c-r8a7779"
- "renesas,i2c-r8a7790"
- "renesas,i2c-r8a7791"
- "renesas,i2c-r8a7792"
- "renesas,i2c-r8a7793"
- "renesas,i2c-r8a7794"
- "renesas,i2c-r8a7795"
- "renesas,i2c-r8a7796"
+- compatible:
+ "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
+ "renesas,i2c-r8a7779" if the device is a part of a R8A7797 SoC.
+ "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
+ "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
+ "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
+ "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
+ "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
+ "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
+ "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
+ "renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device.
+ "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 compatible device.
+ "renesas,rcar-gen3-i2c" for a generic R-Car Gen3 compatible device.
+ "renesas,i2c-rcar" (deprecated)
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first followed
+ by the generic version.
+
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt specifier.
@@ -33,7 +41,7 @@ Examples :
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7791";
+ compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 726615e54f2a..622def6b43e2 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -793,7 +793,6 @@ static const struct i2c_algorithm rcar_i2c_algo = {
};
static const struct of_device_id rcar_i2c_dt_ids[] = {
- { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7778", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7779", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7790", .data = (void *)I2C_RCAR_GEN2 },
@@ -803,6 +802,10 @@ static const struct of_device_id rcar_i2c_dt_ids[] = {
{ .compatible = "renesas,i2c-r8a7794", .data = (void *)I2C_RCAR_GEN2 },
{ .compatible = "renesas,i2c-r8a7795", .data = (void *)I2C_RCAR_GEN3 },
{ .compatible = "renesas,i2c-r8a7796", .data = (void *)I2C_RCAR_GEN3 },
+ { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
// Deprecated
+ { .compatible = "renesas,rcar-gen1-i2c", .data = (void *)I2C_RCAR_GEN1
},
+ { .compatible = "renesas,rcar-gen2-i2c", .data = (void *)I2C_RCAR_GEN2
},
+ { .compatible = "renesas,rcar-gen3-i2c", .data = (void *)I2C_RCAR_GEN3
},
{},
};
MODULE_DEVICE_TABLE(of, rcar_i2c_dt_ids);
--
2.7.0.rc3.207.g0ac5344
