* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family
From: Olof Johansson @ 2014-02-13 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F99056.6010906@samsung.com>
On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> On 02/13/14 04:14, Arnd Bergmann wrote:
>>
>> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote:
>>>
>>> On Feb 12, 2014, at 12:12 PM, Catalin Marinas<catalin.marinas@arm.com>
>>> wrote:
>>>>
>>>> On 12 Feb 2014, at 16:25, Kumar Gala<galak@codeaurora.org> wrote:
>>>>>
>>>>> One reason to keep around ARCH_* is for drivers shared between arm and
>>>>> arm64 that depend on it.
>>>>
>>>>
>>>> We already converted some of them (those depending on ARCH_VEXPRESS) to
>>>> just depend on ARM64. Ideally, at some point I'd like to see them as
>>>> defaulting to modules but I don't think we are there yet (we had some
>>>> discussions at the last KS, I'm not sure anyone started looking into
>>>> this).
>>>
>>>
>>> I'm torn about this, I think for something like VEXPRESS it makes sense,
>>> however I think its reasonable to still have an config symbol for a full
>>> SoC family or something of that nature.
>>
>>
>> I think for SBSA compliant systems, we should be able to live with a
>> generic ARCH_SBSA Kconfig symbol. For more irregular embedded platforms,
>> we may need something more specific.
>>
> Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to
> define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about
> compliant with SBSA Level1 and having some specific features?
(It's a little hard to answer since nobody can download the doc and
then talk about it.)
What kind of features are you expecting though? More IP
blocks/devices? Those are just kernel config options to enable,
ideally as modules.
x86 doesn't need config options for each generation of their platform,
and neither should ARM64. Sure, there might be drivers that don't make
sense to enable on some platforms, but that's what defconfigs (or
distro configs), and modules are for -- the modules won't load unless
the hardware is there.
As long as we're not talking about massive amounts of code that is
part of the base platform, separating out per version again doesn't
make sense -- just enable for SBSA and it'll support Level 1 through
whatever. If the kernel size becomes a concern we can revisit, but
let's not start out that way.
-Olof
^ permalink raw reply
* [BISECTED] ssh - Received disconnect from x.x.x.x: 2: Bad packet length 3149594624
From: Will Deacon @ 2014-02-13 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FD1243.9040706@gmail.com>
On Thu, Feb 13, 2014 at 06:43:15PM +0000, Ivaylo Dimitrov wrote:
>
>
> On 13.02.2014 20:21, Will Deacon wrote:
> >
> > That's certainly unexpected. The n900 has (iirc) a Cortex-A8, which as an
> > ARMv7 core, can perform unaligned accesses to normal, cacheable memory in
> > hardware.
> >
>
> Yep, Cortex-A8 and it has no problem to do unaligned memory accesses
> AFAIK. I suspect it is a driver issue, not CPU.
>
> > Can you provide your .config and/or any information about your network chip
> > please? There's a chance that the driver is doing something odd.
>
> The chip is TI wl1251, you can find the config file here(actually this
> is the tree I am using to boot 3.14-rc1 on N900) -
> https://gitorious.org/linux-n900/freemangordons-linux-n900/source/1434dbd7fbc5ec257b6cd6c547689b79177d1937:arch/arm/configs/rx51_defconfig
Ok, so based on that config I think we can narrow down the unaligned use to
the following files:
# Crypto
crypto/memneq.c:#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
crypto/memneq.c:#endif /* CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
crypto/memneq.c:#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
crypto/memneq.c:#endif /* CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
# Network
include/linux/etherdevice.h:#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
include/linux/etherdevice.h:#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
include/linux/etherdevice.h:#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
include/linux/etherdevice.h:#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
include/linux/etherdevice.h:#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
net/mac80211/rx.c:#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
net/ipv4/netfilter/arp_tables.c:#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
# Probably not relevant
kernel/printk/printk.c:#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
kernel/taskstats.c:#if defined(CONFIG_64BIT) && !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
lib/lz4/lz4defs.h:#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) \
lib/lz4/lz4defs.h:#else /* CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
lib/lzo/lzo1x_compress.c:#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && defined(LZO_USE_CTZ64)
lib/lzo/lzo1x_compress.c:#elif defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && defined(LZO_USE_CTZ32)
lib/lzo/lzo1x_decompress_safe.c:#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
lib/lzo/lzo1x_decompress_safe.c:#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
lib/lzo/lzo1x_decompress_safe.c:#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
lib/strncpy_from_user.c:#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
lib/zlib_inflate/inffast.c:#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
Can you try hacking crypto/memneq.c so that it doesn't use
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS please? That would at least point the
finger at net/mac80211/rx.c or similar.
Cheers,
Will
^ permalink raw reply
* [PATCH 0/6] net: cpsw: Support for am335x chip MACIDs
From: Uwe Kleine-König @ 2014-02-13 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131218171301.GT4970@saruman.home>
Hello,
On Wed, Dec 18, 2013 at 11:13:01AM -0600, Felipe Balbi wrote:
> On Wed, Dec 18, 2013 at 10:40:58PM +0530, Mugunthan V N wrote:
> > On Wednesday 18 December 2013 10:38 PM, Felipe Balbi wrote:
> > > On Wed, Dec 18, 2013 at 10:30:55PM +0530, Mugunthan V N wrote:
> > >> On Wednesday 18 December 2013 10:17 PM, Markus Pargmann wrote:
> > >> Mac ID is to be filled by U-Boot and this kind of approach is already
> > >> rejected in linux-omap list.
> > >>
> > >> If proper ethaddr/eth*addr is populated in U-boot environment variable
> > >> then mac-address dt property in ethernet* device nodes will be populated
> > >> before boot kernel in U-boot. So I don't think this patch series is
> > >> required.
> > > but will u-boot read MACID from control module ?
> > >
> > Yes, U-Boot will read the MACID from control module and if a customer
> > wants to have his own MACID, U-boot ENV variable ethaddr/eth1addr must
> > be updated.
>
> cool, then I agree this series shouldn't be applied ;-)
But even then I'd suggest to take at least patches 1 and 2.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] iommu/exynos: Remove driver
From: Olof Johansson @ 2014-02-13 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL5jtJmfwajFD0cnYt6gOfFsZ5hGbFi=5kv8g4x23fY6qGBOew@mail.gmail.com>
On Mon, Feb 10, 2014 at 10:21 PM, Kukjin Kim <kgene.kim@gmail.com> wrote:
> Just adding KyongHo Cho.
>
> If he can fixup for this time, it would be best solution because he knows
> well than others, I think.
It's not so much a matter of "fixup for this time", it's a about
having ownership of the driver, making sure it works (and keeps
working if there is related development). The posted patches have not
been followed through on and the result is a broken driver. :(
I definitely appreciate his expertise, and we should make sure that he
gets to review the code, but if someone else is able to spend time on
reworking the driver (or rewriting a newer one) and maintaining it
longer-term, then we should not stop them from doing so. And there is
no reason to keep broken stale code in the kernel meanwhile.
-Olof
^ permalink raw reply
* [PATCH 4/6] net: cpsw: Use cpsw-ctrl-macid driver
From: Uwe Kleine-König @ 2014-02-13 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387385242-1161-5-git-send-email-mpa@pengutronix.de>
Hello Markus,
On Wed, Dec 18, 2013 at 05:47:20PM +0100, Markus Pargmann wrote:
> Use ctrl-macid driver to obtain the macids stored in the processor. This
> is only done when defined in DT.
>
> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> ---
> Documentation/devicetree/bindings/net/cpsw.txt | 5 +++++
> drivers/net/ethernet/ti/cpsw.c | 18 ++++++++++++++----
> drivers/net/ethernet/ti/cpsw.h | 2 ++
> 3 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
> index c39f077..b95c38b 100644
> --- a/Documentation/devicetree/bindings/net/cpsw.txt
> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
> @@ -34,6 +34,11 @@ Required properties:
> Optional properties:
> - dual_emac_res_vlan : Specifies VID to be used to segregate the ports
> - mac-address : Specifies slave MAC address
> +- ti,mac-address-ctrl : When cpsw-ctrl-macid support is compiledin, this can
> + be set to a phandle with one argument, see
> + cpsw-ctrl-macid.txt. If this method fails, cpsw falls
> + back to mac-address or random mac-address.
> +
>
> Note: "ti,hwmods" field is used to fetch the base address and irq
> resources from TI, omap hwmod data base during device registration.
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index 5120d9c..382d793 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -1804,9 +1804,16 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
> snprintf(slave_data->phy_id, sizeof(slave_data->phy_id),
> PHY_ID_FMT, mdio->name, phyid);
>
> - mac_addr = of_get_mac_address(slave_node);
> - if (mac_addr)
> - memcpy(slave_data->mac_addr, mac_addr, ETH_ALEN);
> + ret = cpsw_ctrl_macid_read(slave_node, slave_data->mac_addr);
> + if (ret) {
> + if (ret == -EPROBE_DEFER)
> + return ret;
> +
> + mac_addr = of_get_mac_address(slave_node);
> + if (mac_addr)
> + memcpy(slave_data->mac_addr, mac_addr,
> + ETH_ALEN);
> + }
I'd do it the other way round: Use the contents from an explicit
"mac-address" or "local-mac-address" property (i.e. of_get_mac_address)
and if that doesn't return anything use the mac-address-ctrl as
fallback.
>
> slave_data->phy_if = of_get_phy_mode(slave_node);
>
> @@ -1946,10 +1953,13 @@ static int cpsw_probe(struct platform_device *pdev)
> /* Select default pin state */
> pinctrl_pm_select_default_state(&pdev->dev);
>
> - if (cpsw_probe_dt(&priv->data, pdev)) {
> + ret = cpsw_probe_dt(&priv->data, pdev);
> + if (ret == -EINVAL) {
> pr_err("cpsw: platform data missing\n");
> ret = -ENODEV;
> goto clean_runtime_disable_ret;
> + } else if (ret) {
> + goto clean_runtime_disable_ret;
> }
> data = &priv->data;
>
> diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
> index 1b71067..222eebe 100644
> --- a/drivers/net/ethernet/ti/cpsw.h
> +++ b/drivers/net/ethernet/ti/cpsw.h
> @@ -42,4 +42,6 @@ struct cpsw_platform_data {
>
> void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave);
>
> +int cpsw_ctrl_macid_read(struct device_node *np, u8 *mac_addr);
> +
> #endif /* __CPSW_H__ */
> --
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] drm/i2c: tda998x: fix memory leak in case of i2c error
From: Russell King - ARM Linux @ 2014-02-13 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213083316.38D7D822BD@smtp6-g21.free.fr>
On Thu, Feb 13, 2014 at 09:13:34AM +0100, Jean-Francois Moine wrote:
> When the creation of the second i2c client was failing, the private
> buffer was not freed.
>
> This bug was introduced by the commit 6ae668cc19e8
> 'drm/i2c: tda998x: check the CEC device creation'
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Since David got there first with his patch, which is identical to yours,
I'll take his description, and take this as an acked-by for it.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 3/6] net: cpsw: Add control-module macid driver
From: Uwe Kleine-König @ 2014-02-13 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387385242-1161-4-git-send-email-mpa@pengutronix.de>
On Wed, Dec 18, 2013 at 05:47:19PM +0100, Markus Pargmann wrote:
> This driver extracts the hardware macid from the control module of
> am335x processors. It exports a function cpsw_ctrl_macid_read for cpsw
> to get the macid from within the processor.
>
> This driver is not used, unless it is defined in DT and referenced by a
> cpsw slave with a phandle.
>
> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> ---
> .../devicetree/bindings/net/cpsw-ctrl-macid.txt | 31 +++++
> drivers/net/ethernet/ti/Kconfig | 8 ++
> drivers/net/ethernet/ti/Makefile | 1 +
> drivers/net/ethernet/ti/cpsw-ctrl-macid.c | 138 +++++++++++++++++++++
> 4 files changed, 178 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt
> create mode 100644 drivers/net/ethernet/ti/cpsw-ctrl-macid.c
>
> diff --git a/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt b/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt
> new file mode 100644
> index 0000000..abff2af
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt
> @@ -0,0 +1,31 @@
> +TI CPSW ctrl macid Devicetree bindings
> +--------------------------------------
> +
> +Required properties:
> + - compatible : Should be "ti,am3352-cpsw-ctrl-macid"
> + - reg : physical base address and size of the cpsw
> + registers map
> + - reg-names : names of the register map given in "reg" node
> + - #ti,cpsw-ctrl-macid : Should be <1>
#ti,mac-address-ctrl-cells?
> +
> +When used from cpsw, "ti,mac-address-ctrl" should be a phandle to this device
> +node with one argument, 0 or 1 to select the macid 0 or 1.
> +
> +Examples:
> +
> + cpsw_ctrl_macid: cpsw-ctrl-macid at 44e10630 {
> + compatible = "ti,am3352-cpsw-ctrl-macid";
> + #ti,mac-address-ctrl-cells = <1>;
> + reg = <0x44e10630 0x16>;
s/0x16/0x10/
> + reg-names = "ctrl-macid";
> + };
> +
> +Used in cpsw slave nodes like this:
> +
> + cpsw_emac0: slave at 4a100200 {
> + ti,mac-address-ctrl = <&cpsw_ctrl_macid 0>;
> + };
> +
> + cpsw_emac1: slave at 4a100300 {
> + ti,mac-address-ctrl = <&cpsw_ctrl_macid 1>;
> + };
> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
> index 53150c2..24819ef 100644
> --- a/drivers/net/ethernet/ti/Kconfig
> +++ b/drivers/net/ethernet/ti/Kconfig
> @@ -56,12 +56,20 @@ config TI_CPSW_PHY_SEL
> This driver supports configuring of the phy mode connected to
> the CPSW.
>
> +config TI_CPSW_CTRL_MACID
> + boolean "TI CPSW internal MACID support"
> + depends on TI_CPSW
> + ---help---
> + This driver supports reading the hardcoded MACID from am33xx
> + processors control module.
> +
Would it be nicer to put this after the TI_CPSW definition. (Think
$(make config).)
> config TI_CPSW
> tristate "TI CPSW Switch Support"
> depends on ARM && (ARCH_DAVINCI || SOC_AM33XX)
> select TI_DAVINCI_CPDMA
> select TI_DAVINCI_MDIO
> select TI_CPSW_PHY_SEL
> + select TI_CPSW_CTRL_MACID
If TI_CPSW selects TI_CPSW_CTRL_MACID the latter doesn't need to depend
on the former. So this optin is user visible but never
user-(de)selectable. I'd say drop the Kconfig symbol and just add
cpsw-ctrl-macid.o to ti_cpsw-y in the Makefile (or really make it
optional).
> ---help---
> This driver supports TI's CPSW Ethernet Switch.
>
> diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
> index 9cfaab8..5a31c2b 100644
> --- a/drivers/net/ethernet/ti/Makefile
> +++ b/drivers/net/ethernet/ti/Makefile
> @@ -8,5 +8,6 @@ obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
> obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
> obj-$(CONFIG_TI_DAVINCI_CPDMA) += davinci_cpdma.o
> obj-$(CONFIG_TI_CPSW_PHY_SEL) += cpsw-phy-sel.o
> +obj-$(CONFIG_TI_CPSW_CTRL_MACID) += cpsw-ctrl-macid.o
> obj-$(CONFIG_TI_CPSW) += ti_cpsw.o
> ti_cpsw-y := cpsw_ale.o cpsw.o cpts.o
> diff --git a/drivers/net/ethernet/ti/cpsw-ctrl-macid.c b/drivers/net/ethernet/ti/cpsw-ctrl-macid.c
> new file mode 100644
> index 0000000..e18c957
> --- /dev/null
> +++ b/drivers/net/ethernet/ti/cpsw-ctrl-macid.c
> @@ -0,0 +1,138 @@
> +/* CPSW Control Module MACID driver
> + *
> + * Copyright (C) 2013 Markus Pargmann <mpa@pengutronix.de>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +
> +#include "cpsw.h"
> +
> +#define AM33XX_CTRL_MAC_LO_REG(id) (0x8 * id)
> +#define AM33XX_CTRL_MAC_HI_REG(id) (0x8 * id + 0x4)
> +
> +struct cpsw_ctrl_macid {
> + struct device *dev;
> + u8 __iomem *ctrl_macid;
> + void (*cpsw_macid_get)(struct cpsw_ctrl_macid *priv, int slave,
> + u8 *mac_addr);
> +};
> +
> +
> +static void cpsw_ctrl_get_macid(struct cpsw_ctrl_macid *priv, int slave,
> + u8 *mac_addr)
> +{
> + u32 macid_lo;
> + u32 macid_hi;
> +
> + macid_lo = readl(priv->ctrl_macid + AM33XX_CTRL_MAC_LO_REG(slave));
> + macid_hi = readl(priv->ctrl_macid + AM33XX_CTRL_MAC_HI_REG(slave));
> +
> + mac_addr[5] = (macid_lo >> 8) & 0xff;
> + mac_addr[4] = macid_lo & 0xff;
> + mac_addr[3] = (macid_hi >> 24) & 0xff;
> + mac_addr[2] = (macid_hi >> 16) & 0xff;
> + mac_addr[1] = (macid_hi >> 8) & 0xff;
> + mac_addr[0] = macid_hi & 0xff;
> +}
> +
> +static struct platform_driver cpsw_ctrl_macid_driver;
> +
> +static int match(struct device *dev, void *data)
> +{
> + struct device_node *node = (struct device_node *)data;
> +
> + return dev->of_node == node &&
> + dev->driver == &cpsw_ctrl_macid_driver.driver;
> +}
> +
> +int cpsw_ctrl_macid_read(struct device_node *np, u8 *mac_addr)
> +{
> + struct device *ctrl_dev;
> + struct cpsw_ctrl_macid *priv;
> + struct of_phandle_args args;
> + int ret;
> +
> + ret = of_parse_phandle_with_args(np, "ti,mac-address-ctrl",
> + "#ti,mac-address-ctrl-cells", 0, &args);
> + if (ret)
> + return ret;
> +
> + if (args.args_count != 1 || args.args[0] < 0 || args.args[0] > 1) {
> + pr_err("Failed to parse ti,mac-address-module phandle because of invalid arguments\n");
> + return -EINVAL;
> + }
> +
> + ctrl_dev = bus_find_device(&platform_bus_type, NULL, args.np, match);
> + priv = dev_get_drvdata(ctrl_dev);
> + of_node_put(args.np);
> + if (priv == NULL)
> + return -EPROBE_DEFER;
> +
> + priv->cpsw_macid_get(priv, args.args[0], mac_addr);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(cpsw_ctrl_macid_read);
> +
> +static const struct of_device_id cpsw_ctrl_macid_of_ids[] = {
> + {
> + .compatible = "ti,am3352-cpsw-ctrl-macid",
> + .data = &cpsw_ctrl_get_macid,
> + },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, cpsw_ctrl_macid_of_ids);
> +
> +static int cpsw_ctrl_macid_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + const struct of_device_id *of_id;
> + struct cpsw_ctrl_macid *priv;
> +
> + of_id = of_match_node(cpsw_ctrl_macid_of_ids, pdev->dev.of_node);
> + if (!of_id)
> + return -EINVAL;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv) {
> + dev_err(&pdev->dev, "unable to alloc memory for cpsw-ctrl-macid\n");
> + return -ENOMEM;
> + }
> +
> + priv->cpsw_macid_get = of_id->data;
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ctrl-macid");
> + priv->ctrl_macid = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(priv->ctrl_macid))
> + return PTR_ERR(priv->ctrl_macid);
> +
> + dev_set_drvdata(&pdev->dev, priv);
> +
> + dev_info(&pdev->dev, "TI CPSW ctrl macid loaded\n");
> + return 0;
> +}
> +
> +static struct platform_driver cpsw_ctrl_macid_driver = {
> + .probe = cpsw_ctrl_macid_probe,
> + .driver = {
> + .name = "cpsw-ctrl-macid",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(cpsw_ctrl_macid_of_ids),
> + },
> +};
> +
> +module_platform_driver(cpsw_ctrl_macid_driver);
> +MODULE_AUTHOR("Markus Pargmann <mpa@pengutronix.de>");
> +MODULE_LICENSE("GPL v2");
> --
> 1.8.5.1
>
>
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 6/6] arm: dts: am335x beagle bone use processor macids
From: Uwe Kleine-König @ 2014-02-13 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387385242-1161-7-git-send-email-mpa@pengutronix.de>
Hello,
On Wed, Dec 18, 2013 at 05:47:22PM +0100, Markus Pargmann wrote:
> Use macids stored in the am335x chip.
>
> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> ---
> arch/arm/boot/dts/am335x-bone.dts | 8 ++++++++
> arch/arm/boot/dts/am335x-boneblack.dts | 8 ++++++++
> 2 files changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> index 94ee427..9b65a62 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -10,6 +10,14 @@
> #include "am33xx.dtsi"
> #include "am335x-bone-common.dtsi"
>
> +&cpsw_emac0 {
> + ti,mac-address-ctrl = <&cpsw_ctrl_macid 0>;
> +};
> +
> +&cpsw_emac1 {
> + ti,mac-address-ctrl = <&cpsw_ctrl_macid 1>;
> +};
with the mac-address property overwriting the addresses found in the
mac-address-ctrl block as I suggested in reply to the respective patch,
I'd add this property not per machine but directly in am33xx.dtsi.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 1/5] drivers: of: add initialization code for reserved memory
From: Josh Cartwright @ 2014-02-13 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FA87B8.8040203@gmail.com>
On Tue, Feb 11, 2014 at 09:27:36PM +0100, Tomasz Figa wrote:
> On 11.02.2014 21:19, Josh Cartwright wrote:
> >On Tue, Feb 11, 2014 at 09:04:21PM +0100, Tomasz Figa wrote:
> > >On 11.02.2014 21:02, Benjamin Herrenschmidt wrote:
> > > >On Tue, 2014-02-11 at 19:01 +0000, Grant Likely wrote:
> > > > > > except that the former IMHO better suits the definition of memory
> > > > > > region, which I see as a single contiguous range of memory and can be
> > > > > > simplified to have a single reg entry per region.
> > > > >
> > > > > My point is rather if multiple reg tuples are found in a reserved memory
> > > > > node, the kernel must respect them and reserve the memory. I'm not
> > > > > arguing about whether or not that makes for a good binding.
> > > >
> > > > agreed.
> > >
> > > My point is why, if the binding defines that just a single tuple should be
> > > provided.
> >
> > FWIW, the usecase I had mentioned in reply to Grant in the patch 5/5
> > thread [1] could make use of this. The shared memory region is split
> > into a main chunk and several "auxiliary" chunk, but collectively these
> > regions all share the same heap state.
> >
> > Josh
> >
> > 1: http://lkml.kernel.org/r/20140205192502.GO20228 at joshc.qualcomm.com
>
> The use case seems fine, but I believe it could be properly represented in
> device tree using multiple single-reg regions as well, unless the consumer
> can request a block of memory that crosses boundary of two sub-regions
> specified by reg entries of single region.
I could probably make a only-one-reg-entry policy work for me, but it
makes things a bit more awkward. I'd lose the ability to describe
"this set of regions need to be logically handled together" directly in
the reserved memory node, and would need to push it up a layer.
reserved-memory {
smem: smem {
reg = <...>;
};
aux1: auxiliary1 {
reg = <...>;
};
aux2: auxiliary2 {
reg = <...>;
};
...
};
heap : heap {
compatible = "qcom,shared-memory";
memory-region = <&smem &aux1 &aux2>;
#smem-cells = <2>;
};
actual_consumer1 {
compatible = "...";
smem = <&heap IDENTIFIER1 0x1000>;
};
actual_consumer2 {
compatible = "...";
smem = <&heap IDENTIFIER2 0x1000>;
};
Maybe that's better off, I don't know. This would also eliminate my
need for a #memory-region-cells property.
Thanks,
Josh
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v2 3/3] PCI: ARM: add support for generic PCI host controller
From: Will Deacon @ 2014-02-13 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213180616.GD17248@obsidianresearch.com>
On Thu, Feb 13, 2014 at 06:06:16PM +0000, Jason Gunthorpe wrote:
> On Thu, Feb 13, 2014 at 11:07:21AM +0000, Will Deacon wrote:
>
> > Not in this case! kvmtool generates the following:
>
> Well, the example is nice so someone can review it..
>
> > pci {
> > #address-cells = <0x3>;
> > #size-cells = <0x2>;
> > #interrupt-cells = <0x1>;
> > compatible = "arm,pci-cam-generic";
> > reg = <0x0 0x40000000>;
> > ranges = <0x1000000 0x0 0x0 0x0 0x0 0x0 0x10000 0x2000000 0x0 0x41000000 0x0 0x41000000 0x0 0x3f000000>;
> > interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x0 0x4 0x1 0x800 0x0 0x0 0x1 0x1 0x0 0x5 0x1 0x1000 0x0 0x0 0x1 0x1 0x0 0x6 0x1 0x1800 0x0 0x0 0x1 0x1 0x0 0x7 0x1>;
> > interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> > };
>
>
> Looks like there are a few misses in the above. How about this:
>
> pci {
> compatible = "arm,pci-cam-generic"
> device_type = "pci";
> ** ^^^^^^^^^^^^^^^^^
> ** MANDATORY for the host bridge node
Ok, I'll add that.
> #address-cells = <3>;
> #size-cells = <2>;
>
> // BUS_ADDRESS(3) CPU_PHYSICAL(2) SIZE(2)
> ranges = <0x1000000 0x0 0x00000000 0x0 0x00000000 0x0 0x00010000>,
> ^^^^^^^^^^^^^^
> ** ?? Is this why you had problems with the offset? Should
> ** be the cpu physical address of the start of the IO window.
> <0x2000000 0x0 0x41000000 0x0 0x41000000 0x0 0x3f000000>;
>
>
> #interrupt-cells = <0x1>;
> // PCI_DEVICE(3) INT#(1) CONTROLLER(PHANDLE) CONTROLLER_DATA(3)
> interrupt-map = < 0x0 0x0 0x0 0x1 0x1 0x0 0x4 0x1
> 0x800 0x0 0x0 0x1 0x1 0x0 0x5 0x1
> 0x1000 0x0 0x0 0x1 0x1 0x0 0x6 0x1
> 0x1800 0x0 0x0 0x1 0x1 0x0 0x7 0x1>;
> ** ^^^^^^
> ** This should be a phandle to the interrupt controller
That is a phandle, libfdt/kvmtool just ends up dealing with the number
directly. I'll fix in the example.
> // PCI_DEVICE(3) INT#1()
> interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> }
>
> I keep thinking of making a pcie-dt.h file with helper macros for
> all this. :|
If it's not being generated automatically, that could be useful.
> FWWI, I like to put a double space between the logically distinct
> things in the lists.
Makes sense, I may well do the same.
Thanks,
Will
^ permalink raw reply
* [PATCH v2] ARM: mm: report both sections from PMD
From: Kees Cook @ 2014-02-13 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213171211.GJ19841@arm.com>
On Thu, Feb 13, 2014 at 9:12 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Wed, Feb 12, 2014 at 10:46:38PM +0000, Kees Cook wrote:
>> diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
>> index 03243f7eeddf..fb3de59ee811 100644
>> --- a/arch/arm/include/asm/pgtable-3level.h
>> +++ b/arch/arm/include/asm/pgtable-3level.h
>> @@ -138,10 +138,6 @@
>> #define pud_none(pud) (!pud_val(pud))
>> #define pud_bad(pud) (!(pud_val(pud) & 2))
>> #define pud_present(pud) (pud_val(pud))
>> -#define pmd_table(pmd) ((pmd_val(pmd) & PMD_TYPE_MASK) == \
>> - PMD_TYPE_TABLE)
>> -#define pmd_sect(pmd) ((pmd_val(pmd) & PMD_TYPE_MASK) == \
>> - PMD_TYPE_SECT)
>> #define pmd_large(pmd) pmd_sect(pmd)
>>
>> #define pud_clear(pudp) \
>> diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
>> index 7d59b524f2af..934aa5b60c7c 100644
>> --- a/arch/arm/include/asm/pgtable.h
>> +++ b/arch/arm/include/asm/pgtable.h
>> @@ -183,6 +183,10 @@ extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
>>
>> #define pmd_none(pmd) (!pmd_val(pmd))
>> #define pmd_present(pmd) (pmd_val(pmd))
>> +#define pmd_table(pmd) ((pmd_val(pmd) & PMD_TYPE_MASK) == \
>> + PMD_TYPE_TABLE)
>> +#define pmd_sect(pmd) ((pmd_val(pmd) & PMD_TYPE_MASK) == \
>> + PMD_TYPE_SECT)
>
> Do you still need to move these two if you only use pmd_large()? AFAICT,
> it is equivalent to pmd_sect().
Why does pmd_sect exist? I can reduce it to just using pmd_large.
>
>> static inline pte_t *pmd_page_vaddr(pmd_t pmd)
>> {
>> diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
>> index 2b342177f5de..32635b474832 100644
>> --- a/arch/arm/mm/dump.c
>> +++ b/arch/arm/mm/dump.c
>> @@ -260,8 +260,14 @@ static void walk_pmd(struct pg_state *st, pud_t *pud, unsigned long start)
>>
>> for (i = 0; i < PTRS_PER_PMD; i++, pmd++) {
>> addr = start + i * PMD_SIZE;
>> - if (pmd_none(*pmd) || pmd_large(*pmd) || !pmd_present(*pmd))
>> + if (pmd_none(*pmd) || pmd_large(*pmd) || !pmd_present(*pmd)) {
>> note_page(st, addr, 3, pmd_val(*pmd));
>> + if (SECTION_SIZE < PMD_SIZE &&
>> + pmd_sect(*pmd) && pmd_sect(pmd[1])) {
>
> I think the first patch was better with pmd[0] and pmd[1] treated
> independently if SECTION_SIZE < PMD_SIZE, only that it should have
> checked for pmd_sect(pmd[1]). I don't see anything in
> __map_init_section() that would prevent populating only the second pmd
> leaving the first one empty.
Ah, gotcha. Okay, I will send a new version. Thanks!
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* [PATCH v3] ARM: mm: report both sections from PMD
From: Kees Cook @ 2014-02-13 19:52 UTC (permalink / raw)
To: linux-arm-kernel
On 2-level page table systems, the PMD has 2 section entries. Report
these, otherwise ARM_PTDUMP will miss reporting permission changes on
odd section boundaries.
Signed-off-by: Kees Cook <keescook@chromium.org>
---
v3:
- re-reorganize, drop use of pmd_sect; suggested by Catalin Marinas.
v2:
- reorganize, suggested by Catalin Marinas.
---
arch/arm/mm/dump.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
index 2b342177f5de..61cc78ae9f21 100644
--- a/arch/arm/mm/dump.c
+++ b/arch/arm/mm/dump.c
@@ -264,6 +264,9 @@ static void walk_pmd(struct pg_state *st, pud_t *pud, unsigned long start)
note_page(st, addr, 3, pmd_val(*pmd));
else
walk_pte(st, pmd, addr);
+
+ if (SECTION_SIZE < PMD_SIZE && pmd_large(pmd[1]))
+ note_page(st, addr + SECTION_SIZE, 3, pmd_val(pmd[1]));
}
}
--
1.7.9.5
--
Kees Cook
Chrome OS Security
^ permalink raw reply related
* [PATCH v2 3/3] PCI: ARM: add support for generic PCI host controller
From: Rob Herring @ 2014-02-13 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BA5E6077-77F8-4BE8-80E5-BAB9FE111387@codeaurora.org>
On Thu, Feb 13, 2014 at 10:22 AM, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Feb 13, 2014, at 5:07 AM, Will Deacon <will.deacon@arm.com> wrote:
>
>> On Wed, Feb 12, 2014 at 09:51:48PM +0000, Kumar Gala wrote:
>>>
>>> On Feb 12, 2014, at 2:16 PM, Will Deacon <will.deacon@arm.com> wrote:
>>>
>>>> This patch adds support for a generic PCI host controller, such as a
>>>> firmware-initialised device with static windows or an emulation by
>>>> something such as kvmtool.
>>>>
>>>> The controller itself has no configuration registers and has its address
>>>> spaces described entirely by the device-tree (using the bindings from
>>>> ePAPR). Both CAM and ECAM are supported for Config Space accesses.
>>>>
>>>> Corresponding documentation is added for the DT binding.
>>>>
>>>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>>>> ---
>>>> .../devicetree/bindings/pci/arm-generic-pci.txt | 51 ++++
>>>> drivers/pci/host/Kconfig | 7 +
>>>> drivers/pci/host/Makefile | 1 +
>>>> drivers/pci/host/pci-arm-generic.c | 318 +++++++++++++++++++++
>>>> 4 files changed, 377 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/pci/arm-generic-pci.txt
>>>> create mode 100644 drivers/pci/host/pci-arm-generic.c
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pci/arm-generic-pci.txt b/Documentation/devicetree/bindings/pci/arm-generic-pci.txt
>>>> new file mode 100644
>>>> index 000000000000..cc7a35ecfa2d
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/pci/arm-generic-pci.txt
>>>> @@ -0,0 +1,51 @@
>>>> +* ARM generic PCI host controller
>>>> +
>>>> +Firmware-initialised PCI host controllers and PCI emulations, such as the
>>>> +virtio-pci implementations found in kvmtool and other para-virtualised
>>>> +systems, do not require driver support for complexities such as regulator and
>>>> +clock management. In fact, the controller may not even require the
>>>> +configuration of a control interface by the operating system, instead
>>>> +presenting a set of fixed windows describing a subset of IO, Memory and
>>>> +Configuration Spaces.
>>>> +
>>>> +Such a controller can be described purely in terms of the standardized device
>>>> +tree bindings communicated in pci.txt:
>>>> +
>>>> +- compatible : Must be "arm,pci-cam-generic" or "arm,pci-ecam-generic"
>>>> + depending on the layout of configuration space (CAM vs
>>>> + ECAM respectively)
>>>
>>> What's arm specific here? I don't have a great suggestion, but seems odd
>>> for this to be vendor prefixed with "arm".
>>
>> Happy to change it, but I'm also struggling for names. Maybe "linux,..."?
>
> I was thinking that as well, I'd say go with "linux,".
Just drop the prefix altogether.
I'm wondering if this should have host or rc in the name.
Rob
^ permalink raw reply
* [PATCH v2 3/3] PCI: ARM: add support for generic PCI host controller
From: Will Deacon @ 2014-02-13 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213182654.GA20043@obsidianresearch.com>
On Thu, Feb 13, 2014 at 06:26:54PM +0000, Jason Gunthorpe wrote:
> On Thu, Feb 13, 2014 at 05:28:20PM +0100, Arnd Bergmann wrote:
>
> > > Huh? The reg property clearly has the size in it (as shown in the
> > > example below). I guess I was just asking for the description
> > > here to say what the size was for the 2 compatibles since its
> > > fixed and known.
> >
> > It's still an open question whether the config space in the reg
> > property should cover all 256 buses or just the ones in the
> > bus-range. In the latter case, it would be variable (but
> > predictable) size.
>
> The 'describe the hardware principle' says the reg should be the
> entire available ECAM/CAM region the hardware is able to support.
>
> This may be less than 256 busses, as ECAM allows the implementor to
> select how many upper address bits are actually supported.
Ok, but the ECAM/CAM base always corresponds to bus 0, right?
> IMHO, the bus-range should be used to indicate the range of busses
> discovered by the firmware, but we have historically tweaked it to
> indicate the max range of bus numbers available on this bus (I think
> to support the hack where two physical PCI domains were roughly glued
> into a single Linux domain).
Ok, so this answers Kumar's point about the reg property. I'll augment it
with a size.
Will
^ permalink raw reply
* [PATCH] Fix uses of dma_max_pfn() when converting to a limiting address
From: Russell King - ARM Linux @ 2014-02-13 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392314821.2175.16.camel@dabdike.int.hansenpartnership.com>
On Thu, Feb 13, 2014 at 10:07:01AM -0800, James Bottomley wrote:
> On Thu, 2014-02-13 at 17:11 +0000, Russell King - ARM Linux wrote:
> > On Thu, Feb 13, 2014 at 08:58:10AM -0800, James Bottomley wrote:
> > > This doesn't really look like the right fix. You replaced dev->dma_mask
> > > with a calculation on dev_max_pfn(). Since dev->dma_mask is always u64
> > > and dev_max_pfn is supposed to be returning the pfn of the dma_mask, it
> > > should unconditionally be 64 bits as well. Either that or it should
> > > return dma_addr_t.
> >
> > My reasoning is that PFNs in the system are always of type "unsigned long"
> > and therefore a function returning a pfn should have that type. If we
> > overflow a PFN fitting in an unsigned long, we have lots of places which
> > need fixing.
>
> It's not intuitive to people who need the dma mask that they're supposed
> to use dma_max_pfn() << PAGE_SHIFT but now they have to worry about the
> casting and, if they don't get it right, nothing will warn or tell them.
> what about a new macro, say dma_max_mask(dev) that just returns
> (u64)dma_max_pfn() << PAGE_SHIFT?
This sounds like a good idea.
I've just been looking@places which do this << PAGE_SHIFT, and we
have other places which suffer from this same bug all over the kernel,
so maybe we actually need a pfn_to_addr() macro or similar so that
people get this right in these other places too? It appears to be
quite a widespread problem.
I'm surprised none of the below haven't already caused a problem.
Thoughts?
int __remove_pages(struct zone *zone, unsigned long phys_start_pfn,
unsigned long nr_pages)
{
resource_size_t start, size;
start = phys_start_pfn << PAGE_SHIFT;
void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone,
unsigned long start_pfn, enum memmap_context context)
{
unsigned long end_pfn = start_pfn + size;
unsigned long pfn;
/* The shift won't overflow because ZONE_NORMAL is below 4G. */
if (!is_highmem_idx(zone))
set_page_address(page, __va(pfn << PAGE_SHIFT));
void __init free_area_init_nodes(unsigned long *max_zone_pfn)
{
unsigned long start_pfn, end_pfn;
for_each_mem_pfn_range(i, MAX_NUMNODES, &start_pfn, &end_pfn, &nid)
printk(" node %3d: [mem %#010lx-%#010lx]\n", nid,
start_pfn << PAGE_SHIFT, (end_pfn << PAGE_SHIFT) - 1);
(thankfully, this one is just a printk).
int vb2_get_contig_userptr(unsigned long vaddr, unsigned long size,
struct vm_area_struct **res_vma, dma_addr_t *res_pa)
{
unsigned long this_pfn, prev_pfn;
dma_addr_t pa = 0;
if (prev_pfn == 0)
pa = this_pfn << PAGE_SHIFT;
static pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
unsigned long size, pgprot_t vma_prot)
{
#ifdef pgprot_noncached
phys_addr_t offset = pfn << PAGE_SHIFT;
if (uncached_access(file, offset))
return pgprot_noncached(vma_prot);
#endif
return vma_prot;
static int i810_insert_dcache_entries(struct agp_memory *mem, off_t pg_start,
int type)
{
int i;
for (i = pg_start; i < (pg_start + mem->page_count); i++) {
dma_addr_t addr = i << PAGE_SHIFT;
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family
From: Rob Herring @ 2014-02-13 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMiWsWXkQkb-_VZGco0gKNZPsHf3ubR88y4Pt4-umk5_Ww@mail.gmail.com>
On Tue, Feb 11, 2014 at 5:39 PM, Olof Johansson <olof@lixom.net> wrote:
> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig.
>>
>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>
> The overhead of building one more device tree isn't very large, and I
> don't see any other need to have a Kconfig entry per SoC at this time.
> It's of course up to Catalin, but you might just want to always
> compile all dts files instead.
I think having "make dtbs" build all regardless of the config would be
better. Perhaps a "all_dtbs" target could be added and everyone can
get what they want. If/when we add checking into dtc, this we
certainly become more desirable.
Rob
^ permalink raw reply
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family
From: Olof Johansson @ 2014-02-13 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJ5FHt4HoV2NtU1ddFpcdxi=Jji0-mPSXL872P8fXrCuQ@mail.gmail.com>
On Thu, Feb 13, 2014 at 12:08 PM, Rob Herring <robherring2@gmail.com> wrote:
> On Tue, Feb 11, 2014 at 5:39 PM, Olof Johansson <olof@lixom.net> wrote:
>> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
>>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig.
>>>
>>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>
>> The overhead of building one more device tree isn't very large, and I
>> don't see any other need to have a Kconfig entry per SoC at this time.
>> It's of course up to Catalin, but you might just want to always
>> compile all dts files instead.
>
> I think having "make dtbs" build all regardless of the config would be
> better.
We can do that too, but that doesn't mean it's useful to have this
kconfig entry.
> Perhaps a "all_dtbs" target could be added and everyone can
> get what they want. If/when we add checking into dtc, this we
> certainly become more desirable.
-Olof
^ permalink raw reply
* [PATCH v2 3/3] PCI: ARM: add support for generic PCI host controller
From: Jason Gunthorpe @ 2014-02-13 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213195317.GQ13576@mudshark.cambridge.arm.com>
On Thu, Feb 13, 2014 at 07:53:17PM +0000, Will Deacon wrote:
> > This may be less than 256 busses, as ECAM allows the implementor to
> > select how many upper address bits are actually supported.
>
> Ok, but the ECAM/CAM base always corresponds to bus 0, right?
Yes, or it isn't ECAM.
> Ok, so this answers Kumar's point about the reg property. I'll augment it
> with a size.
Don't forget to request_region it as well...
Jason
^ permalink raw reply
* [PATCH 0/5] mv64xxx updates
From: Wolfram Sang @ 2014-02-13 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213094117.GA3934@katana>
So, this is a series I came up with trying to fix the issue found by Kevin.
Patches 1+2 are hopefully fixing the bug (in theory, I don't have the HW).
Patches 3-5 are RFC, and if patch 3 actually works (see the CHECKME), then 4+5
are further cleanup possibilities. And there is still more potential, I mainly
wanted to give some inspiration and awareness that the driver could need some
more love. Please test at least 1+2, comments to 3-5 very welcome.
Sorry for the delay, I got distracted by an NMI.
Wolfram Sang (5):
i2c: mv64xxx: put offload check into offload prepare function
i2c: mv64xxx: refactor message start to ensure proper initialization
i2c: mv64xxx: refactor send_start
i2c: mv64xxx: directly call send_start when initializing transfer
i2c: mv64xxx: refactor initialization for new msgs
drivers/i2c/busses/i2c-mv64xxx.c | 67 ++++++++++++++++------------------------
1 file changed, 27 insertions(+), 40 deletions(-)
--
1.8.5.1
^ permalink raw reply
* [PATCH 1/5] i2c: mv64xxx: put offload check into offload prepare function
From: Wolfram Sang @ 2014-02-13 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392323793-4125-1-git-send-email-wsa@the-dreams.de>
It makes code simpler to read and prepares a reorganization needed for a
bugfix.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
drivers/i2c/busses/i2c-mv64xxx.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index b8c5187..ba64978 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -204,6 +204,9 @@ static int mv64xxx_i2c_offload_msg(struct mv64xxx_i2c_data *drv_data)
unsigned long ctrl_reg;
struct i2c_msg *msg = drv_data->msgs;
+ if (!drv_data->offload_enabled)
+ return -EOPNOTSUPP;
+
drv_data->msg = msg;
drv_data->byte_posn = 0;
drv_data->bytes_left = msg->len;
@@ -433,8 +436,7 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
drv_data->msgs++;
drv_data->num_msgs--;
- if (!(drv_data->offload_enabled &&
- mv64xxx_i2c_offload_msg(drv_data))) {
+ if (mv64xxx_i2c_offload_msg(drv_data) < 0) {
drv_data->cntl_bits |= MV64XXX_I2C_REG_CONTROL_START;
writel(drv_data->cntl_bits,
drv_data->reg_base + drv_data->reg_offsets.control);
--
1.8.5.1
^ permalink raw reply related
* [PATCH 2/5] i2c: mv64xxx: refactor message start to ensure proper initialization
From: Wolfram Sang @ 2014-02-13 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392323793-4125-1-git-send-email-wsa@the-dreams.de>
Because the offload mechanism can fall back to a standard transfer,
having two seperate initialization states is unfortunate. Let's just
have one state which does things consistently. This fixes a bug where
some preparation was missing when the fallback happened. And it makes
the code much easier to follow.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
drivers/i2c/busses/i2c-mv64xxx.c | 27 ++++++++++-----------------
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index ba64978..d52d849 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -97,7 +97,6 @@ enum {
enum {
MV64XXX_I2C_ACTION_INVALID,
MV64XXX_I2C_ACTION_CONTINUE,
- MV64XXX_I2C_ACTION_OFFLOAD_SEND_START,
MV64XXX_I2C_ACTION_SEND_START,
MV64XXX_I2C_ACTION_SEND_RESTART,
MV64XXX_I2C_ACTION_OFFLOAD_RESTART,
@@ -460,15 +459,14 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
drv_data->reg_base + drv_data->reg_offsets.control);
break;
- case MV64XXX_I2C_ACTION_OFFLOAD_SEND_START:
- if (!mv64xxx_i2c_offload_msg(drv_data))
- break;
- else
- drv_data->action = MV64XXX_I2C_ACTION_SEND_START;
- /* FALLTHRU */
case MV64XXX_I2C_ACTION_SEND_START:
- writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_START,
- drv_data->reg_base + drv_data->reg_offsets.control);
+ /* Can we offload this msg ? */
+ if (mv64xxx_i2c_offload_msg(drv_data) < 0) {
+ /* No, switch to standard path */
+ mv64xxx_i2c_prepare_for_io(drv_data, drv_data->msgs);
+ writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_START,
+ drv_data->reg_base + drv_data->reg_offsets.control);
+ }
break;
case MV64XXX_I2C_ACTION_SEND_ADDR_1:
@@ -627,15 +625,10 @@ mv64xxx_i2c_execute_msg(struct mv64xxx_i2c_data *drv_data, struct i2c_msg *msg,
unsigned long flags;
spin_lock_irqsave(&drv_data->lock, flags);
- if (drv_data->offload_enabled) {
- drv_data->action = MV64XXX_I2C_ACTION_OFFLOAD_SEND_START;
- drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_START_COND;
- } else {
- mv64xxx_i2c_prepare_for_io(drv_data, msg);
- drv_data->action = MV64XXX_I2C_ACTION_SEND_START;
- drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_START_COND;
- }
+ drv_data->action = MV64XXX_I2C_ACTION_SEND_START;
+ drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_START_COND;
+
drv_data->send_stop = is_last;
drv_data->block = 1;
mv64xxx_i2c_do_action(drv_data);
--
1.8.5.1
^ permalink raw reply related
* [PATCH 3/5] i2c: mv64xxx: refactor send_start
From: Wolfram Sang @ 2014-02-13 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392323793-4125-1-git-send-email-wsa@the-dreams.de>
For start and restart, we are doing the same thing. Let's consolidate
that.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
drivers/i2c/busses/i2c-mv64xxx.c | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index d52d849..9c37b59 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -419,6 +419,17 @@ mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 status)
}
}
+static void mv64xxx_i2c_send_start(struct mv64xxx_i2c_data *drv_data)
+{
+ /* Can we offload this msg ? */
+ if (mv64xxx_i2c_offload_msg(drv_data) < 0) {
+ /* No, switch to standard path */
+ mv64xxx_i2c_prepare_for_io(drv_data, drv_data->msgs);
+ writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_START,
+ drv_data->reg_base + drv_data->reg_offsets.control);
+ }
+}
+
static void
mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
{
@@ -435,14 +446,11 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
drv_data->msgs++;
drv_data->num_msgs--;
- if (mv64xxx_i2c_offload_msg(drv_data) < 0) {
- drv_data->cntl_bits |= MV64XXX_I2C_REG_CONTROL_START;
- writel(drv_data->cntl_bits,
- drv_data->reg_base + drv_data->reg_offsets.control);
+ // CHECKME: Does it work? Order of writel and prepare_for_io is
+ // exchanged. Also, do we need to change cntl_bits in drv_data
+ // with |= MV64XXX_I2C_REG_CONTROL_START?
+ mv64xxx_i2c_send_start(drv_data);
- /* Setup for the next message */
- mv64xxx_i2c_prepare_for_io(drv_data, drv_data->msgs);
- }
if (drv_data->errata_delay)
udelay(5);
@@ -460,13 +468,7 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
break;
case MV64XXX_I2C_ACTION_SEND_START:
- /* Can we offload this msg ? */
- if (mv64xxx_i2c_offload_msg(drv_data) < 0) {
- /* No, switch to standard path */
- mv64xxx_i2c_prepare_for_io(drv_data, drv_data->msgs);
- writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_START,
- drv_data->reg_base + drv_data->reg_offsets.control);
- }
+ mv64xxx_i2c_send_start(drv_data);
break;
case MV64XXX_I2C_ACTION_SEND_ADDR_1:
--
1.8.5.1
^ permalink raw reply related
* [PATCH 4/5] i2c: mv64xxx: directly call send_start when initializing transfer
From: Wolfram Sang @ 2014-02-13 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392323793-4125-1-git-send-email-wsa@the-dreams.de>
Calling the state machine with a definite state which is only used in
this context is superfluous. Do it directly.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
drivers/i2c/busses/i2c-mv64xxx.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 9c37b59..3af5266 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -97,7 +97,6 @@ enum {
enum {
MV64XXX_I2C_ACTION_INVALID,
MV64XXX_I2C_ACTION_CONTINUE,
- MV64XXX_I2C_ACTION_SEND_START,
MV64XXX_I2C_ACTION_SEND_RESTART,
MV64XXX_I2C_ACTION_OFFLOAD_RESTART,
MV64XXX_I2C_ACTION_SEND_ADDR_1,
@@ -467,10 +466,6 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
drv_data->reg_base + drv_data->reg_offsets.control);
break;
- case MV64XXX_I2C_ACTION_SEND_START:
- mv64xxx_i2c_send_start(drv_data);
- break;
-
case MV64XXX_I2C_ACTION_SEND_ADDR_1:
writel(drv_data->addr1,
drv_data->reg_base + drv_data->reg_offsets.data);
@@ -628,12 +623,11 @@ mv64xxx_i2c_execute_msg(struct mv64xxx_i2c_data *drv_data, struct i2c_msg *msg,
spin_lock_irqsave(&drv_data->lock, flags);
- drv_data->action = MV64XXX_I2C_ACTION_SEND_START;
drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_START_COND;
drv_data->send_stop = is_last;
drv_data->block = 1;
- mv64xxx_i2c_do_action(drv_data);
+ mv64xxx_i2c_send_start(drv_data);
spin_unlock_irqrestore(&drv_data->lock, flags);
mv64xxx_i2c_wait_for_completion(drv_data);
--
1.8.5.1
^ permalink raw reply related
* [PATCH 5/5] i2c: mv64xxx: refactor initialization for new msgs
From: Wolfram Sang @ 2014-02-13 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392323793-4125-1-git-send-email-wsa@the-dreams.de>
We now have a central place to put this code to.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
drivers/i2c/busses/i2c-mv64xxx.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 3af5266..be4b0a1 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -175,11 +175,6 @@ mv64xxx_i2c_prepare_for_io(struct mv64xxx_i2c_data *drv_data,
{
u32 dir = 0;
- drv_data->msg = msg;
- drv_data->byte_posn = 0;
- drv_data->bytes_left = msg->len;
- drv_data->aborting = 0;
- drv_data->rc = 0;
drv_data->cntl_bits = MV64XXX_I2C_REG_CONTROL_ACK |
MV64XXX_I2C_REG_CONTROL_INTEN | MV64XXX_I2C_REG_CONTROL_TWSIEN;
@@ -205,11 +200,6 @@ static int mv64xxx_i2c_offload_msg(struct mv64xxx_i2c_data *drv_data)
if (!drv_data->offload_enabled)
return -EOPNOTSUPP;
- drv_data->msg = msg;
- drv_data->byte_posn = 0;
- drv_data->bytes_left = msg->len;
- drv_data->aborting = 0;
- drv_data->rc = 0;
/* Only regular transactions can be offloaded */
if ((msg->flags & ~(I2C_M_TEN | I2C_M_RD)) != 0)
return -EINVAL;
@@ -420,6 +410,12 @@ mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 status)
static void mv64xxx_i2c_send_start(struct mv64xxx_i2c_data *drv_data)
{
+ drv_data->msg = drv_data->msgs;
+ drv_data->byte_posn = 0;
+ drv_data->bytes_left = drv_data->msg->len;
+ drv_data->aborting = 0;
+ drv_data->rc = 0;
+
/* Can we offload this msg ? */
if (mv64xxx_i2c_offload_msg(drv_data) < 0) {
/* No, switch to standard path */
--
1.8.5.1
^ permalink raw reply related
* [PATCH 0/5] mv64xxx updates
From: Gregory CLEMENT @ 2014-02-13 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392323793-4125-1-git-send-email-wsa@the-dreams.de>
Hi Wolfram,
On 13/02/2014 21:36, Wolfram Sang wrote:
> So, this is a series I came up with trying to fix the issue found by Kevin.
> Patches 1+2 are hopefully fixing the bug (in theory, I don't have the HW).
> Patches 3-5 are RFC, and if patch 3 actually works (see the CHECKME), then 4+5
> are further cleanup possibilities. And there is still more potential, I mainly
> wanted to give some inspiration and awareness that the driver could need some
> more love. Please test at least 1+2, comments to 3-5 very welcome.
>
> Sorry for the delay, I got distracted by an NMI.
>
Thanks for this series, indeed the code looks better.
I will test it tomorrow and let you know if it fixed the bug.
I will also take time to review the RFC patches.
Greogry
> Wolfram Sang (5):
> i2c: mv64xxx: put offload check into offload prepare function
> i2c: mv64xxx: refactor message start to ensure proper initialization
> i2c: mv64xxx: refactor send_start
> i2c: mv64xxx: directly call send_start when initializing transfer
> i2c: mv64xxx: refactor initialization for new msgs
>
> drivers/i2c/busses/i2c-mv64xxx.c | 67 ++++++++++++++++------------------------
> 1 file changed, 27 insertions(+), 40 deletions(-)
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
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