* [PATCH BUGFIX] mtd: nand: mxc: fix obiwan error in mxc_nand_v[12]_ooblayout_free() functions
From: Boris Brezillon @ 2016-09-19 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916100925.1a4d1af7@ipc1.ka-ro>
On Fri, 16 Sep 2016 10:09:25 +0200
Lothar Wa?mann <LW@KARO-electronics.de> wrote:
> Hi,
>
> On Thu, 15 Sep 2016 18:06:05 +0200 Boris Brezillon wrote:
> > Hi Lothar,
> >
> > On Fri, 9 Sep 2016 16:44:11 +0200
> > Lothar Wa?mann <LW@KARO-electronics.de> wrote:
> >
> > > commit a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
> > > introduced a regression accessing the OOB area from the mxc_nand
> > > driver due to an Obiwan error in the mxc_nand_v[12]_ooblayout_free()
> > > functions. They report a bogus oobregion { 64, 7 } which leads to
> > > errors accessing bogus data when reading the oob area.
> > >
> > > Prior to the commit the mtd-oobtest module could be run without any
> > > errors. With the offending commit, this test fails with results like:
> > > |Running mtd-oobtest
> > > |
> > > |=================================================
> > > |mtd_oobtest: MTD device: 5
> > > |mtd_oobtest: MTD device size 524288, eraseblock size 131072, page size 2048, count of eraseblocks 4, pages per eraseblock 64, OOB size 64
> > > |mtd_test: scanning for bad eraseblocks
> > > |mtd_test: scanned 4 eraseblocks, 0 are bad
> > > |mtd_oobtest: test 1 of 5
> > > |mtd_oobtest: writing OOBs of whole device
> > > |mtd_oobtest: written up to eraseblock 0
> > > |mtd_oobtest: written 4 eraseblocks
> > > |mtd_oobtest: verifying all eraseblocks
> > > |mtd_oobtest: error @addr[0x0:0x19] 0x9a -> 0x78 diff 0xe2
> > > |mtd_oobtest: error @addr[0x0:0x1a] 0xcc -> 0x0 diff 0xcc
> > > |mtd_oobtest: error @addr[0x0:0x1b] 0xe0 -> 0x85 diff 0x65
> > > |mtd_oobtest: error @addr[0x0:0x1c] 0x60 -> 0x62 diff 0x2
> > > |mtd_oobtest: error @addr[0x0:0x1d] 0x69 -> 0x45 diff 0x2c
> > > |mtd_oobtest: error @addr[0x0:0x1e] 0xcd -> 0xa0 diff 0x6d
> > > |mtd_oobtest: error @addr[0x0:0x1f] 0xf2 -> 0x60 diff 0x92
> > > |mtd_oobtest: error: verify failed at 0x0
> > > [...]
> > >
> > > Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
> > > ---
> > > drivers/mtd/nand/mxc_nand.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> > > index 5173fad..fdee907 100644
> > > --- a/drivers/mtd/nand/mxc_nand.c
> > > +++ b/drivers/mtd/nand/mxc_nand.c
> > > @@ -893,7 +893,7 @@ static int mxc_v1_ooblayout_free(struct mtd_info *mtd, int section,
> > > {
> > > struct nand_chip *nand_chip = mtd_to_nand(mtd);
> > >
> > > - if (section > nand_chip->ecc.steps)
> > > + if (section >= nand_chip->ecc.steps)
> > > return -ERANGE;
> >
> > Hm, looking at the commit you're pointing to, it seems that this test
> > is correct (we have X + 1 free sections, where X is the number of ECC
> > steps).
> >
> You are right. I didn't verify the v1 case (for which I have no HW here
> any more).
> I'll send a corrected patch.
No need to resend, I fixed it locally.
Thanks,
Boris
^ permalink raw reply
* [PATCH 2/2] drm/virtio: kconfig: Fixup white space.
From: Peter Griffin @ 2016-09-19 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474277660-5196-1-git-send-email-peter.griffin@linaro.org>
Use tabs instead of spaces.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
drivers/gpu/drm/virtio/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index 90357d9..2d83932 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -2,10 +2,10 @@ config DRM_VIRTIO_GPU
tristate "Virtio GPU driver"
depends on DRM
select VIRTIO
- select DRM_KMS_HELPER
- select DRM_TTM
+ select DRM_KMS_HELPER
+ select DRM_TTM
help
This is the virtual GPU driver for virtio. It can be used with
- QEMU based VMMs (like KVM or Xen).
+ QEMU based VMMs (like KVM or Xen).
If unsure say M.
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] drm/virtio: kconfig: Fix recursive dependency issue.
From: Peter Griffin @ 2016-09-19 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474277660-5196-1-git-send-email-peter.griffin@linaro.org>
ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
recursive dependency.
[..]
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:42: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:36: symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/virtio/Kconfig:1: symbol DRM_VIRTIO_GPU depends on VIRTIO
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/virtio/Kconfig:1: symbol VIRTIO is selected by REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:4: symbol REMOTEPROC is selected by ST_SLIM_REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:103: symbol ST_SLIM_REMOTEPROC is selected by ST_FDMA
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:440: symbol ST_FDMA depends on DMADEVICES
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:5: symbol DMADEVICES is selected by SND_SOC_SH4_SIU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:29: symbol SND_SOC_SH4_SIU is selected by SND_SIU_MIGOR
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:64: symbol SND_SIU_MIGOR depends on I2C
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:63: symbol FB_DDC is selected by FB_CYBER2000_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:378: symbol FB_CYBER2000_DDC depends on FB_CYBER2000
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:366: symbol FB_CYBER2000 depends on FB
which is due to drivers/gpu/drm/virtio/Kconfig depending on VIRTIO.
Fix by dropping depend and switching to select VIRTIO.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
drivers/gpu/drm/virtio/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index e1afc3d..90357d9 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -1,6 +1,7 @@
config DRM_VIRTIO_GPU
tristate "Virtio GPU driver"
- depends on DRM && VIRTIO
+ depends on DRM
+ select VIRTIO
select DRM_KMS_HELPER
select DRM_TTM
help
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] Fix recursive Kconfig depedency issue
From: Peter Griffin @ 2016-09-19 9:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series fixes a Kconfig recurssive depedency issue and also some
trivial white space. This was found when developing the fdma dmaegine
series [1], which has now been applied by Vinod.
These patchs were originally included as part of the fdma series [1],
but I've now sent it separately as requested by Vinod [2], and also
privately by Emil.
FYI not having this patch applied causes kbuild error emails [3].
[1] https://lkml.org/lkml/2016/9/13/191
[2] https://lkml.org/lkml/2016/9/15/562
[3] https://lkml.org/lkml/2016/9/15/850
Peter Griffin (2):
drm/virtio: kconfig: Fix recursive dependency issue.
drm/virtio: kconfig: Fixup white space.
drivers/gpu/drm/virtio/Kconfig | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--
1.9.1
^ permalink raw reply
* [RFC PATCH v2 10/11] irqchip: mbigen: Add ACPI support
From: Hanjun Guo @ 2016-09-19 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DA6097.8060105@arm.com>
Hi Marc,
On 2016/9/15 16:49, Marc Zyngier wrote:
> On 14/09/16 15:21, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> With the preparation of platform msi support and interrupt producer
>> in DSDT, we can add mbigen ACPI support now.
>>
>> We are using _PRS methd to indicate number of irq pins instead
>> of num_pins in DT.
>>
>> For mbi-gen,
>> Device(MBI0) {
>> Name(_HID, "HISI0152")
>> Name(_UID, Zero)
>> Name(_CRS, ResourceTemplate() {
>> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
>> })
>>
>> Name (_PRS, ResourceTemplate() {
>> Interrupt(ResourceProducer,...) {12,14,....}
>> })
>
> Since I know next to nothing about all of this, I'm going to play the
> village idiot. What makes it legal to use _PRS as a way to describe the
> interrupts that are exposed by MBI0? Looking at the 6.0 spec, I do not
> see why the interrupts would be put there instead of _CRS, and why you'd
> have a _PRS at all.
_PRS describes possible resource settings for the device, which returns
a list of a device's possible resource settings such as memory range,
interrupt descriptors, and the format of the data in a _PRS object
follows the same format as _CRS object (ACPI 6.1, section 6.2.12),
so Interrupts can be put in the _PRS.
And in ACPI 6.1, section 6.2, it describes the _PRS usage:
"Some resources, however, may be shared amongst several devices. To
describe this, devices that share a resource (resource consumers) must
use the extended resource descriptors (0x7-0xA) described in Section
6.4.3, ?Large Resource Data Type.? These descriptors point to a single
device object (resource producer) that claims the shared resource in
its _PRS."
As mbigen is a interrupt producer which provide interrupt resoures
for devices, which matches the usage of _PRS in the spec.
>
> Also, are you going to exhaustively describe all the possible interrupts
> via this method? Knowing that the mbigen can expose thousands of
> interrupts, I find it slightly mad. Can't you express a range?
Yes, a little bit mad. I can't express a interrupt range in ACPI at
least in current version of spec. But that just adding more lines
of ACPI DSDT code, it's fine to me. or we need to use _DSD to present
similar property "num_pins" in ACPI which I avoid using.
Thanks
Hanjun
^ permalink raw reply
* [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization
From: Boris Brezillon @ 2016-09-19 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474274696-28090-1-git-send-email-andy.yan@rock-chips.com>
On Mon, 19 Sep 2016 16:44:56 +0800
Andy Yan <andy.yan@rock-chips.com> wrote:
> The current rk3066a based boards(Rayeager, Bqcurie2, Marsboard) use
> pwm modulate vdd_logic voltage, but the pwm is default disabled and
> the pwm pin acts as a gpio before pwm regulator probed, so the pwm
> regulator driver will get a zero dutycycle at probe time, so change
> the initial dutycycle to zero to match pwm_regulator_init_state check.
>
> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
>
> ---
>
> arch/arm/boot/dts/rk3066a-bqcurie2.dts | 2 +-
> arch/arm/boot/dts/rk3066a-marsboard.dts | 2 +-
> arch/arm/boot/dts/rk3066a-rayeager.dts | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
> index bc674ee..618450d 100644
> --- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
> +++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
> @@ -61,7 +61,7 @@
> regulator-min-microvolt = <1200000>;
> regulator-max-microvolt = <1200000>;
> regulator-always-on;
> - voltage-table = <1000000 100>,
> + voltage-table = <1000000 0>,
> <1200000 42>;
So, it seems you are reversing the PWM polarity here. Are you sure you
shouldn't change the 2nd entry of this table (<1200000 58>)?
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/rk3066a-marsboard.dts b/arch/arm/boot/dts/rk3066a-marsboard.dts
> index a2b763e..ddc680b 100644
> --- a/arch/arm/boot/dts/rk3066a-marsboard.dts
> +++ b/arch/arm/boot/dts/rk3066a-marsboard.dts
> @@ -59,7 +59,7 @@
> regulator-min-microvolt = <1200000>;
> regulator-max-microvolt = <1200000>;
> regulator-always-on;
> - voltage-table = <1000000 100>,
> + voltage-table = <1000000 0>,
> <1200000 42>;
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/rk3066a-rayeager.dts b/arch/arm/boot/dts/rk3066a-rayeager.dts
> index 2536b3a..30aee99 100644
> --- a/arch/arm/boot/dts/rk3066a-rayeager.dts
> +++ b/arch/arm/boot/dts/rk3066a-rayeager.dts
> @@ -84,7 +84,7 @@
> regulator-min-microvolt = <1200000>;
> regulator-max-microvolt = <1200000>;
> regulator-always-on;
> - voltage-table = <1000000 100>,
> + voltage-table = <1000000 0>,
> <1200000 42>;
> status = "okay";
> };
^ permalink raw reply
* [PATCH v3 1/4] drm/bridge: Add RGB to VGA bridge support
From: Maxime Ripard @ 2016-09-19 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1682784.hDdFQltm22@avalon>
On Sun, Sep 18, 2016 at 01:04:17PM +0300, Laurent Pinchart wrote:
> On Sunday 18 Sep 2016 13:01:16 Laurent Pinchart wrote:
> > On Thursday 08 Sep 2016 14:17:48 Maxime Ripard wrote:
> > > Some boards have an entirely passive RGB to VGA bridge, based on either
> > > DACs or resistor ladders.
> > >
> > > Those might or might not have an i2c bus routed to the VGA connector in
> > > order to access the screen EDIDs.
> > >
> > > Add a bridge that doesn't do anything but expose the modes available on
> > > the screen, either based on the EDIDs if available, or based on the XGA
> > > standards.
> > >
> > > Acked-by: Rob Herring <robh@kernel.org>
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > > ---
> > >
> > > .../bindings/display/bridge/rgb-to-vga-bridge.txt | 52 +++++
> > > drivers/gpu/drm/bridge/Kconfig | 6 +
> > > drivers/gpu/drm/bridge/Makefile | 1 +
> > > drivers/gpu/drm/bridge/rgb-to-vga.c | 232 ++++++++++++++++
> > > 4 files changed, 291 insertions(+)
> > > create mode 100644
> > >
> > > Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> > > create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> > > b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> > > new file mode 100644
> > > index 000000000000..83a053fb51a0
> > > --- /dev/null
> > > +++
> > > b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> > > @@ -0,0 +1,52 @@
> > > +Passive RGB to VGA bridge
> > > +-------------------------
> > > +
> > > +This binding is aimed for entirely passive RGB to VGA bridges that do not
> > > +require any configuration.
> >
> > Couldn't it also support active RGB to VGA bridges that don't require any
> > configuration ? It would seem a bit pointless to define a separate DT
> > binding for them.
>
> I'm thinking in particular about the ADV7123
> (http://www.analog.com/media/en/technical-documentation/data-sheets/ADV7123.pdf)
> that already has a DT binding.
I guess we don't have the same definition of passive, but I was
thinking of devices that do not need any configuration in order to
operate properly. And this one seems to fall in that category.
> Would it be feasible to combine the two, and support both devices
> with a single driver ?
I don't see why not. But converting the renesas DRM driver seems a bit
out of scope, and the ADV compatible can definitely be added later.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/22fa2cec/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: mvebu: let Armada XP also select corediv clk
From: Uwe Kleine-König @ 2016-09-19 9:22 UTC (permalink / raw)
To: linux-arm-kernel
An Armada XP there is also a marvell,armada-370-corediv-clock
compatible device that is needed to make the nand device work.
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/mach-mvebu/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index f9b6bd306cfe..2979a9c454f6 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -97,6 +97,7 @@ config MACH_ARMADA_XP
select CPU_PJ4B
select MACH_MVEBU_V7
select PINCTRL_ARMADA_XP
+ select MVEBU_CLK_COREDIV
help
Say 'Y' here if you want your kernel to support boards based
on the Marvell Armada XP SoC with device tree.
--
2.8.1
^ permalink raw reply related
* [PATCH 0/1] fix rk3066a based boards boot issue on linux-4.8
From: Boris Brezillon @ 2016-09-19 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474274639-27768-1-git-send-email-andy.yan@rock-chips.com>
Hi Andy,
On Mon, 19 Sep 2016 16:43:59 +0800
Andy Yan <andy.yan@rock-chips.com> wrote:
> Hi, heiko:
> I found my Rayeager board couldn't boot up on linux 4.8. After some
> dig, I found the pwm-regulator for vdd_log register failed and found
> some change in Boris's patch: commit 87248991a1de(regulator: pwm: Properly
> initialize the ->state field).
Hm, that's weird. This commit only makes sure that the regulator
voltage state is correctly initialized (matching the hardware state),
and I don't understand why changing the voltage-table make it work.
Can you share the kernel logs? What are the symptoms?
Thanks,
Boris
> I send this patch to make the pwm-regulator can register success on
> this change.
>
>
> Andy Yan (1):
> arm: dts: fix rk3066a based boards vdd_log voltage initialization
>
> arch/arm/boot/dts/rk3066a-bqcurie2.dts | 2 +-
> arch/arm/boot/dts/rk3066a-marsboard.dts | 2 +-
> arch/arm/boot/dts/rk3066a-rayeager.dts | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
^ permalink raw reply
* [PATCH] mtd: s3c2410: add device tree support
From: Mark Rutland @ 2016-09-19 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474125760-28168-1-git-send-email-sergio.prado@e-labworks.com>
On Sat, Sep 17, 2016 at 12:22:40PM -0300, Sergio Prado wrote:
> Tested on FriendlyARM Mini2440
>
> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> ---
> .../devicetree/bindings/mtd/samsung-s3c2410.txt | 70 +++++++++++
> drivers/mtd/nand/s3c2410.c | 129 ++++++++++++++++++++-
> include/linux/platform_data/mtd-nand-s3c2410.h | 1 +
> 3 files changed, 195 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
> new file mode 100644
> index 000000000000..1c39f6cf483b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
> @@ -0,0 +1,70 @@
> +* Samsung S3C2410 and compatible NAND flash controller
> +
> +Required properties:
> +- compatible : The possible values are:
> + "samsung,s3c2410-nand"
> + "samsung,s3c2412-nand"
> + "samsung,s3c2440-nand"
> + "samsung,s3c6400-nand"
> +- reg : register's location and length.
> +- #address-cells, #size-cells : see nand.txt
> +- clocks : phandle to the nand controller clock
> +- clock-names : must contain "nand"
Is there only one clock feeding into the NAND block? Is it actually
called "nand", or does the datasheet not give the input a nme?
> +
> +Optional properties:
> +- samsung,tacls : time for active CLE/ALE to nWE/nOE
> +- samsung,twrph0 : active time for nWE/nOE
> +- samsung,twrph1 : time for release CLE/ALE from nWE/nOE inactive
If these are necessary, what units are these in?
> +- samsung,ignore_unset_ecc : boolean to ignore error when we have
> + 0xff,0xff,0xff read ECC, on the
> + assumption that it is an un-eccd page
s/_/-/ in property names, please.
That said, this name reads like policy rather than a HW description.
Why/when is this necessary to set?
[...]
> + of_property_read_u32(np, "samsung,tacls", &pdata->tacls);
> + of_property_read_u32(np, "samsung,twrph0", &pdata->twrph0);
> + of_property_read_u32(np, "samsung,twrph1", &pdata->twrph1);
Are all values in the range [0, 0xffffffff] valid for these? If not, it
would be a good idea to sanity-check the values.
> + if (of_get_property(np, "samsung,ignore_unset_ecc", NULL))
> + pdata->ignore_unset_ecc = 1;
Use of_property_read_bool();
[...]
> + for_each_available_child_of_node(np, child) {
> +
> + sets->name = (char *)child->name;
> + sets->of_node = child;
Strictly speaking, you should increment the child node refcount here, as
you maintain a reference to it and its name field.
> + sets->nr_chips = 1;
> +
> + if (!of_property_match_string(child, "nand-ecc-mode", "none"))
> + sets->disable_ecc = 1;
> +
> + if (of_get_property(child, "nand-on-flash-bbt", NULL))
> + sets->flash_bbt = 1;
Use of_property_read_bool().
Thanks,
Mark.
^ permalink raw reply
* [PATCH 2/2] clk: imx6: initialize GPU clocks
From: Lucas Stach @ 2016-09-19 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160918001723.GC15478@tiger>
Am Sonntag, den 18.09.2016, 08:17 +0800 schrieb Shawn Guo:
> On Fri, Sep 16, 2016 at 11:16:11AM +0200, Lucas Stach wrote:
> > Initialize the GPU clock muxes to sane inputs. Until now they have
> > not been changed from their default values, which means that both
> > GPU3D shader and GPU2D core were fed by clock inputs whose rates
> > exceed the maximium allowed frequency of the cores by as much as
> > 200MHz.
> >
> > This fixes a severe GPU stability issue on i.MX6DL.
> >
> > Cc: stable at vger.kernel.org
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > ---
> > drivers/clk/imx/clk-imx6q.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
> > index 64c243173395..751c3e7d5843 100644
> > --- a/drivers/clk/imx/clk-imx6q.c
> > +++ b/drivers/clk/imx/clk-imx6q.c
> > @@ -633,6 +633,24 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> > if (IS_ENABLED(CONFIG_PCI_IMX6))
> > clk_set_parent(clk[IMX6QDL_CLK_LVDS1_SEL], clk[IMX6QDL_CLK_SATA_REF_100M]);
> >
> > + /*
> > + * Initialize the GPU clock muxes, so that the maximum specified clock
> > + * rates for the respective SoC are not exceeded.
> > + */
> > + if (clk_on_imx6dl()) {
> > + clk_set_parent(clk[IMX6QDL_CLK_GPU3D_CORE_SEL],
> > + clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
> > + clk_set_parent(clk[IMX6QDL_CLK_GPU2D_CORE_SEL],
> > + clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
> > + } else if (clk_on_imx6q()) {
> > + clk_set_parent(clk[IMX6QDL_CLK_GPU3D_CORE_SEL],
> > + clk[IMX6QDL_CLK_MMDC_CH0_AXI]);
> > + clk_set_parent(clk[IMX6QDL_CLK_GPU3D_SHADER_SEL],
> > + clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
> > + clk_set_parent(clk[IMX6QDL_CLK_GPU2D_CORE_SEL],
> > + clk[IMX6QDL_CLK_PLL3_USB_OTG]);
> > + }
> > +
>
> Can we handle these with assigned-clock-parents from device tree?
>
No, we want to get rid of the GPU overclocking even with old DTs. DT
stability rules and all that...
Regards,
Lucas
^ permalink raw reply
* [PATCH] spi: dw: use relaxed IO accessor
From: Jisheng Zhang @ 2016-09-19 9:00 UTC (permalink / raw)
To: linux-arm-kernel
Using the __raw functions is discouraged. Update the driver to use the
relaxed functions.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
drivers/spi/spi-dw.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-dw.h b/drivers/spi/spi-dw.h
index 61bc3cb..2cfdc4d 100644
--- a/drivers/spi/spi-dw.h
+++ b/drivers/spi/spi-dw.h
@@ -143,22 +143,22 @@ struct dw_spi {
static inline u32 dw_readl(struct dw_spi *dws, u32 offset)
{
- return __raw_readl(dws->regs + offset);
+ return readl_relaxed(dws->regs + offset);
}
static inline u16 dw_readw(struct dw_spi *dws, u32 offset)
{
- return __raw_readw(dws->regs + offset);
+ return readw_relaxed(dws->regs + offset);
}
static inline void dw_writel(struct dw_spi *dws, u32 offset, u32 val)
{
- __raw_writel(val, dws->regs + offset);
+ writel_relaxed(val, dws->regs + offset);
}
static inline void dw_writew(struct dw_spi *dws, u32 offset, u16 val)
{
- __raw_writew(val, dws->regs + offset);
+ writew_relaxed(val, dws->regs + offset);
}
static inline u32 dw_read_io_reg(struct dw_spi *dws, u32 offset)
--
2.9.3
^ permalink raw reply related
* [PATCH V6 6/6] ARM64: bcm2835: add thermal driver to default_config
From: kernel at martin.sperl.org @ 2016-09-19 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474275600-19378-1-git-send-email-kernel@martin.sperl.org>
From: Martin Sperl <kernel@martin.sperl.org>
Add the thermal driver for bcm2837 to list of compiled modules
in the default config.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index eadf485..372f981 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -252,6 +252,7 @@ CONFIG_SENSORS_INA2XX=m
CONFIG_SENSORS_ARM_SCPI=y
CONFIG_THERMAL=y
CONFIG_THERMAL_EMULATION=y
+CONFIG_BCM2835_THERMAL=y
CONFIG_EXYNOS_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_RENESAS_WDT=y
--
2.1.4
^ permalink raw reply related
* [PATCH V6 5/6] ARM: bcm2835: add thermal driver to default_config
From: kernel at martin.sperl.org @ 2016-09-19 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474275600-19378-1-git-send-email-kernel@martin.sperl.org>
From: Martin Sperl <kernel@martin.sperl.org>
Add the thermal driver to list of compiled modules
in the default config for bcm2835.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
---
arch/arm/configs/bcm2835_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 79de828..4b89f4e 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -73,6 +73,8 @@ CONFIG_SPI_BCM2835=y
CONFIG_SPI_BCM2835AUX=y
CONFIG_GPIO_SYSFS=y
# CONFIG_HWMON is not set
+CONFIG_THERMAL=y
+CONFIG_BCM2835_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_BCM2835_WDT=y
CONFIG_DRM=y
--
2.1.4
^ permalink raw reply related
* [PATCH V6 4/6] ARM64: bcm2835: dts: add thermal node to device-tree of bcm2837
From: kernel at martin.sperl.org @ 2016-09-19 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474275600-19378-1-git-send-email-kernel@martin.sperl.org>
From: Martin Sperl <kernel@martin.sperl.org>
Add the node for the thermal sensor of the bcm2837-soc
to the device tree.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
---
arch/arm64/boot/dts/broadcom/bcm2837.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
Note: untested as I have no 64 bit test system.
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
index f2a31d0..2b0cfc7 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
@@ -74,3 +74,9 @@
interrupt-parent = <&local_intc>;
interrupts = <8>;
};
+
+/* enable thermal sensor with the correct compatible property set */
+&thermal {
+ compatible = "brcm,bcm2837-thermal";
+ status = "okay";
+};
--
2.1.4
^ permalink raw reply related
* [PATCH V6 3/6] ARM: bcm2835: dts: add thermal node to device-tree of bcm283x
From: kernel at martin.sperl.org @ 2016-09-19 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474275600-19378-1-git-send-email-kernel@martin.sperl.org>
From: Martin Sperl <kernel@martin.sperl.org>
Add the node for the thermal sensor of the bcm2835-soc
to the device tree.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
Changelog:
V1 -> V5: generic settings is shared in bcm283x.dtsi, but disabled
moved the compatible string to the SOC specific dtsi
for arm and arm64
V5 -> V6: removed 0x in node name
---
arch/arm/boot/dts/bcm2835.dtsi | 6 ++++++
arch/arm/boot/dts/bcm2836.dtsi | 6 ++++++
arch/arm/boot/dts/bcm283x.dtsi | 7 +++++++
3 files changed, 19 insertions(+)
Note: there is no arm/boot/dts/bcm2837.dtsi as of now,
so the 32-bit rpi3 dt is not modified.
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index a78759e..0890d97 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -23,3 +23,9 @@
};
};
};
+
+/* enable thermal sensor with the correct compatible property set */
+&thermal {
+ compatible = "brcm,bcm2835-thermal";
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm2836.dtsi b/arch/arm/boot/dts/bcm2836.dtsi
index 9d0651d..519a44f 100644
--- a/arch/arm/boot/dts/bcm2836.dtsi
+++ b/arch/arm/boot/dts/bcm2836.dtsi
@@ -76,3 +76,9 @@
interrupt-parent = <&local_intc>;
interrupts = <8>;
};
+
+/* enable thermal sensor with the correct compatible property set */
+&thermal {
+ compatible = "brcm,bcm2836-thermal";
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index b982522..d9acf21 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -186,6 +186,13 @@
interrupts = <2 14>; /* pwa1 */
};
+ thermal: thermal at 7e212000 {
+ compatible = "brcm,bcm2835-thermal";
+ reg = <0x7e212000 0x8>;
+ clocks = <&clocks BCM2835_CLOCK_TSENS>;
+ status = "disabled";
+ };
+
aux: aux at 0x7e215000 {
compatible = "brcm,bcm2835-aux";
#clock-cells = <1>;
--
2.1.4
^ permalink raw reply related
* [PATCH V6 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: kernel at martin.sperl.org @ 2016-09-19 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474275600-19378-1-git-send-email-kernel@martin.sperl.org>
From: Martin Sperl <kernel@martin.sperl.org>
Add basic thermal driver for bcm2835 SOC.
This driver currently relies on the firmware setting up the
tsense HW block and does not set it up itself.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Acked-by: Eric Anholt <eric@anholt.net>
ChangeLog:
V1 -> V2: added specific settings depending on compatiblity
added trip point based on register
setting up ctrl-register if HW is not enabled by firmware
as per recommendation of Eric (untested)
check that clock frequency is in range
(1.9 - 5MHz - as per comment in clk-bcm2835.c)
V2 -> V4: moved back to thermal (not using bcm sub-directory)
set polling interval to 1second (was 0ms, so interrupt driven)
V5 -> V6: added correct depends in KConfig
removed defined default for RESET_DELAY
removed obvious comments
clarify HW setup comments if not set up by FW already
move clk_prepare_enable to an earlier stage and add error handling
clarify warning when TS-clock runs out of recommended range
clk_disable_unprepare added in bcm2835_thermal_remove
added comment on recommended temperature ranges for SOC
---
drivers/thermal/Kconfig | 8 +
drivers/thermal/Makefile | 1 +
drivers/thermal/bcm2835_thermal.c | 340 ++++++++++++++++++++++++++++++++++++++
3 files changed, 349 insertions(+)
create mode 100644 drivers/thermal/bcm2835_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 2d702ca..6489723 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -399,4 +399,12 @@ config GENERIC_ADC_THERMAL
to this driver. This driver reports the temperature by reading ADC
channel and converts it to temperature based on lookup table.
+config BCM2835_THERMAL
+ tristate "Thermal sensors on bcm2835 SoC"
+ depends on ARCH_BCM2835 || ARCH_BCM2836 || ARCH_BCM2837 || COMPILE_TEST
+ depends on OF
+ depends on HAS_IOMEM
+ help
+ Support for thermal sensors on Broadcom bcm2835 SoCs.
+
endif
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 10b07c1..c26343e 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -51,3 +51,4 @@ obj-$(CONFIG_TEGRA_SOCTHERM) += tegra/
obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
+obj-$(CONFIG_BCM2835_THERMAL) += bcm2835_thermal.o
diff --git a/drivers/thermal/bcm2835_thermal.c b/drivers/thermal/bcm2835_thermal.c
new file mode 100644
index 0000000..3468c7b
--- /dev/null
+++ b/drivers/thermal/bcm2835_thermal.c
@@ -0,0 +1,340 @@
+/*
+ * Driver for Broadcom BCM2835 soc temperature sensor
+ *
+ * Copyright (C) 2016 Martin Sperl
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/debugfs.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/thermal.h>
+
+#define BCM2835_TS_TSENSCTL 0x00
+#define BCM2835_TS_TSENSSTAT 0x04
+
+#define BCM2835_TS_TSENSCTL_PRWDW BIT(0)
+#define BCM2835_TS_TSENSCTL_RSTB BIT(1)
+#define BCM2835_TS_TSENSCTL_CTRL_BITS 3
+#define BCM2835_TS_TSENSCTL_CTRL_SHIFT 2
+#define BCM2835_TS_TSENSCTL_CTRL_MASK \
+ GENMASK(BCM2835_TS_TSENSCTL_CTRL_BITS + \
+ BCM2835_TS_TSENSCTL_CTRL_SHIFT - 1, \
+ BCM2835_TS_TSENSCTL_CTRL_SHIFT)
+#define BCM2835_TS_TSENSCTL_CTRL_DEFAULT 1
+#define BCM2835_TS_TSENSCTL_EN_INT BIT(5)
+#define BCM2835_TS_TSENSCTL_DIRECT BIT(6)
+#define BCM2835_TS_TSENSCTL_CLR_INT BIT(7)
+#define BCM2835_TS_TSENSCTL_THOLD_SHIFT 8
+#define BCM2835_TS_TSENSCTL_THOLD_BITS 10
+#define BCM2835_TS_TSENSCTL_THOLD_MASK \
+ GENMASK(BCM2835_TS_TSENSCTL_THOLD_BITS + \
+ BCM2835_TS_TSENSCTL_THOLD_SHIFT - 1, \
+ BCM2835_TS_TSENSCTL_THOLD_SHIFT)
+#define BCM2835_TS_TSENSCTL_RSTDELAY_SHIFT 18
+#define BCM2835_TS_TSENSCTL_RSTDELAY_BITS 8
+#define BCM2835_TS_TSENSCTL_REGULEN BIT(26)
+
+#define BCM2835_TS_TSENSSTAT_DATA_BITS 10
+#define BCM2835_TS_TSENSSTAT_DATA_SHIFT 0
+#define BCM2835_TS_TSENSSTAT_DATA_MASK \
+ GENMASK(BCM2835_TS_TSENSSTAT_DATA_BITS + \
+ BCM2835_TS_TSENSSTAT_DATA_SHIFT - 1, \
+ BCM2835_TS_TSENSSTAT_DATA_SHIFT)
+#define BCM2835_TS_TSENSSTAT_VALID BIT(10)
+#define BCM2835_TS_TSENSSTAT_INTERRUPT BIT(11)
+
+struct bcm2835_thermal_info {
+ int offset;
+ int slope;
+ int trip_temp;
+};
+
+struct bcm2835_thermal_data {
+ const struct bcm2835_thermal_info *info;
+ void __iomem *regs;
+ struct clk *clk;
+ struct dentry *debugfsdir;
+};
+
+static int bcm2835_thermal_adc2temp(
+ const struct bcm2835_thermal_info *info, u32 adc)
+{
+ return info->offset + (adc * info->slope);
+}
+
+static int bcm2835_thermal_temp2adc(
+ const struct bcm2835_thermal_info *info, int temp)
+{
+ temp -= info->offset;
+ temp /= info->slope;
+
+ if (temp < 0)
+ temp = 0;
+ if (temp >= BIT(BCM2835_TS_TSENSSTAT_DATA_BITS))
+ temp = BIT(BCM2835_TS_TSENSSTAT_DATA_BITS) - 1;
+
+ return temp;
+}
+
+static int bcm2835_thermal_get_trip_type(
+ struct thermal_zone_device *tz, int trip,
+ enum thermal_trip_type *type)
+{
+ *type = THERMAL_TRIP_CRITICAL;
+ return 0;
+}
+
+static int bcm2835_thermal_get_trip_temp(
+ struct thermal_zone_device *tz, int trip, int *temp)
+{
+ struct bcm2835_thermal_data *data = tz->devdata;
+ u32 val = readl(data->regs + BCM2835_TS_TSENSCTL);
+
+ /* get the THOLD bits */
+ val &= BCM2835_TS_TSENSCTL_THOLD_MASK;
+ val >>= BCM2835_TS_TSENSCTL_THOLD_SHIFT;
+
+ /* if it is zero then use the info value */
+ if (val)
+ *temp = bcm2835_thermal_adc2temp(data->info, val);
+ else
+ *temp = data->info->trip_temp;
+
+ return 0;
+}
+
+static int bcm2835_thermal_get_temp(struct thermal_zone_device *tz,
+ int *temp)
+{
+ struct bcm2835_thermal_data *data = tz->devdata;
+ u32 val = readl(data->regs + BCM2835_TS_TSENSSTAT);
+
+ if (!(val & BCM2835_TS_TSENSSTAT_VALID))
+ return -EIO;
+
+ val &= BCM2835_TS_TSENSSTAT_DATA_MASK;
+
+ *temp = bcm2835_thermal_adc2temp(data->info, val);
+
+ return 0;
+}
+
+static const struct debugfs_reg32 bcm2835_thermal_regs[] = {
+ {
+ .name = "ctl",
+ .offset = 0
+ },
+ {
+ .name = "stat",
+ .offset = 4
+ }
+};
+
+static void bcm2835_thermal_debugfs(struct platform_device *pdev)
+{
+ struct thermal_zone_device *tz = platform_get_drvdata(pdev);
+ struct bcm2835_thermal_data *data = tz->devdata;
+ struct debugfs_regset32 *regset;
+
+ data->debugfsdir = debugfs_create_dir("bcm2835_thermal", NULL);
+ if (!data->debugfsdir)
+ return;
+
+ regset = devm_kzalloc(&pdev->dev, sizeof(*regset), GFP_KERNEL);
+ if (!regset)
+ return;
+
+ regset->regs = bcm2835_thermal_regs;
+ regset->nregs = ARRAY_SIZE(bcm2835_thermal_regs);
+ regset->base = data->regs;
+
+ debugfs_create_regset32("regset", S_IRUGO,
+ data->debugfsdir, regset);
+}
+
+static struct thermal_zone_device_ops bcm2835_thermal_ops = {
+ .get_temp = bcm2835_thermal_get_temp,
+ .get_trip_temp = bcm2835_thermal_get_trip_temp,
+ .get_trip_type = bcm2835_thermal_get_trip_type,
+};
+
+static const struct of_device_id bcm2835_thermal_of_match_table[];
+static int bcm2835_thermal_probe(struct platform_device *pdev)
+{
+ const struct of_device_id *match;
+ struct thermal_zone_device *tz;
+ struct bcm2835_thermal_data *data;
+ struct resource *res;
+ int err;
+ u32 val;
+ unsigned long rate;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ match = of_match_device(bcm2835_thermal_of_match_table,
+ &pdev->dev);
+ if (!match)
+ return -EINVAL;
+ data->info = match->data;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ data->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(data->regs)) {
+ err = PTR_ERR(data->regs);
+ dev_err(&pdev->dev, "Could not get registers: %d\n", err);
+ return err;
+ }
+
+ data->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(data->clk)) {
+ err = PTR_ERR(data->clk);
+ if (err != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Could not get clk: %d\n", err);
+ return err;
+ }
+
+ err = clk_prepare_enable(data->clk);
+ if (err)
+ return err;
+
+ rate = clk_get_rate(data->clk);
+ if ((rate < 1920000) || (rate > 5000000))
+ dev_warn(&pdev->dev,
+ "Clock %pCn running at %pCr Hz is outside of the recommended range: 1.92 to 5MHz\n",
+ data->clk, data->clk);
+
+ /*
+ * right now the FW does set up the HW-block, so we are not
+ * touching the configuration registers.
+ * But if the HW is not enabled, then set it up
+ * using "sane" values used by the firmware right now.
+ */
+ val = readl(data->regs + BCM2835_TS_TSENSCTL);
+ if (!(val & BCM2835_TS_TSENSCTL_RSTB)) {
+ /* the basic required flags */
+ val = (BCM2835_TS_TSENSCTL_CTRL_DEFAULT <<
+ BCM2835_TS_TSENSCTL_CTRL_SHIFT) |
+ BCM2835_TS_TSENSCTL_REGULEN;
+
+ /*
+ * reset delay using the current firmware value of 14
+ * - units of time are unknown.
+ */
+ val |= (14 << BCM2835_TS_TSENSCTL_RSTDELAY_SHIFT);
+
+ /* trip_adc value from info */
+ val |= bcm2835_thermal_temp2adc(data->info,
+ data->info->trip_temp) <<
+ BCM2835_TS_TSENSCTL_THOLD_SHIFT;
+
+ /* write the value back to the register as 2 steps */
+ writel(val, data->regs + BCM2835_TS_TSENSCTL);
+ val |= BCM2835_TS_TSENSCTL_RSTB;
+ writel(val, data->regs + BCM2835_TS_TSENSCTL);
+ }
+
+ /* register thermal zone with 1 trip point an 1s polling */
+ tz = thermal_zone_device_register("bcm2835_thermal",
+ 1, 0, data,
+ &bcm2835_thermal_ops,
+ NULL,
+ 0, 1000);
+ if (IS_ERR(tz)) {
+ clk_disable_unprepare(data->clk);
+ err = PTR_ERR(tz);
+ dev_err(&pdev->dev,
+ "Failed to register the thermal device: %d\n",
+ err);
+ return err;
+ }
+
+ platform_set_drvdata(pdev, tz);
+
+ bcm2835_thermal_debugfs(pdev);
+
+ return 0;
+}
+
+static int bcm2835_thermal_remove(struct platform_device *pdev)
+{
+ struct thermal_zone_device *tz = platform_get_drvdata(pdev);
+ struct bcm2835_thermal_data *data = tz->devdata;
+
+ debugfs_remove_recursive(data->debugfsdir);
+ thermal_zone_device_unregister(tz);
+ clk_disable_unprepare(data->clk);
+
+ return 0;
+}
+
+/*
+ * Note: as per Raspberry Foundation FAQ
+ * (https://www.raspberrypi.org/help/faqs/#performanceOperatingTemperature)
+ * the recommended temperature range for the SOC -40C to +85C
+ * so the trip limit is set to 80C.
+ * this applies to all the BCM283X SOC
+ */
+
+static const struct of_device_id bcm2835_thermal_of_match_table[] = {
+ {
+ .compatible = "brcm,bcm2835-thermal",
+ .data = &(struct bcm2835_thermal_info) {
+ .offset = 407000,
+ .slope = -538,
+ .trip_temp = 80000
+ }
+ },
+ {
+ .compatible = "brcm,bcm2836-thermal",
+ .data = &(struct bcm2835_thermal_info) {
+ .offset = 407000,
+ .slope = -538,
+ .trip_temp = 80000
+ }
+ },
+ {
+ .compatible = "brcm,bcm2837-thermal",
+ .data = &(struct bcm2835_thermal_info) {
+ /* the bcm2837 needs adjustment of +5C */
+ .offset = 407000 + 5000,
+ .slope = -538,
+ .trip_temp = 80000
+ }
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, bcm2835_thermal_of_match_table);
+
+static struct platform_driver bcm2835_thermal_driver = {
+ .probe = bcm2835_thermal_probe,
+ .remove = bcm2835_thermal_remove,
+ .driver = {
+ .name = "bcm2835_thermal",
+ .of_match_table = bcm2835_thermal_of_match_table,
+ },
+};
+module_platform_driver(bcm2835_thermal_driver);
+
+MODULE_AUTHOR("Martin Sperl");
+MODULE_DESCRIPTION("Thermal driver for bcm2835 chip");
+MODULE_LICENSE("GPL");
--
2.1.4
^ permalink raw reply related
* [PATCH V6 1/6] dt: bindings: add thermal device driver for bcm2835
From: kernel at martin.sperl.org @ 2016-09-19 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474275600-19378-1-git-send-email-kernel@martin.sperl.org>
From: Martin Sperl <kernel@martin.sperl.org>
Add dt-binding documentation for bcm2835 SOC thermal sensor.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Acked-by: Eric Anholt <eric@anholt.net>
Acked-by: Rob Herring <robh@kernel.org>
Changelog:
V1 -> V2: renamed file to follow naming conventions
V2 -> V3: removed 0x in node name
---
.../bindings/thermal/brcm,bcm2835-thermal.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt
new file mode 100644
index 0000000..474531d
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt
@@ -0,0 +1,17 @@
+Binding for Thermal Sensor driver for BCM2835 SoCs.
+
+Required parameters:
+-------------------
+
+compatible: should be one of: "brcm,bcm2835-thermal",
+ "brcm,bcm2836-thermal" or "brcm,bcm2837-thermal"
+reg: Address range of the thermal registers.
+clocks: Phandle of the clock used by the thermal sensor.
+
+Example:
+
+thermal: thermal at 7e212000 {
+ compatible = "brcm,bcm2835-thermal";
+ reg = <0x7e212000 0x8>;
+ clocks = <&clocks BCM2835_CLOCK_TSENS>;
+};
--
2.1.4
^ permalink raw reply related
* [PATCH V6 0/6] thermal: bcm2835: add thermal driver
From: kernel at martin.sperl.org @ 2016-09-19 8:59 UTC (permalink / raw)
To: linux-arm-kernel
From: Martin Sperl <kernel@martin.sperl.org>
Add a thermal driver for the TSENSE device of the bcm2835/6/7 SOC.
If the firmware enables the HW, then the configuration is not touched.
In case the firmware has not enabled the device, then we try to set
it up correctly (which unfortunately can not get tested).
It exposes temperature and a critical trip point
(using a hardcoded default of 80C or the temperature configured
in the control register by the firmware, which reads as
407C currently)
The calibrations are (potentially) different for bcm2835, bcm2836
and bcm2837 and can get selected by the compatible property
in the device tree.
The driver also exposes the registers via debugfs.
Possible future enhancements:
* the device has the ability to trigger interrupts on reaching
the programmed critical temperature.
I have no knowledge which interrupt could be responsible
for this on the ARM side, so if we get to know which irq
it is we can implement that.
Instead the driver right now implements polling in 1 second intervals
* the device can also reset the HW after the trip point
has been reached (also with some delay, so that corrective
actions can get taken) - this is currently not enabled by the
firmware, but could.
* we could define more trip points for THERMAL_TRIP_HOT
* make the trip point limits modifiable (ops.set_trip_temp)
Note:
No support for 32-bit arm bcm2837, as there is no
arch/arm/boot/dts/bcm2836.dtsi upstream as of now.
64-bit arm support is not tested
Changelog:
V1 -> V2: renamed dt-binding documentation file
added specific settings depending on compatible
added trip point based on register
setting up ctrl-register if HW is not enabled by firmware
as per recommendation of Eric (untested)
check that clock frequency is in range
(1.9 - 5MHz - as per comment in clk-bcm2835.c)
added driver to multi_v7_defconfig
V2 -> V3: made a module in multi_v7_defconfig
fixed typo in dt-binding document
V3 -> V4: moved driver back to thermal (not using bcm sub-directory)
set polling interval to 1second (was 0ms, so interrupt driven)
V4 -> V5: use correct compatiblity for different soc versions in dt
support ARM64 for bcm2837 in devicetree and defconfig
V5 -> V6: incorporated changes recommended by Stefan Wahren
Martin Sperl (6):
dt: bindings: add thermal device driver for bcm2835
thermal: bcm2835: add thermal driver for bcm2835 soc
ARM: bcm2835: dts: add thermal node to device-tree of bcm283x
ARM64: bcm2835: dts: add thermal node to device-tree of bcm2837
ARM: bcm2835: add thermal driver to default_config
ARM64: bcm2835: add thermal driver to default_config
.../bindings/thermal/brcm,bcm2835-thermal.txt | 17 ++
arch/arm/boot/dts/bcm2835.dtsi | 6 +
arch/arm/boot/dts/bcm2836.dtsi | 6 +
arch/arm/boot/dts/bcm283x.dtsi | 7 +
arch/arm/configs/bcm2835_defconfig | 2 +
arch/arm64/boot/dts/broadcom/bcm2837.dtsi | 6 +
arch/arm64/configs/defconfig | 1 +
drivers/thermal/Kconfig | 8 +
drivers/thermal/Makefile | 1 +
drivers/thermal/bcm2835_thermal.c | 340 +++++++++++++++++++++
10 files changed, 394 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt
create mode 100644 drivers/thermal/bcm2835_thermal.c
--
2.1.4
^ permalink raw reply
* [PATCH 00/19] [RESEND] Remove STiH415 and STiH416 SoC platform support
From: Peter Griffin @ 2016-09-19 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10792443.jxCOopyCy4@wuerfel>
Hi Arnd,
On Thu, 15 Sep 2016, Arnd Bergmann wrote:
> On Thursday, September 15, 2016 8:01:39 AM CEST Peter Griffin wrote:
> >
> > STiH415 I'm sure never shipped. I'm reasonably sure STiH416 didn't
> > either. These SoCs were considered legacy even when I was at ST
> > ~3 years ago.
> >
> > Also remember these are STB SoC's, so JTAG fuses are blown in
> > production boxes, and also full security is enabled. This means the
> > primary bootloader will only boot a signed kernel. So if a end user
> > did happen to have a box they would be unable to upgrade their kernel.
> >
> > From the landing team perspective they were interesting in that they
> > shared many IPs with the STiH407 family on which future chipsets were
> > based, and were available to us when that silicon was harder to get
> > hold of. So we used it as a vehicle for upstreaming so that upstream
> > support was already quite good when STiH407 silicon did land on our
> > desk.
>
> Ok, makes sense. I did stumble over one machine basedon STiH412
> the other day [1], but there probably isn't much shared with that
> one. Since this a NAS server rather than an STB box, it's probably
> less locked-down and potentially a target for OpenWRT or similar.
I just double checked with ST and STiH412 is a STiH407 family based SoC
so support still exists for this upstream. No idea what if any security is
enabled on this product though.
Most probably the A/V stack on it will be SDK2, although native upstream
multimedia drivers for this chipset are looking pretty good now.
Peter.
> [1] http://www.heise.de/preisvergleich/synology-diskstation-ds216play-16tb-a1400885.html
^ permalink raw reply
* [PATCH RFC 4/8] ARM: shmobile: r8a7743: basic SoC support
From: Geert Uytterhoeven @ 2016-09-19 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7093322.WFIWVqz40g@wasted.cogentembedded.com>
Hi Sergei,
On Fri, Sep 16, 2016 at 3:33 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add minimal support for the RZ/G1M (R8A7743) SoC.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> arch/arm/mach-shmobile/Kconfig | 5 ++++
> arch/arm/mach-shmobile/Makefile | 1
> arch/arm/mach-shmobile/setup-r8a7743.c | 34 +++++++++++++++++++++++++++++++++
> 3 files changed, 40 insertions(+)
>
> Index: renesas/arch/arm/mach-shmobile/Kconfig
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/Kconfig
> +++ renesas/arch/arm/mach-shmobile/Kconfig
> @@ -68,6 +68,11 @@ config ARCH_R8A7740
> select ARCH_RMOBILE
> select RENESAS_INTC_IRQPIN
>
> +config ARCH_R8A7743
> + bool "RZ/G1M (R8A77430)"
> + select ARCH_RCAR_GEN2
> + select I2C
The only reason R8A779[013] selects I2C is because they need
regulator-quirk-rcar-gen2.c. Without schematics, it's hard to say if this is
needed for SK-RZG1M, too.
The Board Hardware Manual states SK-RZG1M has both DA9063 and DA9210.
It does state DA9063 is connected to IRQ2, but doesn't mention an interrupt
line for DA9210, so we don't know if they share IRQ2. Note that the Koelsch
fails to mention that DA9210 uses IRQ2, so this doesn't mean much.
For Porter we do not have the quirk enabled, while it has both regulators, too.
You can try to enable regulator-quirk-rcar-gen2.c for "renesas,sk-rzg1m" too,
and see what's printed by the kernel after a cold boot...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
^ permalink raw reply
* [GIT PULL 3/4] Broadcom devicetree changes for 4.9
From: Arnd Bergmann @ 2016-09-19 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473213558-11782-3-git-send-email-f.fainelli@gmail.com>
On Tuesday, September 6, 2016 6:59:17 PM CEST Florian Fainelli wrote:
> This pull request contains Broadcom ARM-based Device Tree changes for v4.9,
> please pull the following:
>
> - Jon adds support for the Ethernet MAC DT nodes (AMAC) and provides the
> following updates for Broadcom references boards:
> * New Northstar Plus reference boards added: BCM958525er, BCM958522er,
> BCM988312hr, BCM958623hr and BCM958622hr
> * Add SATA nodes to the BCM958625hr and XMC boards
> * Add I2C nodes to the XMC board
> * Fixes the amount of RAM on BCM958625HR, BCM958625K and BCM958525XMC boards
> * Add the GPIO reboot method for BCM958625hr and XMC boards
>
> - Dhanajay adds PWM nodes for the Northstar Plus SoCs
>
> - Rafal adds the USB 2.0 PHY to the BCM5301x Device Tree file include
>
> - Stefan adds a missing USB clock to the BCM283x DT files, adds a DTSI file for
> the USB host mode on BCM283x and finally documents and adds support for the
> Raspberry Pi Zero
>
> - Florian adds support for the Northstar Plus Switch Register Access block which
> enables the integrated switch on these SoCs and enables the switch ports on the
> BCM958625HR reference board
>
I pulled this into next/dt last Thursday but forgot to send a notification.
Florian already asked me about on Friday, thanks a lot for paying attention!
Arnd
^ permalink raw reply
* [PATCH] pinctrl: nomadik: don't default-flag IRQs as falling
From: Marc Zyngier @ 2016-09-19 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474273330-15789-1-git-send-email-linus.walleij@linaro.org>
On 19/09/16 09:22, Linus Walleij wrote:
> There is no point in adding any default trigger for these
> GPIO interrupts: the device tree should contain all trigger
> information and the platforms using the driver boots
> exclusively from device tree.
>
> Also the boot log is nagging me to fix this:
>
> [ 0.771057] ------------[ cut here ]------------
> [ 0.775695] WARNING: CPU: 0 PID: 1 at
> ../drivers/gpio/gpiolib.c:1622 _gpiochip_irqchip_add+0x138/0x160
> [ 0.785034] /soc/gpio at 8012e000: Ignoring 2 default trigger
> (...)
> [ 0.942962] gpio 8012e000.gpio: at address e08f8000
> (etc ad nauseam)
>
> Suggested-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/pinctrl/nomadik/pinctrl-nomadik.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/nomadik/pinctrl-nomadik.c b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
> index 205fb399268a..d318ca055489 100644
> --- a/drivers/pinctrl/nomadik/pinctrl-nomadik.c
> +++ b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
> @@ -1177,7 +1177,7 @@ static int nmk_gpio_probe(struct platform_device *dev)
> irqchip,
> 0,
> handle_edge_irq,
> - IRQ_TYPE_EDGE_FALLING);
> + IRQ_TYPE_NONE);
> if (ret) {
> dev_err(&dev->dev, "could not add irqchip\n");
> gpiochip_remove(&nmk_chip->chip);
>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Add entries for sound support on Odroid-XU board
From: Sylwester Nawrocki @ 2016-09-19 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160917200017.GA13666@kozik-lap>
On 09/17/2016 10:00 PM, Krzysztof Kozlowski wrote:
> On Fri, Sep 16, 2016 at 01:58:32PM +0200, Krzysztof Kozlowski wrote:
>> > On 09/16/2016 01:25 PM, Sylwester Nawrocki wrote:
>>> > > On 09/16/2016 01:22 PM, Sylwester Nawrocki wrote:
>>>> > >> This patch adds device nodes for the AUDSS clock controller,
>>>> > >> peripheral DMA 0/1 controllers and the Audio Subsystem I2S controller.
>>>> > >> These entries are required for sound support on Odroid-XU board.
>>>> > >>
>>>> > >> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>>>> > >> ---
>>>> > >> This patch depends on a patch adding clock ID macro definitions.
>>>> > >> I'm going to provide a topic branch containing required changes.
>>>> > >>
>>>> > >> Changes since v1:
>>>> > >> - GIC_SPI, IRQ_TYPE_NONE used in the PDMA and max98080 interrupt
>>>> > >> specifiers,
>>>> > >> - assigned-clock-* properties moved to respective controller
>>>> > >> nodes.
>>> > >
>>> > > And here is a pull request containing clk dependency patches:
>>> > >
>>> > > The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>>> > >
>>> > > Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
>>> > >
>>> > > are available in the git repository at:
>>> > >
>>> > > git://linuxtv.org/snawrocki/samsung.git tags/clk-v4.9-exynos54x0-dt
>>> > >
>>> > > for you to fetch changes up to 58d6506f327e3d192998ba03632f546da221b8d8:
>>> > >
>>> > > clk: samsung: exynos5410: Add clock IDs for PDMA and EPLL clocks (2016-09-09
>>> > > 10:13:02 +0200)
>>> > >
>> >
>> > Pulled and applied, thanks!
>
> This does not boot...
> http://www.krzk.eu/builders/boot-odroid-xu-exynos/builds/216
> http://www.krzk.eu/builders/boot-odroid-xu-multi_v7/builds/195
>
> I am going to send pull request this weekend (or Monday) so probably this
> won't be included. If by any chance you prepare a fix soon, then it
> will save me from rebasing the branch.
Oops, indeed, I didn't test with just that part of clk changes applied.
The only resolution here I can see is to pull my whole clk branch,
it has already been pulled to the upstream clk tree.
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
git://linuxtv.org/snawrocki/samsung.git tags/clk-v4.9-samsung
for you to fetch changes up to be95d2c7d918b2b7b973378a1e92bdc6559c21f9:
clk: samsung: Add support for EPLL on exynos5410 (2016-09-09 17:35:13 +0200)
----------------------------------------------------------------
In addition to a few clean up and code consolidation patches this
includes:
- addition of sound subsystem related clocks for Exynos5410 SoC
(EPLL, PDMA) and support for "samsung,exynos5410-audss-clock"
compatible in the clk-exynos-audss driver,
- addition of DRAM controller related clocks for exynos5420,
- MAINTAINERS update adding Chanwoo Choi as the Samsung SoC
clock drivers co-maintainer.
----------------------------------------------------------------
Chanwoo Choi (5):
clk: samsung: Add clock IDs for the CMU_CDREX (DRAM Express Controller)
MAINTAINERS: Add myself as Samsung SoC clock drivers co-maintainer
clk: samsung: exynos5260: Move struct samsung_cmu_info to init section
clk: samsung: exynos5410: Use samsung_cmu_register_one() to simplify code
clk: samsung: exynos5420: Add clocks for CMU_CDREX domain
Sylwester Nawrocki (7):
clk: samsung: exynos5410: Add clock IDs for PDMA and EPLL clocks
clk: samsung: exynos5410: Expose the peripheral DMA gate clocks
clk: samsung: Use common registration function for pll2550x
clk: samsung: clk-exynos-audss: controller variant handling rework
clk: samsung: clk-exynos-audss: Add exynos5410 compatible
clk: samsung: clk-exynos-audss: Whitespace and debug trace cleanup
clk: samsung: Add support for EPLL on exynos5410
.../devicetree/bindings/clock/clk-exynos-audss.txt | 4 +-
.../devicetree/bindings/clock/exynos5410-clock.txt | 21 +-
MAINTAINERS | 3 +
drivers/clk/samsung/clk-exynos-audss.c | 84 +++--
drivers/clk/samsung/clk-exynos5260.c | 350 ++++++++++-----------
drivers/clk/samsung/clk-exynos5410.c | 61 ++--
drivers/clk/samsung/clk-exynos5420.c | 37 +++
drivers/clk/samsung/clk-exynos5440.c | 9 +-
drivers/clk/samsung/clk-pll.c | 154 ++++++---
drivers/clk/samsung/clk-pll.h | 2 +
include/dt-bindings/clock/exynos5410.h | 3 +
include/dt-bindings/clock/exynos5420.h | 11 +-
include/dt-bindings/clock/exynos5440.h | 2 +
13 files changed, 453 insertions(+), 288 deletions(-)
--
Thanks,
Sylwester
^ permalink raw reply
* [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization
From: Andy Yan @ 2016-09-19 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474274639-27768-1-git-send-email-andy.yan@rock-chips.com>
The current rk3066a based boards(Rayeager, Bqcurie2, Marsboard) use
pwm modulate vdd_logic voltage, but the pwm is default disabled and
the pwm pin acts as a gpio before pwm regulator probed, so the pwm
regulator driver will get a zero dutycycle at probe time, so change
the initial dutycycle to zero to match pwm_regulator_init_state check.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
---
arch/arm/boot/dts/rk3066a-bqcurie2.dts | 2 +-
arch/arm/boot/dts/rk3066a-marsboard.dts | 2 +-
arch/arm/boot/dts/rk3066a-rayeager.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
index bc674ee..618450d 100644
--- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
+++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
@@ -61,7 +61,7 @@
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
- voltage-table = <1000000 100>,
+ voltage-table = <1000000 0>,
<1200000 42>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/rk3066a-marsboard.dts b/arch/arm/boot/dts/rk3066a-marsboard.dts
index a2b763e..ddc680b 100644
--- a/arch/arm/boot/dts/rk3066a-marsboard.dts
+++ b/arch/arm/boot/dts/rk3066a-marsboard.dts
@@ -59,7 +59,7 @@
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
- voltage-table = <1000000 100>,
+ voltage-table = <1000000 0>,
<1200000 42>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/rk3066a-rayeager.dts b/arch/arm/boot/dts/rk3066a-rayeager.dts
index 2536b3a..30aee99 100644
--- a/arch/arm/boot/dts/rk3066a-rayeager.dts
+++ b/arch/arm/boot/dts/rk3066a-rayeager.dts
@@ -84,7 +84,7 @@
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
- voltage-table = <1000000 100>,
+ voltage-table = <1000000 0>,
<1200000 42>;
status = "okay";
};
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox