* [PATCH V6 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Sinan Kaya @ 2016-10-26 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026214512.ofwbxnl2d46n6ef5@rob-hp-laptop>
On 10/26/2016 5:45 PM, Rob Herring wrote:
> On Wed, Oct 19, 2016 at 01:51:43PM -0400, Sinan Kaya wrote:
>> Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
>> MSI interrupts from the older revision.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> Please add acks when posting new versions.
>
Sure, sorry about that. Your acked version already got merged to Vinod's branch.
During the merge, Vinod got some merge conflicts for the remainder of the patches.
I was trying to post the remaining patches for Vinod to pick it up.
Apologies if it was not clear.
I posted V7 with only four remaining patches without the already merged
DT changes.
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 4/5] net: ethernet: bgmac: add NS2 support
From: Florian Fainelli @ 2016-10-26 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510561-17035-5-git-send-email-jon.mason@broadcom.com>
On 10/26/2016 12:36 PM, Jon Mason wrote:
> Add support for the variant of amac hardware present in the Broadcom
> Northstar2 based SoCs. Northstar2 requires an additional register to be
> configured with the port speed/duplexity (NICPM). This can be added to
> the link callback to hide it from the instances that do not use this.
> Also, the bgmac_chip_reset() was intentionally removed to prevent the
> resetting of the chip to the default values on open. Finally, clearing
> of the pending interrupts on init is required due to observed issues on
> some platforms.
>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> +static void bgmac_nicpm_speed_set(struct net_device *net_dev)
> +{
> + struct bgmac *bgmac = netdev_priv(net_dev);
> + u32 val;
> +
> + if (!bgmac->plat.nicpm_base)
> + return;
> +
> + val = NICPM_IOMUX_CTRL_INIT_VAL;
> + switch (bgmac->net_dev->phydev->speed) {
> + default:
> + pr_err("Unsupported speed. Defaulting to 1000Mb\n");
> + case SPEED_1000:
> + val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + case SPEED_100:
> + val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + case SPEED_10:
> + val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + }
> +
> + writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
> +
> + usleep_range(10, 100);
Does not seem like a good idea, do you need that sleep?
> +
> + bgmac_adjust_link(bgmac->net_dev);
> +}
> +
> static int platform_phy_connect(struct bgmac *bgmac)
> {
> struct phy_device *phy_dev;
>
> - phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
> - bgmac_adjust_link);
> + if (bgmac->plat.nicpm_base)
> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> + bgmac->dev->of_node,
> + bgmac_nicpm_speed_set);
> + else
> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> + bgmac->dev->of_node,
> + bgmac_adjust_link);
> if (!phy_dev) {
> dev_err(bgmac->dev, "Phy connect failed\n");
> return -ENODEV;
> }
>
> + if (bgmac->feature_flags & BGMAC_FEAT_LANE_SWAP)
> + phy_dev->dev_flags |= PHY_BRCM_EXP_LANE_SWAP;
> +
> return 0;
> }
>
> @@ -140,6 +188,9 @@ static int bgmac_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, bgmac);
>
> + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap"))
> + bgmac->feature_flags |= BGMAC_FEAT_LANE_SWAP;
> +
> /* Set the features of the 4707 family */
> bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
> bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
> @@ -182,6 +233,14 @@ static int bgmac_probe(struct platform_device *pdev)
> if (IS_ERR(bgmac->plat.idm_base))
> return PTR_ERR(bgmac->plat.idm_base);
>
> + regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
> + if (regs) {
> + bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
> + regs);
> + if (IS_ERR(bgmac->plat.nicpm_base))
> + return PTR_ERR(bgmac->plat.nicpm_base);
> + }
> +
> bgmac->read = platform_bgmac_read;
> bgmac->write = platform_bgmac_write;
> bgmac->idm_read = platform_bgmac_idm_read;
> @@ -213,6 +272,7 @@ static int bgmac_remove(struct platform_device *pdev)
> static const struct of_device_id bgmac_of_enet_match[] = {
> {.compatible = "brcm,amac",},
> {.compatible = "brcm,nsp-amac",},
> + {.compatible = "brcm,ns2-amac",},
> {},
> };
>
> diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
> index 38876ec..1796208 100644
> --- a/drivers/net/ethernet/broadcom/bgmac.c
> +++ b/drivers/net/ethernet/broadcom/bgmac.c
> @@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
> /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
> static void bgmac_chip_init(struct bgmac *bgmac)
> {
> + /* Clear any erroneously pending interrupts */
> + bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
> +
> /* 1 interrupt per received frame */
> bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
>
> @@ -1158,8 +1161,6 @@ static int bgmac_open(struct net_device *net_dev)
> struct bgmac *bgmac = netdev_priv(net_dev);
> int err = 0;
>
> - bgmac_chip_reset(bgmac);
> -
Is this removal intentional? Maybe it should be special cased with
checking for a NS2 BGMAC instance and not do it in that case?
--
Florian
^ permalink raw reply
* [PATCH v6 2/2] Documentation: DT: MMC: meson-gx: new bindings doc
From: Rob Herring @ 2016-10-26 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019181825.2186-2-khilman@baylibre.com>
On Wed, Oct 19, 2016 at 11:18:25AM -0700, Kevin Hilman wrote:
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> .../devicetree/bindings/mmc/amlogic,meson-gx.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH V6 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Rob Herring @ 2016-10-26 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476899512-20431-2-git-send-email-okaya@codeaurora.org>
On Wed, Oct 19, 2016 at 01:51:43PM -0400, Sinan Kaya wrote:
> Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
> MSI interrupts from the older revision.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Please add acks when posting new versions.
Rob
^ permalink raw reply
* [PATCH v2 2/9] dt-bindings: interrupt-controller: add DT binding for meson GPIO interrupt controller
From: Rob Herring @ 2016-10-26 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476890480-8884-3-git-send-email-jbrunet@baylibre.com>
On Wed, Oct 19, 2016 at 05:21:13PM +0200, Jerome Brunet wrote:
>
> This commit adds the device tree bindings description for Amlogic's GPIO
> interrupt controller available on the meson8, meson8b and gxbb SoC families
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> Rob, I did not include the Ack you gave for the RFC as bindings have slightly
> changed. Only the interrupt property has be removed following a discussion I
> had with Marc
As Mark R already said, you should keep the interrupts property.
^ permalink raw reply
* [PATCH 0/5] Minimal cpuidle fixes for omap5 and dra7
From: Tony Lindgren @ 2016-10-26 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1b6bf69-ed11-3355-323f-9d6503180310@ti.com>
* Nishanth Menon <nm@ti.com> [161026 13:57]:
> Tony,
> On 10/26/2016 10:16 AM, Tony Lindgren wrote:
> > Hi all,
> >
> > Here are some fixes to get minimal cpuidle support working with omap5
> > and dra7. Not sure if there are still some unsorted issues on enabling
> > this on dra7, but at least omap5 has been behving for me for few
> > weeks with these.
>
> I am OK with cpuidle for OMAP5, but NOT dra7. we have enabled this series of
> patches close to a couple of years back and hit quiet a few issues that do
> not have silicon resolution. CPU states lower than WFI will not work in
> cpuidle for DRA7 and has already been "descoped" from TI investigation
> charter. details of the issue remain TI internal, given that the descope was
> already done.
Hmm OK, no point adding it if not supported by hardware. I'll modify the
series for omap5 only.
> Again, OMAP5 has only had limited exposure from verification point of view -
> and all of it TI internal (unlike OMAP4 which has had production devices go
> ahead) -> at the very least, I'd link it with experimental.
Sure, this is a subset already to let's see how that works before adding
any other modes.
Regards,
Tony
^ permalink raw reply
* MAINTAINERS entry for ARM/CLKDEV SUPPORT
From: Stephen Boyd @ 2016-10-26 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026191938.GT4418@mwanda>
On 10/26/2016 12:19 PM, Dan Carpenter wrote:
> On Mon, Oct 10, 2016 at 03:18:19PM +0100, Russell King - ARM Linux wrote:
>> On Mon, Oct 10, 2016 at 05:08:10PM +0300, Dan Carpenter wrote:
>>> Hello Stephen Boyd,
>> Okay, that's really not nice.
>>
>> This is _not_ a question for Stephen. Stephen does _not_ co-maintain
>> clkdev or the clk API, but co-maintains CCF. I've no idea why you are
>> addressing this to Stephen when this is clearly a question for me to
>> answer.
>>
> Sorry, I didn't mean to offend. He's the one who deleted the clkdev.h
> file though so I thought he might know if it should still be listed or
> if it was gone for good.
>
Yes, the arm version isn't coming back. We should delete
arch/arm/include/asm/clkdev.h from the maintainers file and perhaps
replace it with the asm-generic one. But we can delete the generic file
too once blackfin removes their clkdev.h header. That patch is still
outstanding.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [rjarzmik:work/ac97 9/13] sound/arm/pxa2xx-ac97.c:34:34: error: passing argument 1 of 'pxa2xx_ac97_try_cold_reset' from incompatible pointer type
From: kbuild test robot @ 2016-10-26 21:06 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/rjarzmik/linux work/ac97
head: 223e9c527c425b1b519468e54fff9f4f82a7f390
commit: 99ed942665174ff3212a5e2353a1dc2e6df76ff9 [9/13] ASoC: pxa: switch to new ac97 bus support
config: arm-viper_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 99ed942665174ff3212a5e2353a1dc2e6df76ff9
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
sound/arm/pxa2xx-ac97.c: In function 'pxa2xx_ac97_reset':
>> sound/arm/pxa2xx-ac97.c:34:34: error: passing argument 1 of 'pxa2xx_ac97_try_cold_reset' from incompatible pointer type [-Werror=incompatible-pointer-types]
if (!pxa2xx_ac97_try_cold_reset(ac97)) {
^~~~
In file included from sound/arm/pxa2xx-ac97.c:24:0:
include/sound/pxa2xx-lib.h:31:13: note: expected 'struct ac97_controller *' but argument is of type 'struct snd_ac97 *'
extern bool pxa2xx_ac97_try_cold_reset(struct ac97_controller *adrv);
^~~~~~~~~~~~~~~~~~~~~~~~~~
>> sound/arm/pxa2xx-ac97.c:35:30: error: passing argument 1 of 'pxa2xx_ac97_try_warm_reset' from incompatible pointer type [-Werror=incompatible-pointer-types]
pxa2xx_ac97_try_warm_reset(ac97);
^~~~
In file included from sound/arm/pxa2xx-ac97.c:24:0:
include/sound/pxa2xx-lib.h:30:13: note: expected 'struct ac97_controller *' but argument is of type 'struct snd_ac97 *'
extern bool pxa2xx_ac97_try_warm_reset(struct ac97_controller *adrv);
^~~~~~~~~~~~~~~~~~~~~~~~~~
>> sound/arm/pxa2xx-ac97.c:38:27: error: passing argument 1 of 'pxa2xx_ac97_finish_reset' from incompatible pointer type [-Werror=incompatible-pointer-types]
pxa2xx_ac97_finish_reset(ac97);
^~~~
In file included from sound/arm/pxa2xx-ac97.c:24:0:
include/sound/pxa2xx-lib.h:32:13: note: expected 'struct ac97_controller *' but argument is of type 'struct snd_ac97 *'
extern void pxa2xx_ac97_finish_reset(struct ac97_controller *adrv);
^~~~~~~~~~~~~~~~~~~~~~~~
sound/arm/pxa2xx-ac97.c: At top level:
>> sound/arm/pxa2xx-ac97.c:42:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.read = pxa2xx_ac97_read,
^~~~~~~~~~~~~~~~
sound/arm/pxa2xx-ac97.c:42:10: note: (near initialization for 'pxa2xx_ac97_ops.read')
sound/arm/pxa2xx-ac97.c:43:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.write = pxa2xx_ac97_write,
^~~~~~~~~~~~~~~~~
sound/arm/pxa2xx-ac97.c:43:11: note: (near initialization for 'pxa2xx_ac97_ops.write')
cc1: some warnings being treated as errors
vim +/pxa2xx_ac97_try_cold_reset +34 sound/arm/pxa2xx-ac97.c
a09e64fb Russell King 2008-08-05 28 #include <mach/audio.h>
2c484df0 Takashi Iwai 2005-06-30 29
2c484df0 Takashi Iwai 2005-06-30 30 #include "pxa2xx-pcm.h"
2c484df0 Takashi Iwai 2005-06-30 31
d18f8376 Takashi Iwai 2005-11-17 32 static void pxa2xx_ac97_reset(struct snd_ac97 *ac97)
2c484df0 Takashi Iwai 2005-06-30 33 {
9c636342 Dmitry Eremin-Solenikov 2008-09-10 @34 if (!pxa2xx_ac97_try_cold_reset(ac97)) {
9c636342 Dmitry Eremin-Solenikov 2008-09-10 @35 pxa2xx_ac97_try_warm_reset(ac97);
2c484df0 Takashi Iwai 2005-06-30 36 }
2c484df0 Takashi Iwai 2005-06-30 37
9c636342 Dmitry Eremin-Solenikov 2008-09-10 @38 pxa2xx_ac97_finish_reset(ac97);
2c484df0 Takashi Iwai 2005-06-30 39 }
2c484df0 Takashi Iwai 2005-06-30 40
d18f8376 Takashi Iwai 2005-11-17 41 static struct snd_ac97_bus_ops pxa2xx_ac97_ops = {
2c484df0 Takashi Iwai 2005-06-30 @42 .read = pxa2xx_ac97_read,
2c484df0 Takashi Iwai 2005-06-30 43 .write = pxa2xx_ac97_write,
2c484df0 Takashi Iwai 2005-06-30 44 .reset = pxa2xx_ac97_reset,
2c484df0 Takashi Iwai 2005-06-30 45 };
:::::: The code at line 34 was first introduced by commit
:::::: 9c63634221f67450ead19820e33996b69691194f ALSA: Separate common pxa2xx-ac97 code
:::::: TO: Dmitry Baryshkov <dbaryshkov@gmail.com>
:::::: CC: Jaroslav Kysela <perex@perex.cz>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 18279 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161027/286943ab/attachment-0001.gz>
^ permalink raw reply
* [PATCH v1 1/4] dt-bindings: Document Broadcom iProc mailbox controller driver
From: Rob Herring @ 2016-10-26 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476817238-1226-2-git-send-email-jonathan.richardson@broadcom.com>
On Tue, Oct 18, 2016 at 12:00:35PM -0700, Jonathan Richardson wrote:
> Reviewed-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> Reviewed-by: Vikram Prakash <vikram.prakash@broadcom.com>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Shreesha Rajashekar <shreesha.rajashekar@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> ---
> .../bindings/mailbox/brcm,iproc-mailbox.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 0/5] Minimal cpuidle fixes for omap5 and dra7
From: Nishanth Menon @ 2016-10-26 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026151703.24730-1-tony@atomide.com>
Tony,
On 10/26/2016 10:16 AM, Tony Lindgren wrote:
> Hi all,
>
> Here are some fixes to get minimal cpuidle support working with omap5
> and dra7. Not sure if there are still some unsorted issues on enabling
> this on dra7, but at least omap5 has been behving for me for few
> weeks with these.
I am OK with cpuidle for OMAP5, but NOT dra7. we have enabled this
series of patches close to a couple of years back and hit quiet a few
issues that do not have silicon resolution. CPU states lower than WFI
will not work in cpuidle for DRA7 and has already been "descoped" from
TI investigation charter. details of the issue remain TI internal,
given that the descope was already done.
Again, OMAP5 has only had limited exposure from verification point of
view - and all of it TI internal (unlike OMAP4 which has had
production devices go ahead) -> at the very least, I'd link it with
experimental.
--
Regards,
Nishanth Menon
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Rob Herring @ 2016-10-26 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024173900.GP15620@leverpostej>
On Mon, Oct 24, 2016 at 06:39:01PM +0100, Mark Rutland wrote:
> On Fri, Oct 14, 2016 at 09:53:31AM +0200, Hans de Goede wrote:
> > Hi Rob, Mark, et al.,
>
> Hi Hans,
>
> Apologies for the delay in replying to this.
>
> I'd like to be clear that I do understand that there is a problem that
> needs to be addressed here. However, I do not believe that the *current*
> in-kernel approach is correct. More on that below.
>
> > Mark, I know that we discussed this at ELCE and you clearly indicated
> > that according to you this does not belong in the kernel. I was a bit
> > surprised by this part of the discussion.
> >
> > I had posted a RFC earlier and Rob had indicated that given that the q8
> > tablets are a special case, as my code uses actual probing rather then some
> > pre-arranged id mechanism with say an eeprom, that doing this in a
> > non-generic manner would be ok for my special case.
>
> To some extent, Rob and I may have differing views here; I'm not
> entirely sure what Rob's view is, and I cannot talk on his behalf. I
> certainly must apologise for having not commented on said RFC, however.
I've focused mainly on the bindings which I certainly had issues with
how the RFC was done. As to where this should be done, keeping all the
dirty bits in firmware/bootloader is certainly appealing. However, there
are cases where data alone can't abstract out board differences and we
need board code. Whether this is one of them, well, that is Hans' job to
convince Mark.
Rob
^ permalink raw reply
* [PATCH 1/6] dt: bindings: Add Allwinner Q8 tablets hardware manager bindings
From: Rob Herring @ 2016-10-26 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161014075337.10452-2-hdegoede@redhat.com>
On Fri, Oct 14, 2016 at 09:53:32AM +0200, Hans de Goede wrote:
> Allwinnner A13 / A23 / A33 based Q8 tablets are popular cheap 7" tablets
> of which a new batch is produced every few weeks. Each batch uses a
> different mix of touchscreen, accelerometer and wifi peripherals.
>
> Given that each batch is different creating a devicetree for each variant
> is not desirable, work is being done on a Q8 tablet hardware manager which
> auto-detects the touchscreen and accelerometer and will update the dt with
> what it has found, so that a single generic dt can be used for these tablets.
>
> This commit adds dt-bindings for this hardware manager.
>
> Note the wifi is connected to a discoverable bus (sdio or usb) and will be
> autodetected by the mmc resp. usb subsystems.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> .../misc/allwinner,sunxi-q8-hardwaremgr.txt | 71 ++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/allwinner,sunxi-q8-hardwaremgr.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/allwinner,sunxi-q8-hardwaremgr.txt b/Documentation/devicetree/bindings/misc/allwinner,sunxi-q8-hardwaremgr.txt
> new file mode 100644
> index 0000000..a81b258
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/allwinner,sunxi-q8-hardwaremgr.txt
> @@ -0,0 +1,71 @@
> +Q8 tablet hardware manager
> +--------------------------
> +
> +Allwinnner A13 / A23 / A33 based Q8 tablets are popular cheap 7" tablets of
> +which a new batch is produced every few weeks. Each batch uses a different
> +mix of touchscreen, accelerometer and wifi peripherals.
> +
> +Given that each batch is different creating a devicetree for each variant is
> +not desirable. The Q8 tablet hardware manager bindings are bindings for an os
> +module which auto-detects the touchscreen and accelerometer so that a single
> +generic dts can be used for these tablets.
> +
> +The wifi is connected to a discoverable bus and will be autodetected by the os.
> +
> +Required properties:
> + - toplevel / machine compatible, one of:
> + "allwinner,q8-a13"
> + "allwinner,q8-a23"
> + "allwinner,q8-a33"
> + - touchscreen node : There must be a template touchscreen node named
> + "touchscreen", this must be a child node of the
> + touchscreen i2c bus
> + - accelerometer node : There must be a template accelerometer node named
> + "accelerometer", this must be a child node of the
> + accelerometer i2c bus
> +
> +touchscreen node required properties:
> + - interrupt-parent : phandle pointing to the interrupt controller
> + serving the touchscreen interrupt
> + - interrupts : interrupt specification for the touchscreen interrupt
> + - power-gpios : Specification for the pin connected to the touchscreen's
> + enable / wake pin. This needs to be driven high to
> + enable the touchscreen controller
enable-gpios is the common name.
I was going to say you need to list possible compatible strings here
also. However, I now wonder if this binding doc is even needed. The
binding docs should just be the bindings for each touchscreen or
accelerometer. The fact that the node is completed at run-time whether
the bootloader or kernel doesn't matter for the binding definition. When
and it is completed is orthogonal to the binding definition.
Rob
^ permalink raw reply
* [PATCH 2/5] ARM: OMAP5: Fix mpuss_early_init
From: Tony Lindgren @ 2016-10-26 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026151703.24730-3-tony@atomide.com>
* Tony Lindgren <tony@atomide.com> [161026 08:18]:
> We need to properly initialize mpuss also on omap5 like we do on omap4.
> Otherwise we run into similar kexec problems like we had on omap4 when
> trying to kexec from a kernel with PM initialized.
...
> + else if (cpu_is_omap446x())
> startup_pa = virt_to_phys(omap4460_secondary_startup);
> + else
> + startup_pa = virt_to_phys(omap5_secondary_startup);
Here we need to check for omap5_secondary_hyp_startup too. And with
omap4 and omap5 being optional, we need to fix up things for make
randconfig builds as reported by the kbuild test robot.
Updated patch below.
Regards,
Tony
8< -----------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 25 Oct 2016 08:33:32 -0700
Subject: [PATCH] ARM: OMAP5: Fix mpuss_early_init
We need to properly initialize mpuss also on omap5 like we do on omap4.
Otherwise we run into similar kexec problems like we had on omap4 when
trying to kexec from a kernel with PM initialized.
Fixes: 0573b957fc21 ("ARM: OMAP4+: Prevent CPU1 related hang with kexec")
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/common.h | 38 +++++++++++++++++++++++--------
arch/arm/mach-omap2/io.c | 3 ++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 32 ++++++++++++++++++++------
arch/arm/mach-omap2/omap4-sar-layout.h | 2 ++
4 files changed, 58 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -262,8 +262,6 @@ extern void __iomem *omap4_get_sar_ram_base(void);
extern void omap4_mpuss_early_init(void);
extern void omap_do_wfi(void);
-extern void omap4_secondary_startup(void);
-extern void omap4460_secondary_startup(void);
#ifdef CONFIG_SMP
/* Needed for secondary core boot */
@@ -275,16 +273,11 @@ extern void omap4_cpu_die(unsigned int cpu);
extern int omap4_cpu_kill(unsigned int cpu);
extern const struct smp_operations omap4_smp_ops;
-
-extern void omap5_secondary_startup(void);
-extern void omap5_secondary_hyp_startup(void);
#endif
#if defined(CONFIG_SMP) && defined(CONFIG_PM)
extern int omap4_mpuss_init(void);
extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
-extern int omap4_finish_suspend(unsigned long cpu_state);
-extern void omap4_cpu_resume(void);
extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
@@ -305,14 +298,41 @@ static inline int omap4_mpuss_init(void)
return 0;
}
+#endif
+
+#ifdef CONFIG_ARCH_OMAP4
+void omap4_secondary_startup(void);
+void omap4460_secondary_startup(void);
+int omap4_finish_suspend(unsigned long cpu_state);
+void omap4_cpu_resume(void);
+#else
+static inline void omap4_secondary_startup(void)
+{
+}
+
+static inline void omap4460_secondary_startup(void)
+{
+}
static inline int omap4_finish_suspend(unsigned long cpu_state)
{
return 0;
}
-
static inline void omap4_cpu_resume(void)
-{}
+{
+}
+#endif
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
+void omap5_secondary_startup(void);
+void omap5_secondary_hyp_startup(void);
+#else
+static inline void omap5_secondary_startup(void)
+{
+}
+
+static inline void omap5_secondary_hyp_startup(void)
+{
+}
#endif
void pdata_quirks_init(const struct of_device_id *);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -717,10 +717,11 @@ void __init omap5_init_early(void)
OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
omap2_control_base_init();
- omap4_pm_init_early();
omap2_prcm_base_init();
omap5xxx_check_revision();
omap4_sar_ram_init();
+ omap4_mpuss_early_init();
+ omap4_pm_init_early();
omap54xx_voltagedomains_init();
omap54xx_powerdomains_init();
omap54xx_clockdomains_init();
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -48,6 +48,7 @@
#include <asm/smp_scu.h>
#include <asm/pgalloc.h>
#include <asm/suspend.h>
+#include <asm/virt.h>
#include <asm/hardware/cache-l2x0.h>
#include "soc.h"
@@ -371,8 +372,12 @@ int __init omap4_mpuss_init(void)
pm_info = &per_cpu(omap4_pm_info, 0x0);
if (sar_base) {
pm_info->scu_sar_addr = sar_base + SCU_OFFSET0;
- pm_info->wkup_sar_addr = sar_base +
- CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ if (cpu_is_omap44xx())
+ pm_info->wkup_sar_addr = sar_base +
+ CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ else
+ pm_info->wkup_sar_addr = sar_base +
+ OMAP5_CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET0;
}
pm_info->pwrdm = pwrdm_lookup("cpu0_pwrdm");
@@ -391,8 +396,12 @@ int __init omap4_mpuss_init(void)
pm_info = &per_cpu(omap4_pm_info, 0x1);
if (sar_base) {
pm_info->scu_sar_addr = sar_base + SCU_OFFSET1;
- pm_info->wkup_sar_addr = sar_base +
- CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ if (cpu_is_omap44xx())
+ pm_info->wkup_sar_addr = sar_base +
+ CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ else
+ pm_info->wkup_sar_addr = sar_base +
+ OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
}
@@ -453,15 +462,24 @@ void __init omap4_mpuss_early_init(void)
{
unsigned long startup_pa;
- if (!cpu_is_omap44xx())
+ if (!(cpu_is_omap44xx() || soc_is_omap54xx()))
return;
sar_base = omap4_get_sar_ram_base();
if (cpu_is_omap443x())
startup_pa = virt_to_phys(omap4_secondary_startup);
- else
+ else if (cpu_is_omap446x())
startup_pa = virt_to_phys(omap4460_secondary_startup);
+ else if ((__boot_cpu_mode & MODE_MASK) == HYP_MODE)
+ startup_pa = virt_to_phys(omap5_secondary_hyp_startup);
+ else
+ startup_pa = virt_to_phys(omap5_secondary_startup);
- writel_relaxed(startup_pa, sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET);
+ if (cpu_is_omap44xx())
+ writel_relaxed(startup_pa, sar_base +
+ CPU1_WAKEUP_NS_PA_ADDR_OFFSET);
+ else
+ writel_relaxed(startup_pa, sar_base +
+ OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET);
}
diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h b/arch/arm/mach-omap2/omap4-sar-layout.h
--- a/arch/arm/mach-omap2/omap4-sar-layout.h
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -31,6 +31,8 @@
/* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */
#define CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xa04
#define CPU1_WAKEUP_NS_PA_ADDR_OFFSET 0xa08
+#define OMAP5_CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xe00
+#define OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET 0xe04
#define SAR_BACKUP_STATUS_OFFSET (SAR_BANK3_OFFSET + 0x500)
#define SAR_SECURE_RAM_SIZE_OFFSET (SAR_BANK3_OFFSET + 0x504)
--
2.9.3
^ permalink raw reply
* [PATCH 2/3] ARM: convert to generated system call tables
From: Robert Jarzmik @ 2016-10-26 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVy_h6Uss9bwVK5hGD42bXeEBcBsBDwCpx_eYnT9r+=Lw@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Sat, Oct 22, 2016 at 10:23 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>>
>>> On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
>>>> What's the point of the x32 mode?
>>>
>>> On x86, the motivation is faster code for most use cases that
>>> don't need a lot of memory, as the 64-bit opcodes have 16 registers
>>> rather than 8 in 32-bit mode but 32-bit pointers have lower
>>> cache footprint than 64-bit pointers.
>>
>> For completness, the second point of x32 AFAIU is the IP-relative addressing
>> which is not available in standard 32 bit mode, which improves PIC code. For
>> simple not algorithmic code (think Android HAL for example) with many shared
>> libraries, it's better in the Hardware Abstraction Layer Libraries, instead of
>> the push-to-stack and pop register.
>
> But that's not an advantage compared to full am64 mode, right?
Nope, the amd64 (that's what you have in mind with am64, not aarch64 right ?)
mode has the IP-relative has well, so x32 has no advantage over amd64 in this
area.
x32 over amd64 advantage is cache and memory footprint AFAICT, I don't see other
benefits. There doesn't seem to be any ISA differences, or I didn't really
notice in my daily system performance analysis job.
There was a nice presentation made by Peter Anvin at a Plumber conference, here
: http://linuxplumbersconf.org/2011/ocw/sessions/531
Cheers.
--
Robert
^ permalink raw reply
* [PATCH] ARM: davinci: register the usb20_phy clock on the DT file
From: David Lechner @ 2016-10-26 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKXjFTNyNEykVn3+mxiaQionxuzrp812nfdD=9uNgrbddv939Q@mail.gmail.com>
On 10/26/2016 03:05 PM, Axel Haslam wrote:
> On Wed, Oct 26, 2016 at 10:03 PM, David Lechner <david@lechnology.com> wrote:
>> On 10/26/2016 03:01 PM, David Lechner wrote:
>>>
>>> On 10/26/2016 02:49 PM, ahaslam at baylibre.com wrote:
>>>>
>>>> From: Axel Haslam <ahaslam@baylibre.com>
>>>>
>>>> The usb20_phy clock needs to be registered for the driver to be able
>>>> to get and enable a clock. Currently the usb phy clocks are registered
>>>> form board files, which will not be called during a device tree based
>>>> boot.
>>>>
>>>> To be able to probe correctly usb form a device tree boot, register
>>>> the usb phy clocks form the DT specific init.
>>>>
>>>> Unfourtunatly, davinci does not have proper clock support on device tree
>>>> yet, so by registering the clock form de DT specific file we are
>>>> forced to hardcode the parent clock, and cannot select refclkin as
>>>> parent for any of the phy clocks of the da850 family.
>>>>
>>>> As none of the current da850 based boards currently in mainline use
>>>> refclkin as source. I guess we can live with this limitation until clocks
>>>> are correctly represented through CCF/device tree.
>>>>
>>>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
>>>> ---
>>>>
>>>> This patch depends on David's series for usb clocks:
>>>>
>>>> currently:
>>>> [PATCH v6 0/5] da8xx USB PHY platform devices and clocks
>>>> https://lkml.org/lkml/2016/10/25/867
>>>>
>>>> arch/arm/mach-davinci/da8xx-dt.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/arch/arm/mach-davinci/da8xx-dt.c
>>>> b/arch/arm/mach-davinci/da8xx-dt.c
>>>> index c9f7e92..7947267 100644
>>>> --- a/arch/arm/mach-davinci/da8xx-dt.c
>>>> +++ b/arch/arm/mach-davinci/da8xx-dt.c
>>>> @@ -45,6 +45,8 @@
>>>>
>>>> static void __init da850_init_machine(void)
>>>> {
>>>> + da8xx_register_usb20_phy_clk(false);
>>>> + da8xx_register_usb11_phy_clk(false);
>>>> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
>>>> }
>>>>
>>>>
>>>
>>>
>>> You should check for error on return and print a warning if there is an
>>> error. Like this: https://patchwork.kernel.org/patch/9395635/
>>>
>>> (I actually just had to make this change a few minutes ago to
>>> troubleshoot a problem that I am working on.
>>> da8xx_register_usb11_phy_clk() is failing for some reason that I have
>>> not figured out yet.)
>>
>>
>>
>> And actually, since my patch that provides these functions has not been
>> accepted yet, why don't I just add this change to that series?
>
> Ok, sure, if you are planing on sending another version.
>
> Regards
> Axel
>
Yes, I have some more changes to make and resubmit, so I will include
this too.
^ permalink raw reply
* [PATCH] ARM: davinci: register the usb20_phy clock on the DT file
From: Axel Haslam @ 2016-10-26 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <48fa5315-74db-cf33-1f34-86764f0e2c1c@lechnology.com>
On Wed, Oct 26, 2016 at 10:03 PM, David Lechner <david@lechnology.com> wrote:
> On 10/26/2016 03:01 PM, David Lechner wrote:
>>
>> On 10/26/2016 02:49 PM, ahaslam at baylibre.com wrote:
>>>
>>> From: Axel Haslam <ahaslam@baylibre.com>
>>>
>>> The usb20_phy clock needs to be registered for the driver to be able
>>> to get and enable a clock. Currently the usb phy clocks are registered
>>> form board files, which will not be called during a device tree based
>>> boot.
>>>
>>> To be able to probe correctly usb form a device tree boot, register
>>> the usb phy clocks form the DT specific init.
>>>
>>> Unfourtunatly, davinci does not have proper clock support on device tree
>>> yet, so by registering the clock form de DT specific file we are
>>> forced to hardcode the parent clock, and cannot select refclkin as
>>> parent for any of the phy clocks of the da850 family.
>>>
>>> As none of the current da850 based boards currently in mainline use
>>> refclkin as source. I guess we can live with this limitation until clocks
>>> are correctly represented through CCF/device tree.
>>>
>>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
>>> ---
>>>
>>> This patch depends on David's series for usb clocks:
>>>
>>> currently:
>>> [PATCH v6 0/5] da8xx USB PHY platform devices and clocks
>>> https://lkml.org/lkml/2016/10/25/867
>>>
>>> arch/arm/mach-davinci/da8xx-dt.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-davinci/da8xx-dt.c
>>> b/arch/arm/mach-davinci/da8xx-dt.c
>>> index c9f7e92..7947267 100644
>>> --- a/arch/arm/mach-davinci/da8xx-dt.c
>>> +++ b/arch/arm/mach-davinci/da8xx-dt.c
>>> @@ -45,6 +45,8 @@
>>>
>>> static void __init da850_init_machine(void)
>>> {
>>> + da8xx_register_usb20_phy_clk(false);
>>> + da8xx_register_usb11_phy_clk(false);
>>> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
>>> }
>>>
>>>
>>
>>
>> You should check for error on return and print a warning if there is an
>> error. Like this: https://patchwork.kernel.org/patch/9395635/
>>
>> (I actually just had to make this change a few minutes ago to
>> troubleshoot a problem that I am working on.
>> da8xx_register_usb11_phy_clk() is failing for some reason that I have
>> not figured out yet.)
>
>
>
> And actually, since my patch that provides these functions has not been
> accepted yet, why don't I just add this change to that series?
Ok, sure, if you are planing on sending another version.
Regards
Axel
^ permalink raw reply
* [PATCH] ARM: davinci: register the usb20_phy clock on the DT file
From: David Lechner @ 2016-10-26 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f2aeafb1-38f4-9b1e-c3fd-a2984333d00f@lechnology.com>
On 10/26/2016 03:01 PM, David Lechner wrote:
> On 10/26/2016 02:49 PM, ahaslam at baylibre.com wrote:
>> From: Axel Haslam <ahaslam@baylibre.com>
>>
>> The usb20_phy clock needs to be registered for the driver to be able
>> to get and enable a clock. Currently the usb phy clocks are registered
>> form board files, which will not be called during a device tree based
>> boot.
>>
>> To be able to probe correctly usb form a device tree boot, register
>> the usb phy clocks form the DT specific init.
>>
>> Unfourtunatly, davinci does not have proper clock support on device tree
>> yet, so by registering the clock form de DT specific file we are
>> forced to hardcode the parent clock, and cannot select refclkin as
>> parent for any of the phy clocks of the da850 family.
>>
>> As none of the current da850 based boards currently in mainline use
>> refclkin as source. I guess we can live with this limitation until clocks
>> are correctly represented through CCF/device tree.
>>
>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
>> ---
>>
>> This patch depends on David's series for usb clocks:
>>
>> currently:
>> [PATCH v6 0/5] da8xx USB PHY platform devices and clocks
>> https://lkml.org/lkml/2016/10/25/867
>>
>> arch/arm/mach-davinci/da8xx-dt.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/mach-davinci/da8xx-dt.c
>> b/arch/arm/mach-davinci/da8xx-dt.c
>> index c9f7e92..7947267 100644
>> --- a/arch/arm/mach-davinci/da8xx-dt.c
>> +++ b/arch/arm/mach-davinci/da8xx-dt.c
>> @@ -45,6 +45,8 @@
>>
>> static void __init da850_init_machine(void)
>> {
>> + da8xx_register_usb20_phy_clk(false);
>> + da8xx_register_usb11_phy_clk(false);
>> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
>> }
>>
>>
>
>
> You should check for error on return and print a warning if there is an
> error. Like this: https://patchwork.kernel.org/patch/9395635/
>
> (I actually just had to make this change a few minutes ago to
> troubleshoot a problem that I am working on.
> da8xx_register_usb11_phy_clk() is failing for some reason that I have
> not figured out yet.)
And actually, since my patch that provides these functions has not been
accepted yet, why don't I just add this change to that series?
^ permalink raw reply
* [PATCH 1/3] coresight: tmc: Cleanup operation mode handling
From: Mathieu Poirier @ 2016-10-26 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474983865-11816-1-git-send-email-suzuki.poulose@arm.com>
On 27 September 2016 at 07:44, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> The mode of operation of the TMC tracked in drvdata->mode is defined
> as a local_t type. This is always checked and modified under the
> drvdata->spinlock and hence we don't need local_t for it and the
> unnecessary synchronisation instructions that comes with it. This
> change makes the code a bit more cleaner.
>
> Also fixes the order in which we update the drvdata->mode to
> CS_MODE_DISABLED. i.e, in tmc_disable_etX_sink we change the
> mode to CS_MODE_DISABLED before invoking tmc_disable_etX_hw()
> which in turn depends on the mode to decide whether to dump the
> trace to a buffer.
>
> Applies on mathieu's coresight/next tree [1]
>
> https://git.linaro.org/kernel/coresight.git next
>
> Reported-by: Venkatesh Vivekanandan <venkatesh.vivekanandan@broadcom.com>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-tmc-etf.c | 32 +++++++++++--------------
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 26 +++++++++-----------
> drivers/hwtracing/coresight/coresight-tmc.h | 2 +-
> 3 files changed, 26 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> index d6941ea..e80a8f4 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> @@ -70,7 +70,7 @@ static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
> * When operating in sysFS mode the content of the buffer needs to be
> * read before the TMC is disabled.
> */
> - if (local_read(&drvdata->mode) == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> tmc_etb_dump_hw(drvdata);
> tmc_disable_hw(drvdata);
>
> @@ -108,7 +108,6 @@ static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev, u32 mode)
> int ret = 0;
> bool used = false;
> char *buf = NULL;
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -138,13 +137,12 @@ static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev, u32 mode)
> goto out;
> }
>
> - val = local_xchg(&drvdata->mode, mode);
> /*
> * In sysFS mode we can have multiple writers per sink. Since this
> * sink is already enabled no memory is needed and the HW need not be
> * touched.
> */
> - if (val == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> goto out;
>
> /*
> @@ -163,6 +161,7 @@ static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev, u32 mode)
> drvdata->buf = buf;
> }
>
> + drvdata->mode = CS_MODE_SYSFS;
> tmc_etb_enable_hw(drvdata);
> out:
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
> @@ -180,7 +179,6 @@ out:
> static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, u32 mode)
> {
> int ret = 0;
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -194,17 +192,17 @@ static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, u32 mode)
> goto out;
> }
>
> - val = local_xchg(&drvdata->mode, mode);
> /*
> * In Perf mode there can be only one writer per sink. There
> * is also no need to continue if the ETB/ETR is already operated
> * from sysFS.
> */
> - if (val != CS_MODE_DISABLED) {
> + if (drvdata->mode != CS_MODE_DISABLED) {
> ret = -EINVAL;
> goto out;
> }
>
> + drvdata->mode = mode;
> tmc_etb_enable_hw(drvdata);
> out:
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
> @@ -227,7 +225,6 @@ static int tmc_enable_etf_sink(struct coresight_device *csdev, u32 mode)
>
> static void tmc_disable_etf_sink(struct coresight_device *csdev)
> {
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -237,10 +234,11 @@ static void tmc_disable_etf_sink(struct coresight_device *csdev)
> return;
> }
>
> - val = local_xchg(&drvdata->mode, CS_MODE_DISABLED);
> /* Disable the TMC only if it needs to */
> - if (val != CS_MODE_DISABLED)
> + if (drvdata->mode != CS_MODE_DISABLED) {
> tmc_etb_disable_hw(drvdata);
> + drvdata->mode = CS_MODE_DISABLED;
> + }
>
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> @@ -260,7 +258,7 @@ static int tmc_enable_etf_link(struct coresight_device *csdev,
> }
>
> tmc_etf_enable_hw(drvdata);
> - local_set(&drvdata->mode, CS_MODE_SYSFS);
> + drvdata->mode = CS_MODE_SYSFS;
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> dev_info(drvdata->dev, "TMC-ETF enabled\n");
> @@ -280,7 +278,7 @@ static void tmc_disable_etf_link(struct coresight_device *csdev,
> }
>
> tmc_etf_disable_hw(drvdata);
> - local_set(&drvdata->mode, CS_MODE_DISABLED);
> + drvdata->mode = CS_MODE_DISABLED;
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> dev_info(drvdata->dev, "TMC disabled\n");
> @@ -383,7 +381,7 @@ static void tmc_update_etf_buffer(struct coresight_device *csdev,
> return;
>
> /* This shouldn't happen */
> - if (WARN_ON_ONCE(local_read(&drvdata->mode) != CS_MODE_PERF))
> + if (WARN_ON_ONCE(drvdata->mode != CS_MODE_PERF))
> return;
>
> CS_UNLOCK(drvdata->base);
> @@ -504,7 +502,6 @@ const struct coresight_ops tmc_etf_cs_ops = {
>
> int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
> {
> - long val;
> enum tmc_mode mode;
> int ret = 0;
> unsigned long flags;
> @@ -528,9 +525,8 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
> goto out;
> }
>
> - val = local_read(&drvdata->mode);
> /* Don't interfere if operated from Perf */
> - if (val == CS_MODE_PERF) {
> + if (drvdata->mode == CS_MODE_PERF) {
> ret = -EINVAL;
> goto out;
> }
> @@ -542,7 +538,7 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
> }
>
> /* Disable the TMC if need be */
> - if (val == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> tmc_etb_disable_hw(drvdata);
>
> drvdata->reading = true;
> @@ -573,7 +569,7 @@ int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata)
> }
>
> /* Re-enable the TMC if need be */
> - if (local_read(&drvdata->mode) == CS_MODE_SYSFS) {
> + if (drvdata->mode == CS_MODE_SYSFS) {
> /*
> * The trace run will continue with the same allocated trace
> * buffer. As such zero-out the buffer so that we don't end
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 886ea83..f23ef0c 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -86,7 +86,7 @@ static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
> * When operating in sysFS mode the content of the buffer needs to be
> * read before the TMC is disabled.
> */
> - if (local_read(&drvdata->mode) == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> tmc_etr_dump_hw(drvdata);
> tmc_disable_hw(drvdata);
>
> @@ -97,7 +97,6 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev, u32 mode)
> {
> int ret = 0;
> bool used = false;
> - long val;
> unsigned long flags;
> void __iomem *vaddr = NULL;
> dma_addr_t paddr;
> @@ -134,13 +133,12 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev, u32 mode)
> goto out;
> }
>
> - val = local_xchg(&drvdata->mode, mode);
> /*
> * In sysFS mode we can have multiple writers per sink. Since this
> * sink is already enabled no memory is needed and the HW need not be
> * touched.
> */
> - if (val == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> goto out;
>
> /*
> @@ -157,6 +155,7 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev, u32 mode)
>
> memset(drvdata->vaddr, 0, drvdata->size);
>
> + drvdata->mode = CS_MODE_SYSFS;
> tmc_etr_enable_hw(drvdata);
> out:
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
> @@ -174,7 +173,6 @@ out:
> static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, u32 mode)
> {
> int ret = 0;
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -188,17 +186,17 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, u32 mode)
> goto out;
> }
>
> - val = local_xchg(&drvdata->mode, mode);
> /*
> * In Perf mode there can be only one writer per sink. There
> * is also no need to continue if the ETR is already operated
> * from sysFS.
> */
> - if (val != CS_MODE_DISABLED) {
> + if (drvdata->mode != CS_MODE_DISABLED) {
> ret = -EINVAL;
> goto out;
> }
>
> + drvdata->mode = CS_MODE_PERF;
> tmc_etr_enable_hw(drvdata);
> out:
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
> @@ -221,7 +219,6 @@ static int tmc_enable_etr_sink(struct coresight_device *csdev, u32 mode)
>
> static void tmc_disable_etr_sink(struct coresight_device *csdev)
> {
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -231,10 +228,11 @@ static void tmc_disable_etr_sink(struct coresight_device *csdev)
> return;
> }
>
> - val = local_xchg(&drvdata->mode, CS_MODE_DISABLED);
> /* Disable the TMC only if it needs to */
> - if (val != CS_MODE_DISABLED)
> + if (drvdata->mode != CS_MODE_DISABLED) {
> tmc_etr_disable_hw(drvdata);
> + drvdata->mode = CS_MODE_DISABLED;
> + }
>
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> @@ -253,7 +251,6 @@ const struct coresight_ops tmc_etr_cs_ops = {
> int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
> {
> int ret = 0;
> - long val;
> unsigned long flags;
>
> /* config types are set a boot time and never change */
> @@ -266,9 +263,8 @@ int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
> goto out;
> }
>
> - val = local_read(&drvdata->mode);
> /* Don't interfere if operated from Perf */
> - if (val == CS_MODE_PERF) {
> + if (drvdata->mode == CS_MODE_PERF) {
> ret = -EINVAL;
> goto out;
> }
> @@ -280,7 +276,7 @@ int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
> }
>
> /* Disable the TMC if need be */
> - if (val == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> tmc_etr_disable_hw(drvdata);
>
> drvdata->reading = true;
> @@ -303,7 +299,7 @@ int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata)
> spin_lock_irqsave(&drvdata->spinlock, flags);
>
> /* RE-enable the TMC if need be */
> - if (local_read(&drvdata->mode) == CS_MODE_SYSFS) {
> + if (drvdata->mode == CS_MODE_SYSFS) {
> /*
> * The trace run will continue with the same allocated trace
> * buffer. The trace buffer is cleared in tmc_etr_enable_hw(),
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
> index 44b3ae3..51c0185 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.h
> +++ b/drivers/hwtracing/coresight/coresight-tmc.h
> @@ -117,7 +117,7 @@ struct tmc_drvdata {
> void __iomem *vaddr;
> u32 size;
> u32 len;
> - local_t mode;
> + u32 mode;
> enum tmc_config_type config_type;
> enum tmc_mem_intf_width memwidth;
> u32 trigger_cntr;
> --
> 2.7.4
>
I have applied all 3 patches in this set.
Thank you for the code and apologies for the delay,
Mathieu
^ permalink raw reply
* [PATCH] ARM: davinci: register the usb20_phy clock on the DT file
From: David Lechner @ 2016-10-26 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026194916.14546-1-ahaslam@baylibre.com>
On 10/26/2016 02:49 PM, ahaslam at baylibre.com wrote:
> From: Axel Haslam <ahaslam@baylibre.com>
>
> The usb20_phy clock needs to be registered for the driver to be able
> to get and enable a clock. Currently the usb phy clocks are registered
> form board files, which will not be called during a device tree based
> boot.
>
> To be able to probe correctly usb form a device tree boot, register
> the usb phy clocks form the DT specific init.
>
> Unfourtunatly, davinci does not have proper clock support on device tree
> yet, so by registering the clock form de DT specific file we are
> forced to hardcode the parent clock, and cannot select refclkin as
> parent for any of the phy clocks of the da850 family.
>
> As none of the current da850 based boards currently in mainline use
> refclkin as source. I guess we can live with this limitation until clocks
> are correctly represented through CCF/device tree.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
>
> This patch depends on David's series for usb clocks:
>
> currently:
> [PATCH v6 0/5] da8xx USB PHY platform devices and clocks
> https://lkml.org/lkml/2016/10/25/867
>
> arch/arm/mach-davinci/da8xx-dt.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index c9f7e92..7947267 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -45,6 +45,8 @@
>
> static void __init da850_init_machine(void)
> {
> + da8xx_register_usb20_phy_clk(false);
> + da8xx_register_usb11_phy_clk(false);
> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
> }
>
>
You should check for error on return and print a warning if there is an
error. Like this: https://patchwork.kernel.org/patch/9395635/
(I actually just had to make this change a few minutes ago to
troubleshoot a problem that I am working on.
da8xx_register_usb11_phy_clk() is failing for some reason that I have
not figured out yet.)
^ permalink raw reply
* [PATCH] arm64: Add support of R_AARCH64_PREL32 relocation in purgatory
From: Geoff Levand @ 2016-10-26 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0eb8a908f617e0f957df7fb3ef293596f47e6832.1477456661.git.panand@redhat.com>
On 10/25/2016 09:40 PM, Pratyush Anand wrote:
> + case R_AARCH64_PREL32:
> + type = "PREL32";
> + loc32 = ptr;
> + *loc32 = cpu_to_elf32(ehdr, elf32_to_cpu(ehdr, *loc32) + value - address);
Please keep line width less than 80 chars.
> + break;
^ permalink raw reply
* [PATCH V4 0/5] firmware: Add support for TI System Control Interface (TI-SCI) protocol driver
From: Santosh Shilimkar @ 2016-10-26 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2694e4b5-20d5-f590-c6a6-55ff4cb8c16b@ti.com>
On 10/25/2016 10:34 AM, Tero Kristo wrote:
> On 19/10/16 02:08, Nishanth Menon wrote:
>> Version 4 of the series is basically a rebase to v4.9-rc1, no functional
>> changes.
>
> Hi,
>
> Any final comments on this series, or shall I send a pull-req forward?
> Very minimal changes compared to v3 so should be good to go imo.
>
The patchset looks fine to me from brief scan so please Go from
my side at least for the pull request.
Regards,
Santosh
^ permalink raw reply
* [PATCH 0/5] Minimal cpuidle fixes for omap5 and dra7
From: Santosh Shilimkar @ 2016-10-26 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026151703.24730-1-tony@atomide.com>
On 10/26/2016 8:16 AM, Tony Lindgren wrote:
> Hi all,
>
> Here are some fixes to get minimal cpuidle support working with omap5
> and dra7. Not sure if there are still some unsorted issues on enabling
> this on dra7, but at least omap5 has been behving for me for few
> weeks with these.
>
> Regards,
>
> Tony
>
>
> Santosh Shilimkar (1):
> ARM: DRA7: PM: cpuidle MPU CSWR support
>
> Tony Lindgren (4):
> ARM: OMAP5: Fix build for PM code
> ARM: OMAP5: Fix mpuss_early_init
> ARM: OMAP4+: Fix bad fallthrough for cpuidle
> ARM: OMAP5: Enable minimal cpuidle for omap5 retention
>
Feel free to add my ack if you need one.
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
^ permalink raw reply
* [PATCH] ARM: davinci: register the usb20_phy clock on the DT file
From: ahaslam at baylibre.com @ 2016-10-26 19:49 UTC (permalink / raw)
To: linux-arm-kernel
From: Axel Haslam <ahaslam@baylibre.com>
The usb20_phy clock needs to be registered for the driver to be able
to get and enable a clock. Currently the usb phy clocks are registered
form board files, which will not be called during a device tree based
boot.
To be able to probe correctly usb form a device tree boot, register
the usb phy clocks form the DT specific init.
Unfourtunatly, davinci does not have proper clock support on device tree
yet, so by registering the clock form de DT specific file we are
forced to hardcode the parent clock, and cannot select refclkin as
parent for any of the phy clocks of the da850 family.
As none of the current da850 based boards currently in mainline use
refclkin as source. I guess we can live with this limitation until clocks
are correctly represented through CCF/device tree.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
This patch depends on David's series for usb clocks:
currently:
[PATCH v6 0/5] da8xx USB PHY platform devices and clocks
https://lkml.org/lkml/2016/10/25/867
arch/arm/mach-davinci/da8xx-dt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index c9f7e92..7947267 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -45,6 +45,8 @@
static void __init da850_init_machine(void)
{
+ da8xx_register_usb20_phy_clk(false);
+ da8xx_register_usb11_phy_clk(false);
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
}
--
1.9.1
^ permalink raw reply related
* [PATCH] ARM: davinci: Add full regulator constraints for non-DT boot
From: ahaslam at baylibre.com @ 2016-10-26 19:41 UTC (permalink / raw)
To: linux-arm-kernel
From: Axel Haslam <ahaslam@baylibre.com>
The phy framework requests an optional "phy" regulator. If it does
not find one, it returns -EPROBE_DEFER. In the case of non-DT boot
for the omap138-lcdk board, this would prevent the usb11 phy to probe
correctly and ohci would not enumerate.
By calling "regulator_has_full_constraints", An error would be returned
instead of DEFER for the regulator, and the probe of the phy driver can
continue normally without a regulator.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
This applies cleanly after David's recent patches:
[PATCH v6 0/5] da8xx USB PHY platform devices and clocks
https://lkml.org/lkml/2016/10/25/867
arch/arm/mach-davinci/board-da830-evm.c | 3 +++
arch/arm/mach-davinci/board-omapl138-hawk.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index c62766e..b33fc6b 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -26,6 +26,7 @@
#include <linux/platform_data/mtd-davinci.h>
#include <linux/platform_data/mtd-davinci-aemif.h>
#include <linux/platform_data/spi-davinci.h>
+#include <linux/regulator/machine.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -631,6 +632,8 @@ static __init void da830_evm_init(void)
ret = da8xx_register_spi_bus(0, ARRAY_SIZE(da830evm_spi_info));
if (ret)
pr_warn("%s: spi 0 registration failed: %d\n", __func__, ret);
+
+ regulator_has_full_constraints();
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index c5cb8d9..c3ab7ea 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -14,6 +14,7 @@
#include <linux/console.h>
#include <linux/gpio.h>
#include <linux/platform_data/gpio-davinci.h>
+#include <linux/regulator/machine.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -328,6 +329,8 @@ static __init void omapl138_hawk_init(void)
if (ret)
pr_warn("%s: dsp/rproc registration failed: %d\n",
__func__, ret);
+
+ regulator_has_full_constraints();
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
--
1.9.1
^ permalink raw reply related
* [PATCH 9/9] Input: wm97xx: add new AC97 bus support
From: Robert Jarzmik @ 2016-10-26 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510907-23495-1-git-send-email-robert.jarzmik@free.fr>
This adds support for the new AC97 bus code, which discovers the devices
rather than uses platform data.
As part of this discovery, it enables a multi-function device wm97xx,
which supports touchscreen, battery, ADC and an audio codec. This patch
adds the code to bind the touchscreen "cell" as the touchscreen driver.
This was tested on the pxa architecture with a pxa270 + wm9713 + the
mioa701 touchscreen.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/input/touchscreen/Kconfig | 2 +-
drivers/input/touchscreen/wm97xx-core.c | 56 ++++++++++++++++++++++++++++++++-
2 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index efca0133e266..7af06015e704 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -737,7 +737,7 @@ config TOUCHSCREEN_WM831X
config TOUCHSCREEN_WM97XX
tristate "Support for WM97xx AC97 touchscreen controllers"
- depends on AC97_BUS
+ depends on AC97_BUS || AC97_BUS_NEW
help
Say Y here if you have a Wolfson Microelectronics WM97xx
touchscreen connected to your system. Note that this option
diff --git a/drivers/input/touchscreen/wm97xx-core.c b/drivers/input/touchscreen/wm97xx-core.c
index 50a110e2988b..4d5c96a5ab04 100644
--- a/drivers/input/touchscreen/wm97xx-core.c
+++ b/drivers/input/touchscreen/wm97xx-core.c
@@ -44,6 +44,7 @@
#include <linux/pm.h>
#include <linux/interrupt.h>
#include <linux/bitops.h>
+#include <linux/mfd/wm97xx.h>
#include <linux/workqueue.h>
#include <linux/wm97xx.h>
#include <linux/uaccess.h>
@@ -763,6 +764,39 @@ static int wm97xx_remove(struct device *dev)
return 0;
}
+static int wm97xx_mfd_probe(struct platform_device *pdev)
+{
+ struct wm97xx *wm;
+ struct wm97xx_platform_data *mfd_pdata = dev_get_platdata(&pdev->dev);
+ int ret;
+
+ wm = devm_kzalloc(&pdev->dev, sizeof(struct wm97xx), GFP_KERNEL);
+ if (!wm)
+ return -ENOMEM;
+
+ wm->dev = &pdev->dev;
+ wm->ac97 = mfd_pdata->ac97;
+
+ ret = _wm97xx_probe(wm);
+ if (ret)
+ return ret;
+
+ ret = wm97xx_add_battery(wm, mfd_pdata->batt_pdata);
+ if (ret < 0)
+ goto batt_err;
+
+ return ret;
+
+batt_err:
+ wm97xx_unregister_touch(wm);
+ return ret;
+}
+
+static int wm97xx_mfd_remove(struct platform_device *pdev)
+{
+ return wm97xx_remove(&pdev->dev);
+}
+
static int __maybe_unused wm97xx_suspend(struct device *dev)
{
struct wm97xx *wm = dev_get_drvdata(dev);
@@ -859,21 +893,41 @@ EXPORT_SYMBOL_GPL(wm97xx_unregister_mach_ops);
static struct device_driver wm97xx_driver = {
.name = "wm97xx-ts",
+#ifdef CONFIG_AC97_BUS
.bus = &ac97_bus_type,
+#endif
.owner = THIS_MODULE,
.probe = wm97xx_probe,
.remove = wm97xx_remove,
.pm = &wm97xx_pm_ops,
};
+static struct platform_driver wm97xx_mfd_driver = {
+ .driver = {
+ .name = "wm97xx-ts",
+ .pm = &wm97xx_pm_ops,
+ },
+ .probe = wm97xx_mfd_probe,
+ .remove = wm97xx_mfd_remove,
+};
+
static int __init wm97xx_init(void)
{
- return driver_register(&wm97xx_driver);
+ int ret;
+
+ ret = platform_driver_register(&wm97xx_mfd_driver);
+ if (ret)
+ return ret;
+
+ if (IS_BUILTIN(CONFIG_AC97_BUS))
+ ret = driver_register(&wm97xx_driver);
+ return ret;
}
static void __exit wm97xx_exit(void)
{
driver_unregister(&wm97xx_driver);
+ platform_driver_unregister(&wm97xx_mfd_driver);
}
module_init(wm97xx_init);
--
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