* [PATCH] crypto: sunxi-ss: mark sun4i_hash() static
From: Baoyou Xie @ 2016-09-24 4:28 UTC (permalink / raw)
To: linux-arm-kernel
We get 1 warning when building kernel with W=1:
drivers/crypto/sunxi-ss/sun4i-ss-hash.c:168:5: warning: no previous prototype for 'sun4i_hash' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
index 1afeb8e..0de2f62 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
@@ -165,7 +165,7 @@ int sun4i_hash_import_sha1(struct ahash_request *areq, const void *in)
* write remaining data in op->buf
* final state op->len=56
*/
-int sun4i_hash(struct ahash_request *areq)
+static int sun4i_hash(struct ahash_request *areq)
{
u32 v, ivmode = 0;
unsigned int i = 0;
--
2.7.4
^ permalink raw reply related
* Alignment issues with freescale FEC driver
From: David Miller @ 2016-09-24 2:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bc19d934-f50b-50d6-0f4f-ecfcb8a2a1c9@nelint.com>
From: Eric Nelson <eric@nelint.com>
Date: Fri, 23 Sep 2016 11:35:17 -0700
> From the i.MX6DQ reference manual, bit 7 of ENET_RACC says this:
>
> "RX FIFO Shift-16
>
> When this field is set, the actual frame data starts at bit 16 of the first
> word read from the RX FIFO aligning the Ethernet payload on a
> 32-bit boundary."
>
> Same for the i.MX6UL.
>
> I'm not sure what it will take to use this, but it seems to be exactly
> what we're looking for.
+1
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: David Miller @ 2016-09-24 2:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0fe7a310-2d2f-4fca-d698-85d66122d91c@nelint.com>
From: Eric Nelson <eric@nelint.com>
Date: Fri, 23 Sep 2016 10:33:29 -0700
> Since the hardware requires longword alignment for its' DMA transfers,
> aligning the IP header will require a memcpy, right?
I wish hardware designers didn't do this.
There is no conflict between DMA alignment and properly offseting
the packet data by two bytes.
All hardware designers have to do is allow 2 padding bytes to be
emitted by the chip before the actual packet data.
Then the longword or whatever DMA transfer alignment is met
whilst still giving the necessary flexibility for where the
packet data lands.
^ permalink raw reply
* [PATCH 0/2] i2c: meson: add gxbb compatible string
From: Rob Herring @ 2016-09-24 1:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923232641.GB5683@katana>
On Fri, Sep 23, 2016 at 6:26 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> > I intentionally don't ask people to send me the patches squashed. So,
>> > you will have them seperate in patchwork et al. I only squash them just
>> > before commiting to my tree. That's because I found that when digging
>> > through git history, it is much more convenient to have all the
>> > information in one commit.
>>
>> If git history was the only thing that mattered, then that would be
>> fine. But it is not. Maintainers should apply what's on the list.
>> Period.
>
> Huh? If you would *ask* me to stop squashing, I am listening to reasons.
I did state some reasons previously. Consistent rules for submitters
of DT bindings and being able to trace history beyond git. Now, I
guess you aren't changing the rules, but you probably aren't
requesting people to split DT bindings either? You might not be aware,
but we also generate a DT only tree with git-filter-branch[1] for
non-kernel projects to use bindings and dts files. For that, sure they
will only get the DT binding part of it, but what commit text do they
get? Finally, DT maintainer acks (which from me is a review really)
apply to the bindings only. Sometimes I review the drivers, but not
often. So I would like the git history of my reviews to be accurate in
terms of what I actually reviewed.
> If you want to force arbitrary rules on me, I am not. There are reasons
> where squashing/modifying patches makes more sense compared to forcing
> the author to resend. DTS bindings may not be one, we can discuss that.
> But that rule without allowing exceptions seems impractical to me.
Okay, "period" was a bit much. Exceptions are perfectly fine, we all
do some minor fixups time to time. It just shouldn't be the norm IMO.
Rob
[1] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
^ permalink raw reply
* [RFC 1/4] arm64: dts: msm8992 SoC and LG Bullhead (Nexus 5X) support
From: Jeremy McNicoll @ 2016-09-23 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147456957514.9057.12155171248212777735@sboyd-linaro>
On 2016-09-22 11:39 AM, Stephen Boyd wrote:
> Quoting Jeremy McNicoll (2016-09-20 17:42:02)
>> On 2016-07-08 10:41 AM, Andy Gross wrote:
>>> On Thu, Jul 07, 2016 at 05:41:04PM -0700, Jeremy McNicoll wrote:
>>>> +
>>>> +#include "../qcom/msm8992.dtsi"
>>>> +
>>>> +/ {
>>>> + model = "LGE MSM8992 BULLHEAD rev-1.01";
>>>> + compatible = "qcom,msm8992";
>>>> + qcom,board-id = <0xb64 0>;
>>>
>>> Please work with sboyd to add the board-id to the dtbTool. We don't put
>>> board-ids in the dts file. We post-process the dtb file and add them then.
>>>
>>
>> sboyd has all the info he needs for this, I believe its just with legal
>> now. Will remove for V2.
>
> I've pushed out an update for dtbtool to have these msm ids.
>
>>
>>>> +
>>>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>>>> +#include <dt-bindings/clock/qcom,gcc-msm8994.h>
>>>> +
>>>> +/ {
>>>> + model = "Qualcomm Technologies, Inc. MSM 8992";
>>>> + compatible = "qcom,msm8992";
>>>> + qcom,msm-id = <251 0>, <252 0>;
>>
>> This is needed or else the LK provides the following error
>>
>> [5380] qcom,msm-id entry not found
>>
>> and refuses to boot.
>>
>>
>>>> + qcom,pmic-id = <0x10009 0x1000A 0x0 0x0>;
>>>
>>> See above comment on ids.
>>
>> removal of this (pmic-id) seems to be ok.
>>
>
> Having the msm ids (and the pmic ids) in dtbtool isn't going to help
> here though. I believe the bootloader on these devices uses a design of
> appended dtbs where each dtb has the qcom,{msm-id,board-id,pmic-id}
> properties in them. The QCDT "header" that dtbtool generates is not
> used.
>
> To fix that problem we'll need to update dtbtool to inject these
> properties into the dtbs based on the compatible strings. Or get
> maintainers to accept that these ids are now necessary for proper
> functionality.
I will try modifying the tool to inject these values to understand
how easy and/or complicated it will be. This topic will be raised
during plumbers as most people will be there.
>
> Furthermore, the value of board-id (0xb64) is concerning. qcom only
> supports a certain set of values there for their boards, but vendors are
> free to do whatever they want with that value. This means they can reuse
> existing values that would map to qcom's concept of the "mtp" or "cdp"
> boards, or they can numbers that would alias with other vendors.
> Thankfully, msm-id and pmic-id are values that are under qcom's control,
> so those are always going to be unique and sane. Really all that could
> alias is board-id.
>
> What does this all mean? We can't support non-qcom boards in the same
> boot.img because of the possibility for the board-id property to alias
> between different dtbs. Or at least dtbtool will have to do some alias
> analysis and eject one aliasing dtbs from the blob. It also means that
> we have a lot of work to do in dtbtool to inject these properties based
> on strings, and to have custom parsers for different vendor prefixes so
> that we know what values to inject (the nightmare is growing).
>
This provides a reasonably compelling argument that can be discussed
with the device tree maintainers during Plumbers.
> I've asked the bootloader folks to fix this in future platforms so that
> we match based on the compatible string, instead of having to do any
> post processing. Basically, put dtbtool logic into the bootloader. The
> discussion is still on-going, but I'm hopeful that we don't need to keep
> doing things here with post-processing and the headache will be reduced.
> That could totally backfire though if vendors decide to leave the
> bootloader unchanged and boot the "qcom,msm8992-mtp" dtb that's been
> slightly tweaked for their design. Let's hope that doesn't happen.
>
Thank you for pushing this internally as it will definitely aid in the
mainline support going forward.
-jeremy
^ permalink raw reply
* [PATCH 0/2] i2c: meson: add gxbb compatible string
From: Wolfram Sang @ 2016-09-23 23:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKi9Dk5-nF9xFD-89TTUinaGjMv5s1=N2b-Xyu98b+S3w@mail.gmail.com>
> > I intentionally don't ask people to send me the patches squashed. So,
> > you will have them seperate in patchwork et al. I only squash them just
> > before commiting to my tree. That's because I found that when digging
> > through git history, it is much more convenient to have all the
> > information in one commit.
>
> If git history was the only thing that mattered, then that would be
> fine. But it is not. Maintainers should apply what's on the list.
> Period.
Huh? If you would *ask* me to stop squashing, I am listening to reasons.
If you want to force arbitrary rules on me, I am not. There are reasons
where squashing/modifying patches makes more sense compared to forcing
the author to resend. DTS bindings may not be one, we can discuss that.
But that rule without allowing exceptions seems impractical to me.
-------------- 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/20160924/8e01fc6e/attachment.sig>
^ permalink raw reply
* [PATCH 0/2] i2c: meson: add gxbb compatible string
From: Rob Herring @ 2016-09-23 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923221312.GA5683@katana>
On Fri, Sep 23, 2016 at 5:13 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Fri, Sep 23, 2016 at 10:01:13AM -0500, Rob Herring wrote:
>> On Thu, Sep 15, 2016 at 2:41 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>> > On Wed, Sep 14, 2016 at 11:49:15AM +0200, Jerome Brunet wrote:
>> >> This patchset adds a specific compatible string in the Meson I2C driver
>> >> for the Amlogic Meson gxbb SoC.
>> >>
>> >> Other patch series (pinctrl and device tree) are being sent to complete
>> >> the i2c support on meson gxbb
>> >>
>> >> Neil Armstrong (2):
>> >> i2c: meson: add gxbb compatible string
>> >> dt-bindings: i2c-meson: add gxbb compatible string
>> >
>> > Squashed both patches and applied to for-next, thanks!
>>
>> Please don't squash. We ask people to split DT bindings for a reason
>> being reviews and bindings may not go thru subsystem maintainers in
>> the future. It also makes it harder to find things in the archives or
>> patchwork (as does maintainer fixups of subject lines).
>
> I intentionally don't ask people to send me the patches squashed. So,
> you will have them seperate in patchwork et al. I only squash them just
> before commiting to my tree. That's because I found that when digging
> through git history, it is much more convenient to have all the
> information in one commit.
If git history was the only thing that mattered, then that would be
fine. But it is not. Maintainers should apply what's on the list.
Period. You wouldn't fixup pull requests to make the commit history
more to your liking, would you?
Rob
^ permalink raw reply
* [PATCH v4] devicetree: bindings: uart: Add new compatible string for ZynqMP
From: Rob Herring @ 2016-09-23 22:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474629948-9780-1-git-send-email-navam@xilinx.com>
On Fri, Sep 23, 2016 at 04:55:48PM +0530, Nava kishore Manne wrote:
> From: Nava kishore Manne <nava.manne@xilinx.com>
>
> This patch Adds the new compatible string for ZynqMP.
>
> Signed-off-by: Nava kishore Manne <navam@xilinx.com>
> ---
> Changes for v4:
> -Modified the ChangeLog comment.
> Changes for v3:
> -Added changeLog comment.
> Changes for v2:
> -None
>
> Documentation/devicetree/bindings/serial/cdns,uart.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.txt b/Documentation/devicetree/bindings/serial/cdns,uart.txt
> index a3eb154..4fe7aae 100644
> --- a/Documentation/devicetree/bindings/serial/cdns,uart.txt
> +++ b/Documentation/devicetree/bindings/serial/cdns,uart.txt
> @@ -1,7 +1,8 @@
> Binding for Cadence UART Controller
>
> Required properties:
> -- compatible : should be "cdns,uart-r1p8", or "xlnx,xuartps"
> +- compatible : should be "cdns,uart-r1p8", or "xlnx,xuartps" for Zynq and
> + "cdns,uart-r1p12" for Zynq Ultrascale+ MPSoC uart controller.
Please format this as one valid combination per line.
xuartps is not very specific. It needs some abbreviation of "Zynq
Ultrascale+ MPSoC" in it.
> - reg: Should contain UART controller registers location and length.
> - interrupts: Should contain UART controller interrupts.
> - clocks: Must contain phandles to the UART clocks
> --
> 2.1.2
>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: add bindings doc for ZTE VOU display controller
From: Rob Herring @ 2016-09-23 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474615449-16893-1-git-send-email-shawn.guo@linaro.org>
On Fri, Sep 23, 2016 at 03:24:08PM +0800, Shawn Guo wrote:
> It adds initial bindings doc for ZTE VOU display controller. HDMI is
> the only supported output device right now.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> .../devicetree/bindings/display/zte,vou.txt | 67 ++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/zte,vou.txt
>
> diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt b/Documentation/devicetree/bindings/display/zte,vou.txt
> new file mode 100644
> index 000000000000..b7407219cfa1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/zte,vou.txt
> @@ -0,0 +1,67 @@
> +ZTE VOU Display Controller
> +
> +This is a display controller found on ZTE ZX296718 SoC. It includes multiple
> +Graphic Layer (GL) and Video Layer (VL), two Mixers/Channels, and a few blocks
> +handling scaling, color space conversion etc. VOU also integrates the support
> +for typical output devices, like HDMI, TV Encoder, VGA, and RGB LCD.
> +
> +* Master display-subsystem node
> +
> +It must be the parent node of all the sub-device nodes.
> +
> +Required properties:
> + - compatible: should be "zte,zx-display-subsystem"
> + - #address-cells: should be <1>
> + - #size-cells: should be <1>
> + - ranges: to allow probing of sub-devices
> +
> +* VOU controller device
> +
> +Required properties:
> + - compatible: should be "zte,zx296718-vou"
> + - reg: Physical base address and length of the whole VOU IO region
> + - interrupts: VOU interrupt number to the CPU
> + - clocks: A list of phandle + clock-specifier pairs, one for each entry
> + in 'clock-names'
> + - clock-names: A list of clock names. It should contain: "aclk", "ppu_wclk",
> + "main_wclk" and "aux_wclk".
> +
> +* HDMI output device
> +
> +Required properties:
> + - compatible: should be "zte,zx296718-hdmi"
> + - reg: Physical base address and length of the HDMI device IO region
> + - interrupts : HDMI interrupt number to the CPU
> + - clocks: A list of phandle + clock-specifier pairs, one for each entry
> + in 'clock-names'
> + - clock-names: A list of clock names. It should contain: "osc_cec", "osc_clk"
> + and "xclk".
> +
> +Example:
> +
> +display-subsystem {
> + compatible = "zte,zx-display-subsystem";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + vou: vou at 1440000 {
> + compatible = "zte,zx296718-vou";
> + reg = <0x1440000 0x10000>;
> + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&topcrm VOU_ACLK>, <&topcrm VOU_PPU_WCLK>,
> + <&topcrm VOU_MAIN_WCLK>, <&topcrm VOU_AUX_WCLK>;
> + clock-names = "aclk", "ppu_wclk",
> + "main_wclk", "aux_wclk";
> + };
> +
> + hdmi: hdmi at 144c000 {
> + compatible = "zte,zx296718-hdmi";
> + reg = <0x144c000 0x4000>;
You have overlapping regions here. I'd suggest you kill off
zte,zx-display-subsystem and make zte,zx296718-vou the top-level node
with hdmi and others as the child nodes.
> + interrupts = <GIC_SPI 82 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&topcrm HDMI_OSC_CEC>,
> + <&topcrm HDMI_OSC_CLK>,
> + <&topcrm HDMI_XCLK>;
> + clock-names = "osc_cec", "osc_clk", "xclk";
> + };
> +};
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v3 4/4] regulator: axp20x: add the AXP813
From: Rob Herring @ 2016-09-23 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21ac1fd8ab33185ec2cdb436272f48571695ce54.1474621108.git.moinejf@free.fr>
On Fri, Sep 23, 2016 at 09:22:41AM +0200, Jean-Francois Moine wrote:
> The X-Powers AXP813 PMIC is close to the AXP803.
> It is used in some Allwinner boards as the Sinovoip BananaPi M3+.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> Documentation/devicetree/bindings/mfd/axp20x.txt | 9 +-
> drivers/mfd/axp20x.c | 2 +
> drivers/regulator/Makefile | 2 +-
> drivers/regulator/axp813.c | 229 +++++++++++++++++++++++
> include/linux/mfd/axp20x.h | 1 +
> 5 files changed, 239 insertions(+), 4 deletions(-)
> create mode 100644 drivers/regulator/axp813.c
>
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 3332d02..62019fb 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -8,11 +8,12 @@ axp221 (X-Powers)
> axp223 (X-Powers)
> axp803 (X-Powers)
> axp809 (X-Powers)
> +axp813 (X-Powers)
>
> Required properties:
> - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
> "x-powers,axp221", "x-powers,axp223", "x-powers,axp803",
> - "x-powers,axp806", "x-powers,axp809"
> + "x-powers,axp806", "x-powers,axp809", "x-powers,axp813"
Same comment here.
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 3/4] regulator: axp20x: add the AXP803
From: Rob Herring @ 2016-09-23 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c9e5c21df09a1feb1b00aa000c3c0f77e51eac3.1474621107.git.moinejf@free.fr>
On Fri, Sep 23, 2016 at 09:00:42AM +0200, Jean-Francois Moine wrote:
> The X-Powers AXP803 PMIC is close to the AXP809 with more outputs.
> It is used in some Allwinner boards as the Sinovoip BananaPi M64
> and the Pine A64.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> not tested
> ---
> Documentation/devicetree/bindings/mfd/axp20x.txt | 32 +++-
> drivers/mfd/axp20x.c | 13 ++
> drivers/regulator/Makefile | 3 +-
> drivers/regulator/axp803.c | 225 +++++++++++++++++++++++
> include/linux/mfd/axp20x.h | 1 +
> 5 files changed, 271 insertions(+), 3 deletions(-)
> create mode 100644 drivers/regulator/axp803.c
>
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 8f3ad9a..3332d02 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -6,12 +6,13 @@ axp202 (X-Powers)
> axp209 (X-Powers)
> axp221 (X-Powers)
> axp223 (X-Powers)
> +axp803 (X-Powers)
> axp809 (X-Powers)
>
> Required properties:
> - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
> - "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
> - "x-powers,axp809"
> + "x-powers,axp221", "x-powers,axp223", "x-powers,axp803",
> + "x-powers,axp806", "x-powers,axp809"
If you respin this, please reformat this to one per line.
Acked-by: Rob Herring <robh@kernel.org>
> - reg: The I2C slave address or RSB hardware address for the AXP chip
> - interrupt-parent: The parent interrupt controller
> - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
> @@ -86,6 +87,33 @@ LDO_IO1 : LDO : ips-supply : GPIO 1
> RTC_LDO : LDO : ips-supply : always on
> DRIVEVBUS : Enable output : drivevbus-supply : external regulator
>
> +AXP803 regulators, type, and corresponding input supply names:
> +
> +Regulator Type Supply Name Notes
> +--------- ---- ----------- -----
> +DCDC1 : DC-DC buck : vin1-supply
> +DCDC2 : DC-DC buck : vin2-supply
> +DCDC3 : DC-DC buck : vin3-supply
> +DCDC4 : DC-DC buck : vin4-supply
> +DCDC5 : DC-DC buck : vin5-supply
> +DCDC6 : DC-DC buck : vin6-supply
> +ALDO1 : LDO : aldoin-supply : shared supply
> +ALDO2 : LDO : aldoin-supply : shared supply
> +ALDO3 : LDO : aldoin-supply : shared supply
> +DLDO1 : LDO : dldoin-supply : shared supply
> +DLDO2 : LDO : dldoin-supply : shared supply
> +DLDO3 : LDO : dldoin-supply : shared supply
> +DLDO4 : LDO : dldoin-supply : shared supply
> +ELDO1 : LDO : eldoin-supply : shared supply
> +ELDO2 : LDO : eldoin-supply : shared supply
> +ELDO3 : LDO : eldoin-supply : shared supply
> +FLDO1 : LDO : fldoin-supply : shared supply
> +FLDO2 : LDO : fldoin-supply : shared supply
> +RTC_LDO : LDO : ips-supply : always on
> +LDO_IO0 : LDO : ips-supply : GPIO 0
> +LDO_IO1 : LDO : ips-supply : GPIO 1
> +DC1SW : On/Off Switch : : DCDC1 secondary output
> +
> AXP806 regulators, type, and corresponding input supply names:
>
> Regulator Type Supply Name Notes
^ permalink raw reply
* [PATCH 0/2] i2c: meson: add gxbb compatible string
From: Wolfram Sang @ 2016-09-23 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKNFzo6RWJO5WOvsyO3e4UTo5Zn48aaDac=+uL_CQWerQ@mail.gmail.com>
On Fri, Sep 23, 2016 at 10:01:13AM -0500, Rob Herring wrote:
> On Thu, Sep 15, 2016 at 2:41 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> > On Wed, Sep 14, 2016 at 11:49:15AM +0200, Jerome Brunet wrote:
> >> This patchset adds a specific compatible string in the Meson I2C driver
> >> for the Amlogic Meson gxbb SoC.
> >>
> >> Other patch series (pinctrl and device tree) are being sent to complete
> >> the i2c support on meson gxbb
> >>
> >> Neil Armstrong (2):
> >> i2c: meson: add gxbb compatible string
> >> dt-bindings: i2c-meson: add gxbb compatible string
> >
> > Squashed both patches and applied to for-next, thanks!
>
> Please don't squash. We ask people to split DT bindings for a reason
> being reviews and bindings may not go thru subsystem maintainers in
> the future. It also makes it harder to find things in the archives or
> patchwork (as does maintainer fixups of subject lines).
I intentionally don't ask people to send me the patches squashed. So,
you will have them seperate in patchwork et al. I only squash them just
before commiting to my tree. That's because I found that when digging
through git history, it is much more convenient to have all the
information in one commit.
-------------- 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/20160924/4c831195/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] clk: imx6: Fix procedure to switch the parent of LDB_DI_CLK
From: Fabio Estevam @ 2016-09-23 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474036587-13819-3-git-send-email-fabio.estevam@nxp.com>
Hi Stephen,
On Fri, Sep 16, 2016 at 11:36 AM, Fabio Estevam <fabio.estevam@nxp.com> wrote:
> Due to incorrect placement of the clock gate cell in the ldb_di[x]_clk
> tree, the glitchy parent mux of ldb_di[x]_clk can cause a glitch to
> enter the ldb_di_ipu_div divider. If the divider gets locked up, no
> ldb_di[x]_clk is generated, and the LVDS display will hang when the
> ipu_di_clk is sourced from ldb_di_clk.
>
> To fix the problem, both the new and current parent of the ldb_di_clk
> should be disabled before the switch. This patch ensures that correct
> steps are followed when ldb_di_clk parent is switched in the beginning
> of boot. The glitchy muxes are then registered as read-only. The clock
> parent can be selected using the assigned-clocks and
> assigned-clock-parents properties of the ccm device tree node:
>
> &clks {
> assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
> <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
> assigned-clock-parents = <&clks IMX6QDL_CLK_MMDC_CH1_AXI>,
> <&clks IMX6QDL_CLK_PLL5_VIDEO_DIV>;
> };
>
> The issue is explained in detail in EB821 ("LDB Clock Switch Procedure &
> i.MX6 Asynchronous Clock Switching Guidelines") [1].
>
> [1] http://www.nxp.com/files/32bit/doc/eng_bulletin/EB821.pdf
>
> Signed-off-by: Ranjani Vaidyanathan <Ranjani.Vaidyanathan@nxp.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> Reviewed-by: Akshay Bhat <akshay.bhat@timesys.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> Tested-by: Charles Kang <Charles.Kang@advantech.com.tw>
> Acked-by: Shawn Guo <shawnguo@kernel.org>
Do you think this one could be applied to clk-next? It fixes an
important LVDS bug.
Thanks
^ permalink raw reply
* [PATCH v3 3/3] clk: mvebu: migrate CP110 system controller to clk_hw API and registration
From: Stephen Boyd @ 2016-09-23 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKfDrtDDMPi4oBmpNN_+b4mvG6cVnZT7pNTo8tcNUyzwyA@mail.gmail.com>
On 09/24, Marcin Wojtas wrote:
> Hi Stephen,
>
> 2016-09-23 23:47 GMT+02:00 Stephen Boyd <sboyd@codeaurora.org>:
> > On 09/21, Marcin Wojtas wrote:
> >> @@ -203,80 +202,75 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
> >> if (ret)
> >> return ret;
> >>
> >> - cp110_clks = devm_kcalloc(&pdev->dev, sizeof(struct clk *),
> >> - CP110_CLK_NUM, GFP_KERNEL);
> >> - if (!cp110_clks)
> >> - return -ENOMEM;
> >> -
> >> - cp110_clk_data = devm_kzalloc(&pdev->dev,
> >> - sizeof(*cp110_clk_data),
> >> + cp110_clk_data = devm_kcalloc(&pdev->dev, sizeof(*cp110_clk_data),
> >> + sizeof(struct clk_hw *) * CP110_CLK_NUM,
> >> GFP_KERNEL);
> >
> > This doesn't look right. Why are calloc()ing clk_hw_onecell_data this
> > way?
>
> After some time, at a first sight it seems I should've used following:
> cp110_clk_data = devm_kzalloc(&pdev->dev, sizeof(*cp110_clk_data) +
> sizeof(struct
> clk_hw *) * CP110_CLK_NUM,
> GFP_KERNEL);
>
> I'll re-check, but is that what you meant?
Yes that looks better.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 3/3] clk: mvebu: migrate CP110 system controller to clk_hw API and registration
From: Marcin Wojtas @ 2016-09-23 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923214730.GF21232@codeaurora.org>
Hi Stephen,
2016-09-23 23:47 GMT+02:00 Stephen Boyd <sboyd@codeaurora.org>:
> On 09/21, Marcin Wojtas wrote:
>> @@ -203,80 +202,75 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
>> if (ret)
>> return ret;
>>
>> - cp110_clks = devm_kcalloc(&pdev->dev, sizeof(struct clk *),
>> - CP110_CLK_NUM, GFP_KERNEL);
>> - if (!cp110_clks)
>> - return -ENOMEM;
>> -
>> - cp110_clk_data = devm_kzalloc(&pdev->dev,
>> - sizeof(*cp110_clk_data),
>> + cp110_clk_data = devm_kcalloc(&pdev->dev, sizeof(*cp110_clk_data),
>> + sizeof(struct clk_hw *) * CP110_CLK_NUM,
>> GFP_KERNEL);
>
> This doesn't look right. Why are calloc()ing clk_hw_onecell_data this
> way?
After some time, at a first sight it seems I should've used following:
cp110_clk_data = devm_kzalloc(&pdev->dev, sizeof(*cp110_clk_data) +
sizeof(struct
clk_hw *) * CP110_CLK_NUM,
GFP_KERNEL);
I'll re-check, but is that what you meant?
Best regards,
Marcin
^ permalink raw reply
* [PATCH v3 3/3] clk: mvebu: migrate CP110 system controller to clk_hw API and registration
From: Stephen Boyd @ 2016-09-23 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474448759-24482-4-git-send-email-mw@semihalf.com>
On 09/21, Marcin Wojtas wrote:
> @@ -203,80 +202,75 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - cp110_clks = devm_kcalloc(&pdev->dev, sizeof(struct clk *),
> - CP110_CLK_NUM, GFP_KERNEL);
> - if (!cp110_clks)
> - return -ENOMEM;
> -
> - cp110_clk_data = devm_kzalloc(&pdev->dev,
> - sizeof(*cp110_clk_data),
> + cp110_clk_data = devm_kcalloc(&pdev->dev, sizeof(*cp110_clk_data),
> + sizeof(struct clk_hw *) * CP110_CLK_NUM,
> GFP_KERNEL);
This doesn't look right. Why are calloc()ing clk_hw_onecell_data this
way?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 2/3] clk: mvebu: dynamically allocate resources in Armada CP110 system controller
From: Stephen Boyd @ 2016-09-23 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474448759-24482-3-git-send-email-mw@semihalf.com>
On 09/21, Marcin Wojtas wrote:
> Original commit, which added support for Armada CP110 system controller
> used global variables for storing all clock information. It worked
> fine for Armada 7k SoC, with single CP110 block. After dual-CP110 Armada 8k
> was introduced, the data got overwritten and corrupted.
>
> This patch fixes the issue by allocating resources dynamically in the
> driver probe and storing it as platform drvdata.
>
> Fixes: d3da3eaef7f4 ("clk: mvebu: new driver for Armada CP110 system ...")
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> CC: <stable@vger.kernel.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 1/3] clk: mvebu: fix setting unwanted flags in CP110 gate clock
From: Stephen Boyd @ 2016-09-23 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474448759-24482-2-git-send-email-mw@semihalf.com>
On 09/21, Marcin Wojtas wrote:
> Armada CP110 system controller comprises its own routine responsble
> for registering gate clocks. Among others 'flags' field in
> struct clk_init_data was not set, using a random values, which
> may cause an unpredicted behavior.
>
> This patch fixes the problem by resetting all fields of clk_init_data
> before assigning values for all gated clocks of Armada 7k/8k SoCs family.
>
> Fixes: d3da3eaef7f4 ("clk: mvebu: new driver for Armada CP110 system ...")
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> CC: <stable@vger.kernel.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: zx296718: register driver earlier with core_initcall
From: Stephen Boyd @ 2016-09-23 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474595108-15790-1-git-send-email-shawn.guo@linaro.org>
On 09/23, Shawn Guo wrote:
> Clock driver should be registered with an earlier initcall than
> module_init which is used by most of client device drivers. Otherwise,
> probing of these client drivers will likely be deferred due to that
> calls into clk API will return -EPROBE_DEFER.
>
> Deferred probing is not a problem for most subsystems, but could bring
> some side effect for particular subsystem, like display. On ZX296718
> platform, we get Linux logo and boot log lost from display device, just
> because the DRM/KMS driver gets -EPROBE_DEFER from devm_clk_get() call.
>
> Let's use core_initcall (qcom and a few other clk drivers use that) for
> driver registration to avoid those unnecessary -EPROBE_DEFER and get rid
> of the side effect with ZX296718 display system.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
Not the ideal solution but it'll do for now.
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2] ASoC: rk3399_gru_sound: fix recording pop at first attempt
From: Rob Herring @ 2016-09-23 21:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474552206-31742-1-git-send-email-zhengxing@rock-chips.com>
On Thu, Sep 22, 2016 at 09:50:06PM +0800, Xing Zheng wrote:
> From: Wonjoon Lee <woojoo.lee@samsung.com>
>
> Pop happens when mclk applied but dmic's own boot-time
This statement doesn't make sense.
> Specify dmic delay times in dt to make sure
> clocks are ready earlier than dmic working
I don't think this really belongs in DT. Seems like better control of
the init order is needed. Or why not just a fixed delay in the driver?
>
> Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v2:
> - rename dmic-delay to dmic-wakeup-delay-ms
>
> .../bindings/sound/rockchip,rk3399-gru-sound.txt | 7 +++++++
> sound/soc/rockchip/rk3399_gru_sound.c | 14 ++++++++++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
> index f19b6c8..eac91db 100644
> --- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
> +++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
> @@ -6,10 +6,17 @@ Required properties:
> connected to the codecs
> - rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs
>
> +Optional properties:
> +- dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready.
> + If this option is specified, which means it's required dmic need
> + delay for DMIC to ready so that rt5514 can avoid recording before
> + DMIC send valid data
> +
> Example:
>
> sound {
> compatible = "rockchip,rk3399-gru-sound";
> rockchip,cpu = <&i2s0>;
> rockchip,codec = <&max98357a &rt5514 &da7219>;
> + dmic-wakeup-delay-ms = <20>;
> };
> diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
> index ee06489..9ed735a 100644
> --- a/sound/soc/rockchip/rk3399_gru_sound.c
> +++ b/sound/soc/rockchip/rk3399_gru_sound.c
> @@ -38,6 +38,8 @@
>
> #define SOUND_FS 256
>
> +unsigned int rt5514_dmic_delay;
> +
> static struct snd_soc_jack rockchip_sound_jack;
>
> static const struct snd_soc_dapm_widget rockchip_dapm_widgets[] = {
> @@ -123,6 +125,9 @@ static int rockchip_sound_rt5514_hw_params(struct snd_pcm_substream *substream,
> return ret;
> }
>
> + /* Wait for DMIC stable */
> + msleep(rt5514_dmic_delay);
> +
> return 0;
> }
>
> @@ -343,6 +348,15 @@ static int rockchip_sound_probe(struct platform_device *pdev)
> return -ENODEV;
> }
>
> + /* Set DMIC delay */
> + ret = device_property_read_u32(&pdev->dev, "dmic-delay",
Obviously, this doesn't work now...
> + &rt5514_dmic_delay);
> + if (ret) {
> + rt5514_dmic_delay = 0;
> + dev_dbg(&pdev->dev,
> + "no optional property 'dmic-delay' found, default: no delay\n");
> + }
> +
> rockchip_dailinks[DAILINK_RT5514_DSP].cpu_name = kstrdup_const(dev_name(dev), GFP_KERNEL);
> rockchip_dailinks[DAILINK_RT5514_DSP].cpu_dai_name = kstrdup_const(dev_name(dev), GFP_KERNEL);
> rockchip_dailinks[DAILINK_RT5514_DSP].platform_name = kstrdup_const(dev_name(dev), GFP_KERNEL);
> --
> 1.9.1
>
>
^ permalink raw reply
* [PATCH] [media] VPU: mediatek: Fix return value in case of error
From: Christophe JAILLET @ 2016-09-23 21:19 UTC (permalink / raw)
To: linux-arm-kernel
If 'dma_alloc_coherent()' returns NULL, 'vpu_alloc_ext_mem()' will
return 0 which means success.
Return -ENOMEM instead.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/media/platform/mtk-vpu/mtk_vpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c
index c9bf58c97878..3edb5ed852e6 100644
--- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -674,7 +674,7 @@ static int vpu_alloc_ext_mem(struct mtk_vpu *vpu, u32 fw_type)
GFP_KERNEL);
if (!vpu->extmem[fw_type].va) {
dev_err(dev, "Failed to allocate the extended program memory\n");
- return PTR_ERR(vpu->extmem[fw_type].va);
+ return -ENOMEM;
}
/* Disable extend0. Enable extend1 */
--
2.7.4
^ permalink raw reply related
* Regression in next with "mfd: twl6040: The chip does not support bulk access"
From: Santosh Shilimkar @ 2016-09-23 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <663a8a97-f01f-ce10-b0c6-c1a5ca0f11d2@ti.com>
On 9/23/2016 12:05 PM, Peter Ujfalusi wrote:
> On 09/23/2016 06:24 PM, Santosh Shilimkar wrote:
>> On 9/23/2016 7:26 AM, Tony Lindgren wrote:
>>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [160923 00:21]:
>>>> On 09/22/16 21:07, Tony Lindgren wrote:
>>
>> [...]
>>
>>>> On which linux-next version you are seeing this?
>>>
>>> This was with next-20160922. But testing it again this is just another
>>> regression caused by "softirq: fix tasklet_kill() and its users", so adding
>>> Santosh to Cc.
>>>
>>> So no need to revert $subject patch.
>>>
>> So your driver also looks like fiddling with tasklet core structures if
>> you got impacted because of the core change.
>
> How is that? None of the drivers in the twl6040 stack uses tasklets
> explicitly. The core uses regmap_irq and the drivers use threaded irq when
> they need interrupt handling, but no tasklet, no fiddling with internals.
>
May be MFD core or some up dependency for this driver does that.
If not then you shouldn't be impacted because of the change.
Regards,
Santosh
^ permalink raw reply
* [PATCH 3/3] ARM: pxa: em-x270: use the new pxa_camera platform_data
From: Robert Jarzmik @ 2016-09-23 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474662654-23263-1-git-send-email-robert.jarzmik@free.fr>
pxa_camera has transitioned from a soc_camera driver to a standalone
v4l2 driver. Amend the device declaration accordingly.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/em-x270.c | 85 ++++++++++++++-------------------------------
1 file changed, 27 insertions(+), 58 deletions(-)
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index 03354c21e1f2..2d7762ab1d70 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -34,8 +34,6 @@
#include <linux/i2c/pxa-i2c.h>
#include <linux/regulator/userspace-consumer.h>
-#include <media/soc_camera.h>
-
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -969,81 +967,52 @@ static int em_x270_sensor_init(void)
return ret;
gpio_direction_output(cam_reset, 0);
-
- em_x270_camera_ldo = regulator_get(NULL, "vcc cam");
- if (em_x270_camera_ldo == NULL) {
- gpio_free(cam_reset);
- return -ENODEV;
- }
-
- ret = regulator_enable(em_x270_camera_ldo);
- if (ret) {
- regulator_put(em_x270_camera_ldo);
- gpio_free(cam_reset);
- return ret;
- }
-
gpio_set_value(cam_reset, 1);
return 0;
}
-struct pxacamera_platform_data em_x270_camera_platform_data = {
- .flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
- PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
- .mclk_10khz = 2600,
+static struct regulator_consumer_supply camera_dummy_supplies[] = {
+ REGULATOR_SUPPLY("vdd", "0-005d"),
};
-static int em_x270_sensor_power(struct device *dev, int on)
-{
- int ret;
- int is_on = regulator_is_enabled(em_x270_camera_ldo);
-
- if (on == is_on)
- return 0;
-
- gpio_set_value(cam_reset, !on);
-
- if (on)
- ret = regulator_enable(em_x270_camera_ldo);
- else
- ret = regulator_disable(em_x270_camera_ldo);
-
- if (ret)
- return ret;
-
- gpio_set_value(cam_reset, on);
-
- return 0;
-}
-
-static struct i2c_board_info em_x270_i2c_cam_info[] = {
- {
- I2C_BOARD_INFO("mt9m111", 0x48),
+static struct regulator_init_data camera_dummy_initdata = {
+ .consumer_supplies = camera_dummy_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(camera_dummy_supplies),
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
},
};
-static struct soc_camera_link iclink = {
- .bus_id = 0,
- .power = em_x270_sensor_power,
- .board_info = &em_x270_i2c_cam_info[0],
- .i2c_adapter_id = 0,
+static struct fixed_voltage_config camera_dummy_config = {
+ .supply_name = "camera_vdd",
+ .input_supply = "vcc cam",
+ .microvolts = 2800000,
+ .gpio = GPIO56_MT9M111_nOE,
+ .enable_high = 0,
+ .init_data = &camera_dummy_initdata,
};
-static struct platform_device em_x270_camera = {
- .name = "soc-camera-pdrv",
- .id = -1,
+static struct platform_device camera_supply_dummy_device = {
+ .name = "reg-fixed-voltage",
+ .id = 1,
.dev = {
- .platform_data = &iclink,
+ .platform_data = &camera_dummy_config,
},
};
+struct pxacamera_platform_data em_x270_camera_platform_data = {
+ .flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
+ PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
+ .mclk_10khz = 2600,
+ .sensor_i2c_adapter_id = 0,
+ .sensor_i2c_address = 0x5d,
+};
+
static void __init em_x270_init_camera(void)
{
- if (em_x270_sensor_init() == 0) {
+ if (em_x270_sensor_init() == 0)
pxa_set_camera_info(&em_x270_camera_platform_data);
- platform_device_register(&em_x270_camera);
- }
}
#else
static inline void em_x270_init_camera(void) {}
--
2.1.4
^ permalink raw reply related
* [PATCH 2/3] ARM: pxa: ezx: use the new pxa_camera platform_data
From: Robert Jarzmik @ 2016-09-23 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474662654-23263-1-git-send-email-robert.jarzmik@free.fr>
pxa_camera has transitioned from a soc_camera driver to a standalone
v4l2 driver. Amend the device declaration accordingly.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/ezx.c | 176 ++++++++++++++++++++----------------------------
1 file changed, 72 insertions(+), 104 deletions(-)
diff --git a/arch/arm/mach-pxa/ezx.c b/arch/arm/mach-pxa/ezx.c
index 34ad0a89d4a9..0b8300e6fca3 100644
--- a/arch/arm/mach-pxa/ezx.c
+++ b/arch/arm/mach-pxa/ezx.c
@@ -17,14 +17,14 @@
#include <linux/delay.h>
#include <linux/pwm.h>
#include <linux/pwm_backlight.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
#include <linux/input.h>
#include <linux/gpio.h>
#include <linux/gpio_keys.h>
#include <linux/leds-lp3944.h>
#include <linux/i2c/pxa-i2c.h>
-#include <media/soc_camera.h>
-
#include <asm/setup.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -723,6 +723,42 @@ static struct platform_device a780_gpio_keys = {
};
/* camera */
+static struct regulator_consumer_supply camera_dummy_supplies[] = {
+ REGULATOR_SUPPLY("vdd", "0-005d"),
+};
+
+static struct regulator_init_data camera_dummy_initdata = {
+ .consumer_supplies = camera_dummy_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(camera_dummy_supplies),
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct fixed_voltage_config camera_dummy_config = {
+ .supply_name = "camera_vdd",
+ .microvolts = 2800000,
+ .gpio = GPIO50_nCAM_EN,
+ .enable_high = 0,
+ .init_data = &camera_dummy_initdata,
+};
+
+static struct platform_device camera_supply_dummy_device = {
+ .name = "reg-fixed-voltage",
+ .id = 1,
+ .dev = {
+ .platform_data = &camera_dummy_config,
+ },
+};
+static int a780_camera_reset(struct device *dev)
+{
+ gpio_set_value(GPIO19_GEN1_CAM_RST, 0);
+ msleep(10);
+ gpio_set_value(GPIO19_GEN1_CAM_RST, 1);
+
+ return 0;
+}
+
static int a780_camera_init(void)
{
int err;
@@ -731,73 +767,36 @@ static int a780_camera_init(void)
* GPIO50_nCAM_EN is active low
* GPIO19_GEN1_CAM_RST is active on rising edge
*/
- err = gpio_request(GPIO50_nCAM_EN, "nCAM_EN");
- if (err) {
- pr_err("%s: Failed to request nCAM_EN\n", __func__);
- goto fail;
- }
-
err = gpio_request(GPIO19_GEN1_CAM_RST, "CAM_RST");
if (err) {
pr_err("%s: Failed to request CAM_RST\n", __func__);
- goto fail_gpio_cam_rst;
+ return err;
}
- gpio_direction_output(GPIO50_nCAM_EN, 1);
gpio_direction_output(GPIO19_GEN1_CAM_RST, 0);
-
- return 0;
-
-fail_gpio_cam_rst:
- gpio_free(GPIO50_nCAM_EN);
-fail:
- return err;
-}
-
-static int a780_camera_power(struct device *dev, int on)
-{
- gpio_set_value(GPIO50_nCAM_EN, !on);
- return 0;
-}
-
-static int a780_camera_reset(struct device *dev)
-{
- gpio_set_value(GPIO19_GEN1_CAM_RST, 0);
- msleep(10);
- gpio_set_value(GPIO19_GEN1_CAM_RST, 1);
+ a780_camera_reset(NULL);
return 0;
}
struct pxacamera_platform_data a780_pxacamera_platform_data = {
.flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
- PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
+ PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN |
+ PXA_CAMERA_PCP,
.mclk_10khz = 5000,
+ .sensor_i2c_adapter_id = 0,
+ .sensor_i2c_address = 0x5d,
};
-static struct i2c_board_info a780_camera_i2c_board_info = {
- I2C_BOARD_INFO("mt9m111", 0x5d),
-};
-
-static struct soc_camera_link a780_iclink = {
- .bus_id = 0,
- .flags = SOCAM_SENSOR_INVERT_PCLK,
- .i2c_adapter_id = 0,
- .board_info = &a780_camera_i2c_board_info,
- .power = a780_camera_power,
- .reset = a780_camera_reset,
-};
-
-static struct platform_device a780_camera = {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &a780_iclink,
+static struct i2c_board_info a780_i2c_board_info[] = {
+ {
+ I2C_BOARD_INFO("mt9m111", 0x5d),
},
};
static struct platform_device *a780_devices[] __initdata = {
&a780_gpio_keys,
+ &camera_supply_dummy_device,
};
static void __init a780_init(void)
@@ -811,19 +810,19 @@ static void __init a780_init(void)
pxa_set_stuart_info(NULL);
pxa_set_i2c_info(NULL);
+ i2c_register_board_info(0, ARRAY_AND_SIZE(a780_i2c_board_info));
pxa_set_fb_info(NULL, &ezx_fb_info_1);
pxa_set_keypad_info(&a780_keypad_platform_data);
- if (a780_camera_init() == 0) {
+ if (a780_camera_init() == 0)
pxa_set_camera_info(&a780_pxacamera_platform_data);
- platform_device_register(&a780_camera);
- }
pwm_add_table(ezx_pwm_lookup, ARRAY_SIZE(ezx_pwm_lookup));
platform_add_devices(ARRAY_AND_SIZE(ezx_devices));
platform_add_devices(ARRAY_AND_SIZE(a780_devices));
+ regulator_has_full_constraints();
}
MACHINE_START(EZX_A780, "Motorola EZX A780")
@@ -1001,6 +1000,15 @@ static struct platform_device a910_gpio_keys = {
};
/* camera */
+static int a910_camera_reset(struct device *dev)
+{
+ gpio_set_value(GPIO28_GEN2_CAM_RST, 0);
+ msleep(10);
+ gpio_set_value(GPIO28_GEN2_CAM_RST, 1);
+
+ return 0;
+}
+
static int a910_camera_init(void)
{
int err;
@@ -1009,68 +1017,25 @@ static int a910_camera_init(void)
* GPIO50_nCAM_EN is active low
* GPIO28_GEN2_CAM_RST is active on rising edge
*/
- err = gpio_request(GPIO50_nCAM_EN, "nCAM_EN");
- if (err) {
- pr_err("%s: Failed to request nCAM_EN\n", __func__);
- goto fail;
- }
-
err = gpio_request(GPIO28_GEN2_CAM_RST, "CAM_RST");
if (err) {
pr_err("%s: Failed to request CAM_RST\n", __func__);
- goto fail_gpio_cam_rst;
+ return err;
}
- gpio_direction_output(GPIO50_nCAM_EN, 1);
gpio_direction_output(GPIO28_GEN2_CAM_RST, 0);
-
- return 0;
-
-fail_gpio_cam_rst:
- gpio_free(GPIO50_nCAM_EN);
-fail:
- return err;
-}
-
-static int a910_camera_power(struct device *dev, int on)
-{
- gpio_set_value(GPIO50_nCAM_EN, !on);
- return 0;
-}
-
-static int a910_camera_reset(struct device *dev)
-{
- gpio_set_value(GPIO28_GEN2_CAM_RST, 0);
- msleep(10);
- gpio_set_value(GPIO28_GEN2_CAM_RST, 1);
+ a910_camera_reset(NULL);
return 0;
}
struct pxacamera_platform_data a910_pxacamera_platform_data = {
.flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
- PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
+ PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN |
+ PXA_CAMERA_PCP,
.mclk_10khz = 5000,
-};
-
-static struct i2c_board_info a910_camera_i2c_board_info = {
- I2C_BOARD_INFO("mt9m111", 0x5d),
-};
-
-static struct soc_camera_link a910_iclink = {
- .bus_id = 0,
- .i2c_adapter_id = 0,
- .board_info = &a910_camera_i2c_board_info,
- .power = a910_camera_power,
- .reset = a910_camera_reset,
-};
-
-static struct platform_device a910_camera = {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &a910_iclink,
- },
+ .sensor_i2c_adapter_id = 0,
+ .sensor_i2c_address = 0x5d,
};
/* leds-lp3944 */
@@ -1122,10 +1087,14 @@ static struct i2c_board_info __initdata a910_i2c_board_info[] = {
I2C_BOARD_INFO("lp3944", 0x60),
.platform_data = &a910_lp3944_leds,
},
+ {
+ I2C_BOARD_INFO("mt9m111", 0x5d),
+ },
};
static struct platform_device *a910_devices[] __initdata = {
&a910_gpio_keys,
+ &camera_supply_dummy_device,
};
static void __init a910_init(void)
@@ -1145,14 +1114,13 @@ static void __init a910_init(void)
pxa_set_keypad_info(&a910_keypad_platform_data);
- if (a910_camera_init() == 0) {
+ if (a910_camera_init() == 0)
pxa_set_camera_info(&a910_pxacamera_platform_data);
- platform_device_register(&a910_camera);
- }
pwm_add_table(ezx_pwm_lookup, ARRAY_SIZE(ezx_pwm_lookup));
platform_add_devices(ARRAY_AND_SIZE(ezx_devices));
platform_add_devices(ARRAY_AND_SIZE(a910_devices));
+ regulator_has_full_constraints();
}
MACHINE_START(EZX_A910, "Motorola EZX A910")
--
2.1.4
^ permalink raw reply related
* [PATCH 1/3] ARM: pxa: mioa701: use the new pxa_camera platform_data
From: Robert Jarzmik @ 2016-09-23 20:30 UTC (permalink / raw)
To: linux-arm-kernel
pxa_camera has transitioned from a soc_camera driver to a standalone
v4l2 driver. Amend the device declaration accordingly.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/mioa701.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index 38a96a193dc4..8a5d0491e73c 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -57,7 +57,6 @@
#include <linux/platform_data/media/camera-pxa.h>
#include <mach/audio.h>
#include <mach/smemc.h>
-#include <media/soc_camera.h>
#include "mioa701.h"
@@ -627,6 +626,8 @@ struct pxacamera_platform_data mioa701_pxacamera_platform_data = {
.flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
.mclk_10khz = 5000,
+ .sensor_i2c_adapter_id = 0,
+ .sensor_i2c_address = 0x5d,
};
static struct i2c_board_info __initdata mioa701_pi2c_devices[] = {
@@ -643,12 +644,6 @@ static struct i2c_board_info mioa701_i2c_devices[] = {
},
};
-static struct soc_camera_link iclink = {
- .bus_id = 0, /* Match id in pxa27x_device_camera in device.c */
- .board_info = &mioa701_i2c_devices[0],
- .i2c_adapter_id = 0,
-};
-
struct i2c_pxa_platform_data i2c_pdata = {
.fast_mode = 1,
};
@@ -684,7 +679,6 @@ MIO_SIMPLE_DEV(mioa701_sound, "mioa701-wm9713", NULL)
MIO_SIMPLE_DEV(mioa701_board, "mioa701-board", NULL)
MIO_SIMPLE_DEV(wm9713_acodec, "wm9713-codec", NULL);
MIO_SIMPLE_DEV(gpio_vbus, "gpio-vbus", &gpio_vbus_data);
-MIO_SIMPLE_DEV(mioa701_camera, "soc-camera-pdrv",&iclink);
static struct platform_device *devices[] __initdata = {
&mioa701_gpio_keys,
@@ -696,7 +690,6 @@ static struct platform_device *devices[] __initdata = {
&power_dev,
&docg3,
&gpio_vbus,
- &mioa701_camera,
&mioa701_board,
};
@@ -761,6 +754,7 @@ static void __init mioa701_machine_init(void)
platform_add_devices(devices, ARRAY_SIZE(devices));
gsm_init();
+ i2c_register_board_info(0, ARRAY_AND_SIZE(mioa701_i2c_devices));
i2c_register_board_info(1, ARRAY_AND_SIZE(mioa701_pi2c_devices));
pxa_set_i2c_info(&i2c_pdata);
pxa27x_set_i2c_power_info(NULL);
@@ -769,6 +763,7 @@ static void __init mioa701_machine_init(void)
regulator_register_always_on(0, "fixed-5.0V", fixed_5v0_consumers,
ARRAY_SIZE(fixed_5v0_consumers),
5000000);
+ regulator_has_full_constraints();
}
static void mioa701_machine_exit(void)
--
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