* [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] 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 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] 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 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: 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
* [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 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
* [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 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 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] arm: dts: fix rk3066a based boards vdd_log voltage initialization
From: Andy Yan @ 2016-09-19 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919112522.5567b882@bbrezillon>
On 2016?09?19? 17:25, Boris Brezillon wrote:
> 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>)?
no, 42% duty cycle give a stable 1.2v vdd_logic voltage on my
board. As i explained in the commit, the pwm was default at a disabled
state before regulator_register success at pwm_regulator probe, so
pwm_regulator_init_state function will get a zero dutycycle from
pwm_get_relative_dutycycle. I have to change the dutycycle of fist
table to zero to match the following check, other wise the function will
return defualt value(-EINVAL), then the pwm regulator register failed.
>
>> 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] ASoC: samsung: make audio interface/controller explicitly
From: Ayaka @ 2016-09-19 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919083342.GE10189@sirena.org.uk>
??? iPad ??
> Mark Brown <broonie@kernel.org> ? 2016?9?19? ??4:33 ???
>
>> On Sun, Sep 18, 2016 at 10:09:11PM +0800, Randy Li wrote:
>>
>> It is simple sound card time, we could assign different codec
>> to a interface without making a specific driver for it.
>
>> config SND_SAMSUNG_AC97
>> - tristate
>> + tristate "Samsung AC97 controller support"
>> select SND_SOC_AC97_BUS
>
> Are you *sure* simple-card works for AC'97?
Not sure. I could hardly find a AC97 device in embedded market. If it didn't I could disable it. I have only tested simple sound card for i2s and SPDIF.
^ permalink raw reply
* [RFC PATCH v2 05/11] ACPI: platform: setup MSI domain for ACPI based platform device
From: Hanjun Guo @ 2016-09-19 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DABBB3.3020208@arm.com>
On 2016/9/15 23:18, Marc Zyngier wrote:
> On 15/09/16 15:05, Hanjun Guo wrote:
>> Hi Marc,
[...]
>>>> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
>>>> index 6482d47..ea01a37 100644
>>>> --- a/drivers/base/platform.c
>>>> +++ b/drivers/base/platform.c
>>>> @@ -24,6 +24,7 @@
>>>> #include <linux/pm_domain.h>
>>>> #include <linux/idr.h>
>>>> #include <linux/acpi.h>
>>>> +#include <linux/msi.h>
>>>> #include <linux/clk/clk-conf.h>
>>>> #include <linux/limits.h>
>>>> #include <linux/property.h>
>>>> @@ -500,6 +501,7 @@ struct platform_device *platform_device_register_full(
>>>> pdev->dev.parent = pdevinfo->parent;
>>>> pdev->dev.fwnode = pdevinfo->fwnode;
>>>>
>>>> + acpi_configure_msi_domain(&pdev->dev);
>>>
>>> It feels odd to put this in the generic code, while you could perfectly
>>> put the call into acpi_platform.c and keep the firmware stuff away from
>>> the generic code.
>>
>> My feeling is the same, I'm still trying to find a new way to do it,
>> but I can't simply put that in acpi_platform.c, because
>>
>> acpi_create_platform_device()
>> platform_device_register_full()
>> platform_device_alloc() --> dev is alloced
>> ...
>> dev.fwnode is set
>> (I get the msi domain by the fwnode in acpi_configure_msi_domain)
>> ...
>> platform_device_add() --> which the device is probed.
>>
>> For devices like irqchip which needs the dev->msi_domain to be
>> set before it's really probed, because it needs the msi domain
>> to be the parent domain.
>>
>> If I call the function in acpi_create_platform_device() before
>> platform_device_register_full(), we just can't set dev's msi
>> domain, but if call it after platform_device_register_full(),
>> the irqchip like mbigen will not get its parent domain...
>>
>> DT is using another API for platform device probe, so has no
>> problems like I said above, any suggestions to do it right in
>> ACPI?
>
> How about having something that's completely generic and solves
> the problem once and for all? Something like this:
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 6482d47..6f0f90b 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -533,6 +533,9 @@ struct platform_device *platform_device_register_full(
> goto err;
> }
>
> + if (pdevinfo->pre_add_cb)
> + pdevinfo->pre_add_cb(&pdev->dev);
> +
> ret = platform_device_add(pdev);
> if (ret) {
> err:
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index 98c2a7c..44ea133 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -74,6 +74,7 @@ struct platform_device_info {
> u64 dma_mask;
>
> struct property_entry *properties;
> + void (*pre_add_cb)(struct device *);
> };
> extern struct platform_device *platform_device_register_full(
> const struct platform_device_info *pdevinfo);
>
> Plug pre_add_cb with your ACPI callback where you can do all the
> processing you want before the device is actually added.
Great, will do, thank you very much!
Hanjun
^ permalink raw reply
* [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization
From: Boris Brezillon @ 2016-09-19 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <66bc44e2-2549-c6d1-150c-5ddadf538f06@rock-chips.com>
On Mon, 19 Sep 2016 17:38:10 +0800
Andy Yan <andy.yan@rock-chips.com> wrote:
> On 2016?09?19? 17:25, Boris Brezillon wrote:
> > 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>)?
>
>
> no, 42% duty cycle give a stable 1.2v vdd_logic voltage on my
> board. As i explained in the commit, the pwm was default at a disabled
> state before regulator_register success at pwm_regulator probe, so
> pwm_regulator_init_state function will get a zero dutycycle from
> pwm_get_relative_dutycycle. I have to change the dutycycle of fist
> table to zero to match the following check, other wise the function will
> return defualt value(-EINVAL), then the pwm regulator register failed.
Is 0% duty really producing a 1V output, or are you just changing it to
make it work?
BTW, I'm not sure we should fail when the current PWM state does not
match one of the value in the voltage-table.
> >
> >> 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
* [RFC PATCH v2 11/11] irqchip: mbigen: promote mbigen init
From: Hanjun Guo @ 2016-09-19 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DABD2F.1030606@arm.com>
On 2016/9/15 23:24, Marc Zyngier wrote:
> On 14/09/16 15:21, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> mbigen is an irqchip and it needs to be probed before
>> devices, same logic is used for SMMU and etc., let's
>> use arch_initcall instead of platform init for mbigen.
>>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ma Jun <majun258@huawei.com>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> drivers/irqchip/irq-mbigen.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
>> index ca6add1..3a33de6 100644
>> --- a/drivers/irqchip/irq-mbigen.c
>> +++ b/drivers/irqchip/irq-mbigen.c
>> @@ -374,7 +374,11 @@ static struct platform_driver mbigen_platform_driver = {
>> .probe = mbigen_device_probe,
>> };
>>
>> -module_platform_driver(mbigen_platform_driver);
>> +static __init int mbigen_init(void)
>> +{
>> + return platform_driver_register(&mbigen_platform_driver);
>> +}
>> +arch_initcall(mbigen_init);
>>
>> MODULE_AUTHOR("Jun Ma <majun258@huawei.com>");
>> MODULE_AUTHOR("Yun Wu <wuyun.wu@huawei.com>");
>>
>
> I've already NACKed such a patch in the past, and I will carry on
> NACKing it until all the other avenues (like properly tracking device
> dependencies) have been explored and have been proven not to be fit for
> purpose.
I'd happy to work on this to make progress.
>
> Rafael had proposed something around this subject last year, and I've
Sorry, obviously I missed something, could you give me the link about
Rafael's patches? I will pull back and test it on our hardware.
> been repeatedly advising you to work with him and others to make it
> happen. You can choose to ignore this advise, but that doesn't make this
> patch an acceptable approach.
OK, I will drop this patch in next version, and work on the generic
solution instead.
Thanks
Hanjun
^ permalink raw reply
* [PATCH v4 1/7] pinctrl: bcm2835: add pull defines to dt bindings
From: Eric Anholt @ 2016-09-19 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474274603-24215-2-git-send-email-kraxel@redhat.com>
Gerd Hoffmann <kraxel@redhat.com> writes:
> Also delete (unused) private enum from driver.
> The pull defines can be used instead if needed.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Eric Anholt <eric@anholt.net>
gpio maintainers, could I pull this through my dt tree? Or does this
need to be split in two?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/82c39ac2/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] arm64: defconfig: enable I2C and DW MMC controller on rockchip platform
From: Andy Yan @ 2016-09-19 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473248790-27101-1-git-send-email-andy.yan@rock-chips.com>
Hi :
Respected maintainers, is there some suggestions for this patch?
On 2016?09?07? 19:46, Andy Yan wrote:
> I2C and MMC are very basic modules for a board to bootup, as I2C always
> used to configure PMIC and MMC devices often used to store filesytem.
> So enable them here to let the rockchip based arm64 boards can bootup.
>
> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
> ---
>
> arch/arm64/configs/defconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index eadf485..427b6dc 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -222,6 +222,7 @@ CONFIG_I2C_QUP=y
> CONFIG_I2C_TEGRA=y
> CONFIG_I2C_UNIPHIER_F=y
> CONFIG_I2C_RCAR=y
> +CONFIG_I2C_RK3X=y
> CONFIG_I2C_CROS_EC_TUNNEL=y
> CONFIG_SPI=y
> CONFIG_SPI_ORION=y
> @@ -323,6 +324,7 @@ CONFIG_MMC_SPI=y
> CONFIG_MMC_DW=y
> CONFIG_MMC_DW_EXYNOS=y
> CONFIG_MMC_DW_K3=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> CONFIG_MMC_SUNXI=y
> CONFIG_NEW_LEDS=y
> CONFIG_LEDS_CLASS=y
^ permalink raw reply
* [PATCH 5/6] arm/arm64: vgic-new: Implement VGICv3 CPU interface access
From: Peter Maydell @ 2016-09-19 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6s=FOVv8t-6s4VJYwqUGaCfqMxrjXuop=JX6UYrYVj7Fg@mail.gmail.com>
On 19 September 2016 at 08:36, Vijay Kilari <vijay.kilari@gmail.com> wrote:
> In order to track the PRI and ID bits written by guest,
> VGIC needs to store these values when ICC_CTRL_EL1 is updated.
> However, QEMU is reseting VGIC by writing 0's to all the
> registers after VGIC initialization and hence the back up values are
> always reset to 0 and hence when guest read back, VGIC returns wrong value.
>
> One option is to drop VGIC reset from QEMU which is not doing much.
No, if QEMU's reset is not resetting registers to the right value
the correct thing to do is fix the reset code. The way device
reset is supposed to work is that QEMU knows the right values
to use and it writes them to the kernel.
QEMU doesn't reset ICC_CTLR_EL1 to 0 for TCG:
cs->icc_ctlr_el1[GICV3_NS] = ICC_CTLR_EL1_A3V |
(1 << ICC_CTLR_EL1_IDBITS_SHIFT) |
(7 << ICC_CTLR_EL1_PRIBITS_SHIFT);
but I don't think that code gets run for the KVM VGIC.
thanks
-- PMM
^ permalink raw reply
* [RFC PATCH v2 11/11] irqchip: mbigen: promote mbigen init
From: Marc Zyngier @ 2016-09-19 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3f9b5a3e-13f4-75a4-15bc-f55e26740205@linaro.org>
On 19/09/16 10:49, Hanjun Guo wrote:
> On 2016/9/15 23:24, Marc Zyngier wrote:
>> On 14/09/16 15:21, Hanjun Guo wrote:
>>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>>
>>> mbigen is an irqchip and it needs to be probed before
>>> devices, same logic is used for SMMU and etc., let's
>>> use arch_initcall instead of platform init for mbigen.
>>>
>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Ma Jun <majun258@huawei.com>
>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> ---
>>> drivers/irqchip/irq-mbigen.c | 6 +++++-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
>>> index ca6add1..3a33de6 100644
>>> --- a/drivers/irqchip/irq-mbigen.c
>>> +++ b/drivers/irqchip/irq-mbigen.c
>>> @@ -374,7 +374,11 @@ static struct platform_driver mbigen_platform_driver = {
>>> .probe = mbigen_device_probe,
>>> };
>>>
>>> -module_platform_driver(mbigen_platform_driver);
>>> +static __init int mbigen_init(void)
>>> +{
>>> + return platform_driver_register(&mbigen_platform_driver);
>>> +}
>>> +arch_initcall(mbigen_init);
>>>
>>> MODULE_AUTHOR("Jun Ma <majun258@huawei.com>");
>>> MODULE_AUTHOR("Yun Wu <wuyun.wu@huawei.com>");
>>>
>>
>> I've already NACKed such a patch in the past, and I will carry on
>> NACKing it until all the other avenues (like properly tracking device
>> dependencies) have been explored and have been proven not to be fit for
>> purpose.
>
> I'd happy to work on this to make progress.
>
>>
>> Rafael had proposed something around this subject last year, and I've
>
> Sorry, obviously I missed something, could you give me the link about
> Rafael's patches? I will pull back and test it on our hardware.
Please see this discussion from almost a year ago:
https://patchwork.kernel.org/patch/7407401/
in which I give the existing pointers and explain why I'm pushing back
on things like this patch.
>
>> been repeatedly advising you to work with him and others to make it
>> happen. You can choose to ignore this advise, but that doesn't make this
>> patch an acceptable approach.
>
> OK, I will drop this patch in next version, and work on the generic
> solution instead.
That'd be the ideal thing, and that's what I suggested when we did meet
in BKK earlier this year. Obviously, I didn't convey my point clearly
enough.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v4 7/7] ARM: dts: bcm283x: drop alt3 from &gpio
From: Eric Anholt @ 2016-09-19 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474274603-24215-8-git-send-email-kraxel@redhat.com>
Gerd Hoffmann <kraxel@redhat.com> writes:
> As the alt3 group has no pins left drop it from &gpio.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
If you end up spinning another version for some reason, I'd squash this
patch with the previous one. But regardless, 3-7 are:
Acked-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/749771d8/attachment.sig>
^ permalink raw reply
* [PATCH] spi: dw: use relaxed IO accessor
From: Arnd Bergmann @ 2016-09-19 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919090041.4024-1-jszhang@marvell.com>
On Monday, September 19, 2016 5:00:41 PM CEST Jisheng Zhang wrote:
> Using the __raw functions is discouraged. Update the driver to use the
> relaxed functions.
>
> Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
This should mention that it fixes the driver for big-endian kernels.
However, it seems that the fix is only correct for the MMIO
registers, while the polled FIFO access is now wrong AFAICT,
both reader and writer:
static void dw_reader(struct dw_spi *dws)
{
u32 max = rx_max(dws);
u16 rxw;
while (max--) {
rxw = dw_read_io_reg(dws, DW_SPI_DR);
/* Care rx only if the transfer's original "rx" is not null */
if (dws->rx_end - dws->len) {
if (dws->n_bytes == 1)
*(u8 *)(dws->rx) = rxw;
else
*(u16 *)(dws->rx) = rxw;
}
dws->rx += dws->n_bytes;
}
}
As the FIFO is a byte stream, we have to use a non-swapping
accessor here, such as readsl() which would also take care of the
loop. The "n_bytes == 1" case probably should look like e.g.
*(u8 *)(dws->rx) = *(u8 *)&rxw;
so you are sure to get the first byte of the rxw variable
rather than the lower 8 bits.
> 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);
> }
>
What is the reason for using readl_relaxed() rather than the
normal readl() here? In almost all instances that these are
called, you don't care about the added latency and should just
default to the normal I/O functions.
Arnd
^ permalink raw reply
* next-20160914 build: 2 failures 3 warnings (next-20160914)
From: Mark Brown @ 2016-09-19 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914171137.GF27974@sirena.org.uk>
On Wed, Sep 14, 2016 at 06:11:37PM +0100, Mark Brown wrote:
> On Wed, Sep 14, 2016 at 09:18:08AM +0100, Build bot for Mark Brown wrote:
> Today's -next fails to build both arm and arm64 allmodconfig due to:
> > arm64-allmodconfig
> > ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
> > arm-allmodconfig
> > ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
> due to 262d5cc6ceb293 (mfd: tps65217: Add support for IRQs) since
> irq_set_parent() isn't exported.
This is still breaking the build, do we have any ETA on getting the
export added?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/1958a83c/attachment.sig>
^ permalink raw reply
* [PATCH] ASoC: samsung: make audio interface/controller explicitly
From: Mark Brown @ 2016-09-19 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1BBB8B7D-0C1B-48E0-A516-402515A04568@soulik.info>
On Mon, Sep 19, 2016 at 05:41:50PM +0800, Ayaka wrote:
> ??? iPad ??
Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns. Doing this makes your messages much
easier to read and reply to.
> > Are you *sure* simple-card works for AC'97?
> Not sure. I could hardly find a AC97 device in embedded market. If it
> didn't I could disable it. I have only tested simple sound card for
> i2s and SPDIF.
I would be very surprised if it does and AC'97 is supposed to be
enumerable and not need a card binding anyway so best to remove this one
for the time being.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/c6b270fe/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/1] clk: imx53: Add clocks configuration
From: Fabien Lahoudere @ 2016-09-19 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160918002451.GE15478@tiger>
From: Kalle Kankare <kalle.kankare@vincit.fi>
Add clocks configuration for CSI, FIRI and IEEE1588.
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
---
drivers/clk/imx/clk-imx51-imx53.c | 20 ++++++++++++++++++++
include/dt-bindings/clock/imx5-clock.h | 15 ++++++++++++++-
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx51-imx53.c b/drivers/clk/imx/clk-imx51-imx53.c
index 29d4c44..1e3c9ea 100644
--- a/drivers/clk/imx/clk-imx51-imx53.c
+++ b/drivers/clk/imx/clk-imx51-imx53.c
@@ -126,6 +126,7 @@ static const char *spdif0_com_sel[] = { "spdif0_podf", "ssi1_root_gate", };
static const char *mx51_spdif1_com_sel[] = { "spdif1_podf", "ssi2_root_gate", };
static const char *step_sels[] = { "lp_apm", };
static const char *cpu_podf_sels[] = { "pll1_sw", "step_sel" };
+static const char *ieee1588_sels[] = { "pll3_sw", "pll4_sw", "dummy" /* usbphy2_clk */, "dummy" /* fec_phy_clk */ };
static struct clk *clk[IMX5_CLK_END];
static struct clk_onecell_data clk_data;
@@ -543,6 +544,25 @@ static void __init mx53_clocks_init(struct device_node *np)
clk[IMX5_CLK_I2C3_GATE] = imx_clk_gate2("i2c3_gate", "per_root", MXC_CCM_CCGR1, 22);
clk[IMX5_CLK_SATA_GATE] = imx_clk_gate2("sata_gate", "ipg", MXC_CCM_CCGR4, 2);
+ clk[IMX5_CLK_FIRI_SEL] = imx_clk_mux("firi_sel", MXC_CCM_CSCMR2, 12, 2,
+ standard_pll_sel, ARRAY_SIZE(standard_pll_sel));
+ clk[IMX5_CLK_FIRI_PRED] = imx_clk_divider("firi_pred", "firi_sel", MXC_CCM_CSCDR3, 6, 3);
+ clk[IMX5_CLK_FIRI_PODF] = imx_clk_divider("firi_podf", "firi_pred", MXC_CCM_CSCDR3, 0, 6);
+ clk[IMX5_CLK_FIRI_SERIAL_GATE] = imx_clk_gate2("firi_serial_gate", "firi_podf", MXC_CCM_CCGR1, 28);
+ clk[IMX5_CLK_FIRI_IPG_GATE] = imx_clk_gate2("firi_ipg_gate", "ipg", MXC_CCM_CCGR1, 26);
+
+ clk[IMX5_CLK_CSI0_MCLK1_SEL] = imx_clk_mux("csi0_mclk1_sel", MXC_CCM_CSCMR2, 22, 2,
+ standard_pll_sel, ARRAY_SIZE(standard_pll_sel));
+ clk[IMX5_CLK_CSI0_MCLK1_PRED] = imx_clk_divider("csi0_mclk1_pred", "csi0_mclk1_sel", MXC_CCM_CSCDR4, 6, 3);
+ clk[IMX5_CLK_CSI0_MCLK1_PODF] = imx_clk_divider("csi0_mclk1_podf", "csi0_mclk1_pred", MXC_CCM_CSCDR4, 0, 6);
+ clk[IMX5_CLK_CSI0_MCLK1_GATE] = imx_clk_gate2("csi0_mclk1_serial_gate", "csi0_mclk1_podf", MXC_CCM_CCGR6, 4);
+
+ clk[IMX5_CLK_IEEE1588_SEL] = imx_clk_mux("ieee1588_sel", MXC_CCM_CSCMR2, 14, 2,
+ ieee1588_sels, ARRAY_SIZE(ieee1588_sels));
+ clk[IMX5_CLK_IEEE1588_PRED] = imx_clk_divider("ieee1588_pred", "ieee1588_sel", MXC_CCM_CSCDR2, 6, 3);
+ clk[IMX5_CLK_IEEE1588_PODF] = imx_clk_divider("ieee1588_podf", "ieee1588_pred", MXC_CCM_CSCDR2, 0, 6);
+ clk[IMX5_CLK_IEEE1588_GATE] = imx_clk_gate2("ieee1588_serial_gate", "ieee1588_podf", MXC_CCM_CCGR7, 6);
+
clk[IMX5_CLK_CKO1_SEL] = imx_clk_mux("cko1_sel", MXC_CCM_CCOSR, 0, 4,
mx53_cko1_sel, ARRAY_SIZE(mx53_cko1_sel));
clk[IMX5_CLK_CKO1_PODF] = imx_clk_divider("cko1_podf", "cko1_sel", MXC_CCM_CCOSR, 4, 3);
diff --git a/include/dt-bindings/clock/imx5-clock.h b/include/dt-bindings/clock/imx5-clock.h
index f4b7478..d382fc7 100644
--- a/include/dt-bindings/clock/imx5-clock.h
+++ b/include/dt-bindings/clock/imx5-clock.h
@@ -201,6 +201,19 @@
#define IMX5_CLK_STEP_SEL 189
#define IMX5_CLK_CPU_PODF_SEL 190
#define IMX5_CLK_ARM 191
-#define IMX5_CLK_END 192
+#define IMX5_CLK_FIRI_PRED 192
+#define IMX5_CLK_FIRI_SEL 193
+#define IMX5_CLK_FIRI_PODF 194
+#define IMX5_CLK_FIRI_SERIAL_GATE 195
+#define IMX5_CLK_FIRI_IPG_GATE 196
+#define IMX5_CLK_CSI0_MCLK1_PRED 197
+#define IMX5_CLK_CSI0_MCLK1_SEL 198
+#define IMX5_CLK_CSI0_MCLK1_PODF 199
+#define IMX5_CLK_CSI0_MCLK1_GATE 200
+#define IMX5_CLK_IEEE1588_PRED 201
+#define IMX5_CLK_IEEE1588_SEL 202
+#define IMX5_CLK_IEEE1588_PODF 203
+#define IMX5_CLK_IEEE1588_GATE 204
+#define IMX5_CLK_END 205
#endif /* __DT_BINDINGS_CLOCK_IMX5_H */
--
2.1.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