* [PATCH V2 0/2] ARM: bcm2835: Fix names for the Raspberry Pi GPIO lines
From: Stefan Wahren @ 2016-11-16 17:52 UTC (permalink / raw)
To: linux-arm-kernel
This patch series should fix and extend the patch V4 "ARM: bcm2835: Add names
for the Raspberry Pi GPIO lines" from Linus Walleij and Eric Anholt.
Changes in V2:
- fix URL to firmware DT blob
- drop dtsi file since Model A+ and Zero aren't identical
Stefan Wahren (2):
ARM: bcm2835: Fix names for the Raspberry Pi GPIO lines
ARM: bcm2835: Add names for the RPi Zero GPIO lines
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 4 +-
arch/arm/boot/dts/bcm2835-rpi-a.dts | 4 +-
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 2 +-
arch/arm/boot/dts/bcm2835-rpi-b.dts | 4 +-
arch/arm/boot/dts/bcm2835-rpi-zero.dts | 65 ++++++++++++++++++++++++++++++
5 files changed, 72 insertions(+), 7 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v2] input: touchscreen: silead: Add regulator support
From: Dmitry Torokhov @ 2016-11-16 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116115507.24220-1-hdegoede@redhat.com>
On Wed, Nov 16, 2016 at 12:55:07PM +0100, Hans de Goede wrote:
> On some tablets the touchscreen controller is powered by separate
> regulators, add support for this.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Changes in v2:
> -Use devm_regulator_bulk_get() and friends
> -Use devm_add_action_or_reset() to disable the regulator
> ---
> .../bindings/input/touchscreen/silead_gsl1680.txt | 2 ++
> drivers/input/touchscreen/silead.c | 29 ++++++++++++++++++++++
> 2 files changed, 31 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> index e844c3f..b726823 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> @@ -22,6 +22,8 @@ Optional properties:
> - touchscreen-inverted-y : See touchscreen.txt
> - touchscreen-swapped-x-y : See touchscreen.txt
> - silead,max-fingers : maximum number of fingers the touchscreen can detect
> +- vddio-supply : regulator phandle for controller VDDIO
> +- avdd-supply : regulator phandle for controller AVDD
>
> Example:
>
> diff --git a/drivers/input/touchscreen/silead.c b/drivers/input/touchscreen/silead.c
> index f502c84..404830a 100644
> --- a/drivers/input/touchscreen/silead.c
> +++ b/drivers/input/touchscreen/silead.c
> @@ -29,6 +29,7 @@
> #include <linux/input/touchscreen.h>
> #include <linux/pm.h>
> #include <linux/irq.h>
> +#include <linux/regulator/consumer.h>
>
> #include <asm/unaligned.h>
>
> @@ -73,6 +74,7 @@ struct silead_ts_data {
> struct i2c_client *client;
> struct gpio_desc *gpio_power;
> struct input_dev *input;
> + struct regulator_bulk_data regulators[2];
> char fw_name[64];
> struct touchscreen_properties prop;
> u32 max_fingers;
> @@ -433,6 +435,13 @@ static int silead_ts_set_default_fw_name(struct silead_ts_data *data,
> }
> #endif
>
> +static void silead_disable_regulator(void *arg)
> +{
> + struct silead_ts_data *data = arg;
> +
> + regulator_bulk_disable(ARRAY_SIZE(data->regulators), data->regulators);
> +}
> +
> static int silead_ts_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -465,6 +474,26 @@ static int silead_ts_probe(struct i2c_client *client,
> if (client->irq <= 0)
> return -ENODEV;
>
> + data->regulators[0].supply = "vddio";
> + data->regulators[1].supply = "avdd";
> + error = devm_regulator_bulk_get(dev, ARRAY_SIZE(data->regulators),
> + data->regulators);
> + if (error)
> + return error;
> +
> + /*
> + * Enable regulators at probe and disable them at remove, we need
> + * to keep the chip powered otherwise it forgets its firmware.
> + */
Hmm, this burns power though. Why can't we reload firmware on resume (it
should be already cached)? Does it take too long?
Thanks.
> + error = regulator_bulk_enable(ARRAY_SIZE(data->regulators),
> + data->regulators);
> + if (error)
> + return error;
> +
> + error = devm_add_action_or_reset(dev, silead_disable_regulator, data);
> + if (error)
> + return error;
> +
> /* Power GPIO pin */
> data->gpio_power = devm_gpiod_get_optional(dev, "power", GPIOD_OUT_LOW);
> if (IS_ERR(data->gpio_power)) {
> --
> 2.9.3
>
--
Dmitry
^ permalink raw reply
* Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'
From: Guenter Roeck @ 2016-11-16 17:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
my 'sabrelite' and 'imx25-pdk' qemu boot tests are failing in linux-next.
Bisect for the sabrelite failure points to commit 'ARM: dts: imx: Remove skeleton.dtsi'.
Bisect log is attached. Complete test logs are at
http://kerneltests.org/builders/qemu-arm-next/builds/571/steps/qemubuildcommand/logs/stdio
Boot log for imx25-pdk:
qemu-system-arm: findnode_nofail Couldn't find node /chosen: FDT_ERR_NOTFOUND
Boot log for sabrelite:
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.9.0-rc5-next-20161116 (groeck at jupiter.roeck-us.net) (gcc version 4.9.2 (GCC) ) #1 SMP Tue Nov 15 22:34:35 PST 2016
[ 0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[ 0.000000] OF: fdt:Machine model: Freescale i.MX6 DualLite SABRE Lite Board
[ 0.000000] earlycon: ec_imx21 at MMIO 0x021e8000 (options '')
[ 0.000000] bootconsole [ec_imx21] enabled
[ 0.000000] INITRD: 0x14000000+0x00501600 is not a memory region - disabling initrd
[ 0.000000] cma: Failed to reserve 64 MiB
[ 0.000000] Memory policy: Data cache writeback
[ stuck here until aborted ]
Build is imx_v6_v7_defconfig and multi_v7_defconfig with imx6dl-sabrelite.dtb,
and imx_v4_v5_defconfig with imx25-pdk.dtb.
Any idea what might be wrong ?
Thanks,
Guenter
-------
# bad: [56c0dbc6eced261af328afd3335d62234bc56513] Add linux-next specific files for 20161116
# good: [a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6] Linux 4.9-rc5
git bisect start 'HEAD' 'v4.9-rc5'
# bad: [56abc46730bb1c5ffd960c71ae089cb713e85e47] Merge remote-tracking branch 'drm/drm-next'
git bisect bad 56abc46730bb1c5ffd960c71ae089cb713e85e47
# bad: [c0d79c892333b32ddae50bbadd885413b51f7252] Merge remote-tracking branch 'dlm/next'
git bisect bad c0d79c892333b32ddae50bbadd885413b51f7252
# bad: [4763d380325df1d74bf3891b00fd318d4a44feee] Merge remote-tracking branch 'renesas/next'
git bisect bad 4763d380325df1d74bf3891b00fd318d4a44feee
# good: [19be51760fbe79fc5926c455546971bd1412b9cf] Merge remote-tracking branch 'pinctrl/for-next'
git bisect good 19be51760fbe79fc5926c455546971bd1412b9cf
# bad: [c07b71c4ddd300095d39b74da58f0e70b7931f1d] Merge remote-tracking branch 'mvebu/for-next'
git bisect bad c07b71c4ddd300095d39b74da58f0e70b7931f1d
# bad: [242a001e48b78f190d18242132cab73527ca06a4] Merge branch 'zte/dt64' into for-next
git bisect bad 242a001e48b78f190d18242132cab73527ca06a4
# bad: [c201369d4aa5f05b8a37d6d1eeabf248c7086454] ARM: dts: imx6ull: add imx6ull support
git bisect bad c201369d4aa5f05b8a37d6d1eeabf248c7086454
# good: [9daee307694027eac4b10baa9cd3f2070f7459ba] ARM: dts: imx6q: Add Engicam i.CoreM6 DualLite/Solo initial support
git bisect good 9daee307694027eac4b10baa9cd3f2070f7459ba
# good: [67cb5d52ea2c3ae35d637ab79a46cd452d1c7d41] ARM: dts: imx6sx-sdb: update TX D_CAL for USBPHY
git bisect good 67cb5d52ea2c3ae35d637ab79a46cd452d1c7d41
# good: [c4479f6f57a0821aae4f6ab6a91a23625d6b35a0] ARM: dts: add new compatible string for i.MX6QP mmdc
git bisect good c4479f6f57a0821aae4f6ab6a91a23625d6b35a0
# bad: [7f107887d1995c819389f292828097cac4ec4396] ARM: dts: imx: Remove skeleton.dtsi
git bisect bad 7f107887d1995c819389f292828097cac4ec4396
# good: [425dd2773ed07d1ba21d4ada0f9a9abc85b75151] ARM: dts: imx6q-utilite-pro: i2c1 is muxed
git bisect good 425dd2773ed07d1ba21d4ada0f9a9abc85b75151
# first bad commit: [7f107887d1995c819389f292828097cac4ec4396] ARM: dts: imx: Remove skeleton.dtsi
^ permalink raw reply
* [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash
From: Jagan Teki @ 2016-11-16 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1471505884-33996-6-git-send-email-B56489@freescale.com>
On Thu, Aug 18, 2016 at 1:08 PM, Yunhui Cui <B56489@freescale.com> wrote:
> From: Yunhui Cui <yunhui.cui@nxp.com>
>
> With the physical sectors combination, S25FS-S family flash
> requires some special operations for read/write functions.
>
> Signed-off-by: Yunhui Cui <yunhui.cui@nxp.com>
> ---
> drivers/mtd/spi-nor/spi-nor.c | 56 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 56 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index d0fc165..495d0bb 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -39,6 +39,10 @@
>
> #define SPI_NOR_MAX_ID_LEN 6
> #define SPI_NOR_MAX_ADDR_WIDTH 4
> +/* Added for S25FS-S family flash */
> +#define SPINOR_CONFIG_REG3_OFFSET 0x800004
> +#define CR3V_4KB_ERASE_UNABLE 0x8
> +#define SPINOR_S25FS_FAMILY_EXT_JEDEC 0x81
>
> struct flash_info {
> char *name;
> @@ -78,6 +82,7 @@ struct flash_info {
> };
>
> #define JEDEC_MFR(info) ((info)->id[0])
> +#define EXT_JEDEC(info) ((info)->id[5])
>
> static const struct flash_info *spi_nor_match_id(const char *name);
>
> @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] = {
> */
> { "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024, 64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024, 128, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> + { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024, 512, 0)},
Handling normal and parameter sectors on specific chip part look quite
messy, and this patch[1] will erase SECT_4K by seeing whole flash as
normal sectors.
[1] https://patchwork.kernel.org/patch/9266541/
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Catalin Marinas @ 2016-11-16 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95d1f7bb-d451-3b0a-1a32-957a24023a49@redhat.com>
On Tue, Nov 15, 2016 at 04:09:07PM -0800, Laura Abbott wrote:
> On 11/15/2016 10:35 AM, Catalin Marinas wrote:
> > I'm fine with __pa_symbol use entirely from under arch/arm64. But if you
> > want to use __pa_symbol, I tried to change most (all?) places where
> > necessary, together with making virt_to_phys() only deal with the kernel
> > linear mapping. Not sure it looks cleaner, especially the
> > __va(__pa_symbol()) cases (we could replace the latter with another
> > macro and proper comment):
>
> I agree everything should be converted over, I was considering doing
> that in a separate patch but this covers everything nicely. Are you
> okay with me folding this in? (Few comments below)
Yes. I would also like Ard to review it since he introduced the current
__virt_to_phys() macro.
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index eac3dbb7e313..e02f45e5ee1b 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -169,15 +169,22 @@ extern u64 kimage_voffset;
> > */
> > #define __virt_to_phys_nodebug(x) ({ \
> > phys_addr_t __x = (phys_addr_t)(x); \
> > - __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
> > - (__x - kimage_voffset); })
> > + VM_BUG_ON(!(__x & BIT(VA_BITS - 1))); \
> > + ((__x & ~PAGE_OFFSET) + PHYS_OFFSET); \
> > +})
>
> I do think this is easier to understand vs the ternary operator.
> I'll add a comment detailing the use of __pa vs __pa_symbol somewhere
> as well.
Of course, a comment is welcome (I just did a quick hack to check that
it works).
> > --- a/arch/arm64/include/asm/mmu_context.h
> > +++ b/arch/arm64/include/asm/mmu_context.h
> > @@ -44,7 +44,7 @@ static inline void contextidr_thread_switch(struct task_struct *next)
> > */
> > static inline void cpu_set_reserved_ttbr0(void)
> > {
> > - unsigned long ttbr = virt_to_phys(empty_zero_page);
> > + unsigned long ttbr = __pa_symbol(empty_zero_page);
> >
> > write_sysreg(ttbr, ttbr0_el1);
> > isb();
> > @@ -113,7 +113,7 @@ static inline void cpu_install_idmap(void)
> > local_flush_tlb_all();
> > cpu_set_idmap_tcr_t0sz();
> >
> > - cpu_switch_mm(idmap_pg_dir, &init_mm);
> > + cpu_switch_mm(__va(__pa_symbol(idmap_pg_dir)), &init_mm);
>
> Yes, the __va(__pa_symbol(..)) idiom needs to be macroized and commented...
Indeed. At the same time we should also replace the LMADDR macro in
hibernate.c with whatever you come up with.
> > diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> > index d55a7b09959b..81c03c74e5fe 100644
> > --- a/arch/arm64/kernel/hibernate.c
> > +++ b/arch/arm64/kernel/hibernate.c
> > @@ -51,7 +51,7 @@
> > extern int in_suspend;
> >
> > /* Find a symbols alias in the linear map */
> > -#define LMADDR(x) phys_to_virt(virt_to_phys(x))
> > +#define LMADDR(x) __va(__pa_symbol(x))
>
> ...Perhaps just borrowing this macro?
Yes but I don't particularly like the name, especially since it goes
into a .h file. Maybe __lm_sym_addr() or something else if you have a
better idea.
> > diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
> > index 874c78201a2b..98dae943e496 100644
> > --- a/arch/arm64/mm/physaddr.c
> > +++ b/arch/arm64/mm/physaddr.c
> > @@ -14,8 +14,8 @@ unsigned long __virt_to_phys(unsigned long x)
> > */
> > return (__x & ~PAGE_OFFSET) + PHYS_OFFSET;
> > } else {
> > - VIRTUAL_BUG_ON(x < kimage_vaddr || x >= (unsigned long)_end);
> > - return (__x - kimage_voffset);
> > + WARN_ON(1);
>
> Was the deletion of the BUG_ON here intentional? VIRTUAL_BUG_ON
> is the check enabled by CONFIG_DEBUG_VIRTUAL vs just CONFIG_DEBUG_VM.
> I intentionally kept CONFIG_DEBUG_VIRTUAL separate since the checks
> are expensive.
I wanted to always get a warning but fall back to __phys_addr_symbol()
so that I can track down other uses of __virt_to_phys() on kernel
symbols without killing the kernel. A better option would have been
VIRTUAL_WARN_ON (or *_ONCE) but we don't have it. VM_WARN_ON, as you
said, is independent of CONFIG_DEBUG_VIRTUAL.
We could as well kill the system with VIRTUAL_BUG_ON in this case but I
thought we should be more gentle until all the __virt_to_phys use-cases
are sorted out.
--
Catalin
^ permalink raw reply
* [PATCH 2/2] arm64: dts: juno: fix cluster sleep state entry latency on all SoC versions
From: Sudeep Holla @ 2016-11-16 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479317491-7435-1-git-send-email-sudeep.holla@arm.com>
The core and the cluster sleep state entry latencies can't be same as
cluster sleep involves more work compared to core level e.g. shared
cache maintenance.
Experiments have shown on an average about 100us more latency for the
cluster sleep state compared to the core level sleep. This patch fixes
the entry latency for the cluster sleep state.
Fixes: 28e10a8f3a03 ("arm64: dts: juno: Add idle-states to device tree")
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: "Jon Medhurst (Tixy)" <tixy@linaro.org>
Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/boot/dts/arm/juno-r1.dts | 2 +-
arch/arm64/boot/dts/arm/juno-r2.dts | 2 +-
arch/arm64/boot/dts/arm/juno.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
index 123a58b29cbd..f0b857d6d73c 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -76,7 +76,7 @@
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x1010000>;
local-timer-stop;
- entry-latency-us = <300>;
+ entry-latency-us = <400>;
exit-latency-us = <1200>;
min-residency-us = <2500>;
};
diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts
index 007be826efce..26aaa6a7670f 100644
--- a/arch/arm64/boot/dts/arm/juno-r2.dts
+++ b/arch/arm64/boot/dts/arm/juno-r2.dts
@@ -76,7 +76,7 @@
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x1010000>;
local-timer-stop;
- entry-latency-us = <300>;
+ entry-latency-us = <400>;
exit-latency-us = <1200>;
min-residency-us = <2500>;
};
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index a7270eff6939..6e154d948a80 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -76,7 +76,7 @@
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x1010000>;
local-timer-stop;
- entry-latency-us = <300>;
+ entry-latency-us = <400>;
exit-latency-us = <1200>;
min-residency-us = <2500>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] bus: vexpress-config: fix device reference leak
From: Sudeep Holla @ 2016-11-16 17:31 UTC (permalink / raw)
To: linux-arm-kernel
From: Johan Hovold <johan@kernel.org>
Make sure to drop the reference to the parent device taken by
class_find_device() after populating the bus.
Fixes: 3b9334ac835b ("mfd: vexpress: Convert custom func API to regmap")
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/bus/vexpress-config.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Hi ARM-SoC team,
I am not sure if these couple of patches can be considered as fixes for
v4.9. I will leave that to you guys.
Can you pick these couple of patches directly either for v4.9 or v4.10 ?
I am trying to avoid single patch pull requests here. Let me know if
you prefer PR instead.
Regards,
Sudeep
diff --git a/drivers/bus/vexpress-config.c b/drivers/bus/vexpress-config.c
index 9efdf1de4035..493e7b9fc813 100644
--- a/drivers/bus/vexpress-config.c
+++ b/drivers/bus/vexpress-config.c
@@ -171,6 +171,7 @@ static int vexpress_config_populate(struct device_node *node)
{
struct device_node *bridge;
struct device *parent;
+ int ret;
bridge = of_parse_phandle(node, "arm,vexpress,config-bridge", 0);
if (!bridge)
@@ -182,7 +183,11 @@ static int vexpress_config_populate(struct device_node *node)
if (WARN_ON(!parent))
return -ENODEV;
- return of_platform_populate(node, NULL, NULL, parent);
+ ret = of_platform_populate(node, NULL, NULL, parent);
+
+ put_device(parent);
+
+ return ret;
}
static int __init vexpress_config_init(void)
--
2.7.4
^ permalink raw reply related
* [PATCH 0/8] DMA: s3c64xx: Conversion to the new channel request API
From: Sylwester Nawrocki @ 2016-11-16 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116170337.GA4124@kozik-lap>
On 11/16/2016 06:03 PM, Krzysztof Kozlowski wrote:
> As I understood, everything won't be applied because ASoC tree already
> contains some work around this?
Yes, sorry, I didn't coordinate this work very well, there are some patches
for the pcm and the i2s driver already in the ASoC tree which would conflict
with this series. I'd suggest to ignore patches 5/8...8/8 for now.
--
Thanks,
Sylwester
^ permalink raw reply
* [PATCH v4 4/4] ARM: dts: da850: Add the usb otg device nodeg
From: Bin Liu @ 2016-11-16 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9a73c416-fe4c-57c3-af53-87146dae2206@ti.com>
On Wed, Nov 16, 2016 at 12:06:51PM +0530, Sekhar Nori wrote:
> On Wednesday 16 November 2016 02:49 AM, Bin Liu wrote:
> > On Tue, Nov 15, 2016 at 04:16:02PM +0530, Sekhar Nori wrote:
> >> On Thursday 03 November 2016 09:29 PM, Alexandre Bailon wrote:
> >>> This adds the device tree node for the usb otg
> >>> controller present in the da850 family of SoC's.
> >>> This also enables the otg usb controller for the lcdk board.
> >>>
> >>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
> >>> ---
> >>> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
> >>> arch/arm/boot/dts/da850.dtsi | 15 +++++++++++++++
> >>> 2 files changed, 23 insertions(+)
> >>>
> >>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
> >>> index 7b8ab21..9f5040c 100644
> >>> --- a/arch/arm/boot/dts/da850-lcdk.dts
> >>> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> >>> @@ -158,6 +158,14 @@
> >>> rx-num-evt = <32>;
> >>> };
> >>>
> >>> +&usb_phy {
> >>> + status = "okay";
> >>> + };
> >>
> >> As mentioned by David already, this node needs to be removed. Please
> >> rebase this on top of latest linux-davinci/master when ready for merging
> >> (driver changes accepted).
> >
> > Dropped this patch due to this comment.
>
> Bin, Please do not apply dts or arch/arm/mach-davinci patches. I have a
> bunch queued through my tree and more in pipeline and it will cause
> unnecessary merge conflicts in linux-next or at Linus.
Sure, I will drop this whole set, and only apply the musb patches in the
new v5.
>
> For future, I have asked Alexandre to send driver and dts patches as
> separate series so there is no confusion on who should apply.
I will keep in mind to ping other domain maintainers before applying
non-musb patches in future.
>
> Thanks,
> Sekhar
Regards,
-Bin.
^ permalink raw reply
* [PATCH 2/5] drm/modes: Support modes names on the command line
From: Sean Paul @ 2016-11-16 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <853193fdf9ec1af94056d9fa2c276079c779aaf4.1476779323.git-series.maxime.ripard@free-electrons.com>
On Tue, Oct 18, 2016 at 4:29 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The drm subsystem also uses the video= kernel parameter, and in the
> documentation refers to the fbdev documentation for that parameter.
>
> However, that documentation also says that instead of giving the mode using
> its resolution we can also give a name. However, DRM doesn't handle that
> case at the moment. Even though in most case it shouldn't make any
> difference, it might be useful for analog modes, where different standards
> might have the same resolution, but still have a few different parameters
> that are not encoded in the modes (NTSC vs NTSC-J vs PAL-M for example).
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/gpu/drm/drm_connector.c | 3 +-
> drivers/gpu/drm/drm_fb_helper.c | 4 +++-
> drivers/gpu/drm/drm_modes.c | 49 +++++++++++++++++++++++-----------
> include/drm/drm_connector.h | 1 +-
> 4 files changed, 41 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 2db7fb510b6c..27a8a511257c 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -147,8 +147,9 @@ static void drm_connector_get_cmdline_mode(struct drm_connector *connector)
> connector->force = mode->force;
> }
>
> - DRM_DEBUG_KMS("cmdline mode for connector %s %dx%d@%dHz%s%s%s\n",
> + DRM_DEBUG_KMS("cmdline mode for connector %s %s %dx%d@%dHz%s%s%s\n",
> connector->name,
> + mode->name ? mode->name : "",
> mode->xres, mode->yres,
> mode->refresh_specified ? mode->refresh : 60,
> mode->rb ? " reduced blanking" : "",
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 03414bde1f15..20a68305fb45 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1748,6 +1748,10 @@ struct drm_display_mode *drm_pick_cmdline_mode(struct drm_fb_helper_connector *f
> prefer_non_interlace = !cmdline_mode->interlace;
> again:
> list_for_each_entry(mode, &fb_helper_conn->connector->modes, head) {
> + /* Check (optional) mode name first */
> + if (!strcmp(mode->name, cmdline_mode->name))
> + return mode;
> +
> /* check width/height */
> if (mode->hdisplay != cmdline_mode->xres ||
> mode->vdisplay != cmdline_mode->yres)
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 7d5bdca276f2..fdbf541a5978 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1413,7 +1413,7 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option,
> struct drm_cmdline_mode *mode)
> {
> const char *name;
> - bool parse_extras = false;
> + bool named_mode = false, parse_extras = false;
> unsigned int bpp_off = 0, refresh_off = 0;
> unsigned int mode_end = 0;
> char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
> @@ -1432,8 +1432,14 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option,
>
> name = mode_option;
>
> + /*
> + * If the first character is not a digit, then it means that
> + * we have a named mode.
> + */
> if (!isdigit(name[0]))
> - return false;
> + named_mode = true;
> + else
> + named_mode = false;
named_mode = isalpha(name[0]); might be more succinct (and covers
special characters).
>
> /* Try to locate the bpp and refresh specifiers, if any */
> bpp_ptr = strchr(name, '-');
> @@ -1460,12 +1466,16 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option,
> parse_extras = true;
> }
>
> - ret = drm_mode_parse_cmdline_res_mode(name, mode_end,
> - parse_extras,
> - connector,
> - mode);
> - if (ret)
> - return false;
> + if (named_mode) {
> + strncpy(mode->name, name, mode_end);
> + } else {
> + ret = drm_mode_parse_cmdline_res_mode(name, mode_end,
> + parse_extras,
> + connector,
> + mode);
> + if (ret)
> + return false;
> + }
> mode->specified = true;
>
> if (bpp_ptr) {
> @@ -1493,14 +1503,23 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option,
> extra_ptr = refresh_end_ptr;
>
> if (extra_ptr) {
> - int remaining = strlen(name) - (extra_ptr - name);
> + if (!named_mode) {
> + int len = strlen(name) - (extra_ptr - name);
>
> - /*
> - * We still have characters to process, while
> - * we shouldn't have any
> - */
> - if (remaining > 0)
> - return false;
> + ret = drm_mode_parse_cmdline_extra(extra_ptr, len,
> + connector, mode);
> + if (ret)
> + return false;
> + } else {
> + int remaining = strlen(name) - (extra_ptr - name);
> +
> + /*
> + * We still have characters to process, while
> + * we shouldn't have any
> + */
> + if (remaining > 0)
> + return false;
Correct me if I'm wrong, but this shouldn't ever happen. AFAICT, the
only way it could would be if we parsed bpp or refresh in the named
mode (since those are the only cases where we don't copy the whole
string over). Shouldn't that be invalid anyways?
Perhaps you can just avoid all of this code and just do a
strcpy/return when you first detect a named mode.
Sean
> + }
> }
>
> return true;
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index ac9d7d8e0e43..dce3d4b2fd33 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -485,6 +485,7 @@ struct drm_connector_funcs {
>
> /* mode specified on the command line */
> struct drm_cmdline_mode {
> + char name[DRM_DISPLAY_MODE_LEN];
> bool specified;
> bool refresh_specified;
> bool bpp_specified;
> --
> git-series 0.8.10
^ permalink raw reply
* [PATCH V7 1/3] ACPI: Retry IRQ conversion if it failed previously
From: Lorenzo Pieralisi @ 2016-11-16 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0b6358b4c723bb08623c322051bb4c77@codeaurora.org>
On Tue, Nov 15, 2016 at 12:43:38PM -0500, Agustin Vega-Frias wrote:
> Hi Lorenzo,
>
> On 2016-11-15 10:48, Lorenzo Pieralisi wrote:
> >On Sun, Nov 13, 2016 at 04:59:33PM -0500, Agustin Vega-Frias wrote:
> >>This allows probe deferral to work properly when a dependent device
> >>fails to get a valid IRQ because the IRQ domain was not registered
> >>at the time the resources were added to the platform_device.
> >>
> >>Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
> >>---
> >> drivers/acpi/resource.c | 59
> >>+++++++++++++++++++++++++++++++++++++++++++++++++
> >> drivers/base/platform.c | 9 +++++++-
> >> include/linux/acpi.h | 7 ++++++
> >> 3 files changed, 74 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> >>index 56241eb..4beda15 100644
> >>--- a/drivers/acpi/resource.c
> >>+++ b/drivers/acpi/resource.c
> >>@@ -664,3 +664,62 @@ int acpi_dev_filter_resource_type(struct
> >>acpi_resource *ares,
> >> return (type & types) ? 0 : 1;
> >> }
> >> EXPORT_SYMBOL_GPL(acpi_dev_filter_resource_type);
> >>+
> >>+struct acpi_irq_get_ctx {
> >>+ unsigned int index;
> >>+ struct resource *res;
> >>+};
> >>+
> >>+static acpi_status acpi_irq_get_cb(struct acpi_resource *ares,
> >>void *context)
> >>+{
> >>+ struct acpi_irq_get_ctx *ctx = context;
> >>+ struct acpi_resource_irq *irq;
> >>+ struct acpi_resource_extended_irq *ext_irq;
> >>+
> >>+ switch (ares->type) {
> >>+ case ACPI_RESOURCE_TYPE_IRQ:
> >>+ irq = &ares->data.irq;
> >>+ if (ctx->index < irq->interrupt_count) {
> >>+ acpi_dev_resource_interrupt(ares, ctx->index, ctx->res);
> >>+ return AE_CTRL_TERMINATE;
> >>+ }
> >>+ ctx->index -= irq->interrupt_count;
> >
> >I do not understand this code, mind explaining what it is meant to do ?
> >
> >In particular I do not understand the logic behind the index decrement,
> >I think I am missing something here.
> >
>
> ACPI IRQ resources can be encoded into two types of structures:
>
> struct acpi_resource_irq,
> struct acpi_resource_extended_irq.
>
> In theory only the extended version can contain multiple IRQs, but
> the Linux
> ACPI core accommodates non-compliant DSDT tables that have regular
> IRQ resources
> contain multiple IRQs.
>
> To better explain, suppose you have a device that handles two GSIs
> and one
> other IRQ form a separate device:
>
> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, 0x00, )
> { 130, 131 }
>
> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, 0x00,
> "\\_SB.TCS0.QIC0", )
> { 4 }
>
> These are encoded into two separate structures with their own
> interrupts array:
>
> res0.interrupts[] = { 130, 131 }
> res1.interrupts[] = { 4 }
>
> However, from the perspective of a client driver these are indexed
> into a flat space:
>
> [0] -> 130
> [1] -> 131
> [2] -> 4
>
> Now say mapping of IRQ 4 failed during bus scan. When acpi_irq_get
> retries to map it, the client code will pass index 2.
> acpi_walk_resources will call acpi_irq_get_cb with the first IRQ
> resource. If the index is less than the number of IRQs, we know this
> IRQ resource contains the IRQ we want so we call
> acpi_dev_resource_interrupt to do the actual mapping and return
> AE_CTRL_TERMINATE so acpi_walk_resources does not continue walking the
> resource buffer. On the other hand if the index is equal or larger it
> means we need to skip this IRQ resource and look at the next one, but
> we need to adjust the lookup index to that of the next IRQ resource.
>
> Makes sense?
Yes, basically it is to create a linear index out of multiple resources,
the DT case is simpler since you get the interrupt out of a single
property that we can easily index (ie we have to know which firmware
entry corresponds to the resource that we are retrying). That deserves
a comment.
Thanks for explaining.
Lorenzo
> >>+ break;
> >>+ case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
> >>+ ext_irq = &ares->data.extended_irq;
> >>+ if (ctx->index < ext_irq->interrupt_count) {
> >>+ acpi_dev_resource_interrupt(ares, ctx->index, ctx->res);
> >>+ return AE_CTRL_TERMINATE;
> >>+ }
> >>+ ctx->index -= ext_irq->interrupt_count;
> >
> >Ditto.
>
> The same logic is used for both types of resources because they are
> handled in
> the same way by the ACPI core when it comes to indexing.
>
> Thanks,
> Agustin
>
> >
> >Thanks,
> >Lorenzo
> >
> >>+ break;
> >>+ }
> >>+
> >>+ return AE_OK;
> >>+}
> >>+
> >>+/**
> >>+ * acpi_irq_get - Look for the ACPI IRQ resource with the given
> >>index and
> >>+ * use it to initialize the given Linux IRQ resource.
> >>+ * @handle ACPI device handle
> >>+ * @index ACPI IRQ resource index to lookup
> >>+ * @res Linux IRQ resource to initialize
> >>+ *
> >>+ * Return: 0 on success
> >>+ * -EINVAL if an error occurs
> >>+ * -EPROBE_DEFER if the IRQ lookup/conversion failed
> >>+ */
> >>+int acpi_irq_get(acpi_handle handle, unsigned int index, struct
> >>resource *res)
> >>+{
> >>+ struct acpi_irq_get_ctx ctx = { index, res };
> >>+ acpi_status status;
> >>+
> >>+ status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> >>+ acpi_irq_get_cb, &ctx);
> >>+ if (ACPI_FAILURE(status))
> >>+ return -EINVAL;
> >>+ if (res->flags & IORESOURCE_DISABLED)
> >>+ return -EPROBE_DEFER;
> >>+ return 0;
> >>+}
> >>+EXPORT_SYMBOL_GPL(acpi_irq_get);
> >>diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> >>index c4af003..61423d2 100644
> >>--- a/drivers/base/platform.c
> >>+++ b/drivers/base/platform.c
> >>@@ -102,6 +102,14 @@ int platform_get_irq(struct platform_device
> >>*dev, unsigned int num)
> >> }
> >>
> >> r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> >>+ if (r && r->flags & IORESOURCE_DISABLED &&
> >>ACPI_COMPANION(&dev->dev)) {
> >>+ int ret;
> >>+
> >>+ ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r);
> >>+ if (ret)
> >>+ return ret;
> >>+ }
> >>+
> >> /*
> >> * The resources may pass trigger flags to the irqs that need
> >> * to be set up. It so happens that the trigger flags for
> >>@@ -1450,4 +1458,3 @@ void __init early_platform_cleanup(void)
> >> memset(&pd->dev.devres_head, 0, sizeof(pd->dev.devres_head));
> >> }
> >> }
> >>-
> >>diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> >>index 689a8b9..325bdb9 100644
> >>--- a/include/linux/acpi.h
> >>+++ b/include/linux/acpi.h
> >>@@ -406,6 +406,7 @@ bool
> >>acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
> >> unsigned int acpi_dev_get_irq_type(int triggering, int polarity);
> >> bool acpi_dev_resource_interrupt(struct acpi_resource *ares,
> >>int index,
> >> struct resource *res);
> >>+int acpi_irq_get(acpi_handle handle, unsigned int index, struct
> >>resource *res);
> >>
> >> void acpi_dev_free_resource_list(struct list_head *list);
> >> int acpi_dev_get_resources(struct acpi_device *adev, struct
> >>list_head *list,
> >>@@ -763,6 +764,12 @@ static inline int
> >>acpi_reconfig_notifier_unregister(struct notifier_block *nb)
> >> return -EINVAL;
> >> }
> >>
> >>+static inline int acpi_irq_get(acpi_handle handle, unsigned int
> >>index,
> >>+ struct resource *res)
> >>+{
> >>+ return -EINVAL;
> >>+}
> >>+
> >> #endif /* !CONFIG_ACPI */
> >>
> >> #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
> >>--
> >>Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
> >>Technologies, Inc.
> >>Qualcomm Technologies, Inc. is a member of the Code Aurora
> >>Forum, a Linux Foundation Collaborative Project.
> >>
> >>--
> >>To unsubscribe from this list: send the line "unsubscribe
> >>linux-acpi" in
> >>the body of a message to majordomo at vger.kernel.org
> >>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
> Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
> Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 1/5] drm/modes: Rewrite the command line parser
From: Sean Paul @ 2016-11-16 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cf494b4e9585e720b2640705e3b2102c19d193c2.1476779323.git-series.maxime.ripard@free-electrons.com>
On Tue, Oct 18, 2016 at 4:29 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Rewrite the command line parser in order to get away from the state machine
> parsing the video mode lines.
>
> Hopefully, this will allow to extend it more easily to support named modes
> and / or properties set directly on the command line.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/gpu/drm/drm_modes.c | 305 +++++++++++++++++++++++--------------
> 1 file changed, 190 insertions(+), 115 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 53f07ac7c174..7d5bdca276f2 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -30,6 +30,7 @@
> * authorization from the copyright holder(s) and author(s).
> */
>
> +#include <linux/ctype.h>
> #include <linux/list.h>
> #include <linux/list_sort.h>
> #include <linux/export.h>
> @@ -1261,6 +1262,131 @@ void drm_mode_connector_list_update(struct drm_connector *connector)
> }
> EXPORT_SYMBOL(drm_mode_connector_list_update);
>
> +static int drm_mode_parse_cmdline_bpp(const char *str, char **end_ptr,
> + struct drm_cmdline_mode *mode)
> +{
> + if (str[0] != '-')
> + return -EINVAL;
> +
> + mode->bpp = simple_strtol(str + 1, end_ptr, 10);
> + mode->bpp_specified = true;
> +
> + return 0;
> +}
> +
> +static int drm_mode_parse_cmdline_refresh(const char *str, char **end_ptr,
> + struct drm_cmdline_mode *mode)
> +{
> + if (str[0] != '@')
> + return -EINVAL;
> +
> + mode->refresh = simple_strtol(str + 1, end_ptr, 10);
> + mode->refresh_specified = true;
> +
> + return 0;
> +}
> +
> +static int drm_mode_parse_cmdline_extra(const char *str, int length,
> + struct drm_connector *connector,
> + struct drm_cmdline_mode *mode)
> +{
> + int i;
> +
> + for (i = 0; i < length; i++) {
> + switch (str[i]) {
> + case 'i':
> + mode->interlace = true;
> + break;
> + case 'm':
> + mode->margins = true;
> + break;
> + case 'D':
> + if (mode->force != DRM_FORCE_UNSPECIFIED)
> + return -EINVAL;
> +
> + if ((connector->connector_type != DRM_MODE_CONNECTOR_DVII) &&
> + (connector->connector_type != DRM_MODE_CONNECTOR_HDMIB))
> + mode->force = DRM_FORCE_ON;
> + else
> + mode->force = DRM_FORCE_ON_DIGITAL;
> + break;
> + case 'd':
> + if (mode->force != DRM_FORCE_UNSPECIFIED)
> + return -EINVAL;
> +
> + mode->force = DRM_FORCE_OFF;
> + break;
> + case 'e':
> + if (mode->force != DRM_FORCE_UNSPECIFIED)
> + return -EINVAL;
> +
> + mode->force = DRM_FORCE_ON;
> + break;
> + default:
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int drm_mode_parse_cmdline_res_mode(const char *str, unsigned int length,
> + bool extras,
> + struct drm_connector *connector,
> + struct drm_cmdline_mode *mode)
> +{
> + bool rb = false, cvt = false;
> + int xres = 0, yres = 0;
> + int remaining, i;
> + char *end_ptr;
> +
> + xres = simple_strtol(str, &end_ptr, 10);
> +
checkpatch is telling me to use kstrtol instead, as simple_strtol is deprecated
> + if (end_ptr[0] != 'x')
check that end_ptr != NULL? you should probably also check that xres
isn't an error (ie: -ERANGE or -EINVAL)
> + return -EINVAL;
> + end_ptr++;
> +
> + yres = simple_strtol(end_ptr, &end_ptr, 10);
check end_ptr != NULL and yres sane
> +
> + remaining = length - (end_ptr - str);
> + if (remaining < 0)
right, so if end_ptr is NULL here, we'll end up with a huge positive
value for remaining :)
> + return -EINVAL;
> +
> + for (i = 0; i < remaining; i++) {
> + switch (end_ptr[i]) {
> + case 'M':
> + cvt = true;
the previous code ensured proper ordering as well as parsing, whereas
yours will take these in any order (and accepts duplicates). i don't
think this should cause any issues, but perhaps something to verify.
> + break;
> + case 'R':
> + rb = true;
> + break;
> + default:
> + /*
> + * Try to pass that to our extras parsing
> + * function to handle the case where the
> + * extras are directly after the resolution
> + */
> + if (extras) {
> + int ret = drm_mode_parse_cmdline_extra(end_ptr + i,
> + 1,
> + connector,
> + mode);
> + if (ret)
> + return ret;
> + } else {
> + return -EINVAL;
> + }
> + }
> + }
> +
> + mode->xres = xres;
> + mode->yres = yres;
> + mode->cvt = cvt;
> + mode->rb = rb;
> +
> + return 0;
> +}
> +
> /**
> * drm_mode_parse_command_line_for_connector - parse command line modeline for connector
> * @mode_option: optional per connector mode option
> @@ -1287,13 +1413,12 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option,
> struct drm_cmdline_mode *mode)
> {
> const char *name;
> - unsigned int namelen;
> - bool res_specified = false, bpp_specified = false, refresh_specified = false;
> - unsigned int xres = 0, yres = 0, bpp = 32, refresh = 0;
> - bool yres_specified = false, cvt = false, rb = false;
> - bool interlace = false, margins = false, was_digit = false;
> - int i;
> - enum drm_connector_force force = DRM_FORCE_UNSPECIFIED;
> + bool parse_extras = false;
> + unsigned int bpp_off = 0, refresh_off = 0;
> + unsigned int mode_end = 0;
> + char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
> + char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
> + int ret;
>
> #ifdef CONFIG_FB
> if (!mode_option)
> @@ -1306,127 +1431,77 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option,
> }
>
> name = mode_option;
> - namelen = strlen(name);
> - for (i = namelen-1; i >= 0; i--) {
> - switch (name[i]) {
> - case '@':
> - if (!refresh_specified && !bpp_specified &&
> - !yres_specified && !cvt && !rb && was_digit) {
> - refresh = simple_strtol(&name[i+1], NULL, 10);
> - refresh_specified = true;
> - was_digit = false;
> - } else
> - goto done;
> - break;
> - case '-':
> - if (!bpp_specified && !yres_specified && !cvt &&
> - !rb && was_digit) {
> - bpp = simple_strtol(&name[i+1], NULL, 10);
> - bpp_specified = true;
> - was_digit = false;
> - } else
> - goto done;
> - break;
> - case 'x':
> - if (!yres_specified && was_digit) {
> - yres = simple_strtol(&name[i+1], NULL, 10);
> - yres_specified = true;
> - was_digit = false;
> - } else
> - goto done;
> - break;
> - case '0' ... '9':
> - was_digit = true;
> - break;
> - case 'M':
> - if (yres_specified || cvt || was_digit)
> - goto done;
> - cvt = true;
> - break;
> - case 'R':
> - if (yres_specified || cvt || rb || was_digit)
> - goto done;
> - rb = true;
> - break;
> - case 'm':
> - if (cvt || yres_specified || was_digit)
> - goto done;
> - margins = true;
> - break;
> - case 'i':
> - if (cvt || yres_specified || was_digit)
> - goto done;
> - interlace = true;
> - break;
> - case 'e':
> - if (yres_specified || bpp_specified || refresh_specified ||
> - was_digit || (force != DRM_FORCE_UNSPECIFIED))
> - goto done;
>
> - force = DRM_FORCE_ON;
> - break;
> - case 'D':
> - if (yres_specified || bpp_specified || refresh_specified ||
> - was_digit || (force != DRM_FORCE_UNSPECIFIED))
> - goto done;
> + if (!isdigit(name[0]))
> + return false;
>
> - if ((connector->connector_type != DRM_MODE_CONNECTOR_DVII) &&
> - (connector->connector_type != DRM_MODE_CONNECTOR_HDMIB))
> - force = DRM_FORCE_ON;
> - else
> - force = DRM_FORCE_ON_DIGITAL;
> - break;
> - case 'd':
> - if (yres_specified || bpp_specified || refresh_specified ||
> - was_digit || (force != DRM_FORCE_UNSPECIFIED))
> - goto done;
> + /* Try to locate the bpp and refresh specifiers, if any */
> + bpp_ptr = strchr(name, '-');
> + if (bpp_ptr) {
> + bpp_off = bpp_ptr - name;
> + mode->bpp_specified = true;
> + }
>
> - force = DRM_FORCE_OFF;
> - break;
> - default:
> - goto done;
> - }
> + refresh_ptr = strchr(name, '@');
> + if (refresh_ptr) {
> + refresh_off = refresh_ptr - name;
> + mode->refresh_specified = true;
> }
>
> - if (i < 0 && yres_specified) {
> - char *ch;
> - xres = simple_strtol(name, &ch, 10);
> - if ((ch != NULL) && (*ch == 'x'))
> - res_specified = true;
> - else
> - i = ch - name;
> - } else if (!yres_specified && was_digit) {
> - /* catch mode that begins with digits but has no 'x' */
> - i = 0;
> + /* Locate the end of the name / resolution, and parse it */
> + if (bpp_ptr && refresh_ptr) {
> + mode_end = min(bpp_off, refresh_off);
> + } else if (bpp_ptr) {
> + mode_end = bpp_off;
> + } else if (refresh_ptr) {
> + mode_end = refresh_off;
> + } else {
> + mode_end = strlen(name);
> + parse_extras = true;
> }
> -done:
> - if (i >= 0) {
> - pr_warn("[drm] parse error at position %i in video mode '%s'\n",
> - i, name);
> - mode->specified = false;
> +
> + ret = drm_mode_parse_cmdline_res_mode(name, mode_end,
> + parse_extras,
> + connector,
> + mode);
> + if (ret)
> return false;
> - }
> + mode->specified = true;
>
> - if (res_specified) {
> - mode->specified = true;
> - mode->xres = xres;
> - mode->yres = yres;
> + if (bpp_ptr) {
> + ret = drm_mode_parse_cmdline_bpp(bpp_ptr, &bpp_end_ptr, mode);
> + if (ret)
> + return false;
> }
>
> - if (refresh_specified) {
> - mode->refresh_specified = true;
> - mode->refresh = refresh;
> + if (refresh_ptr) {
> + ret = drm_mode_parse_cmdline_refresh(refresh_ptr,
> + &refresh_end_ptr, mode);
> + if (ret)
> + return false;
> }
>
> - if (bpp_specified) {
> - mode->bpp_specified = true;
> - mode->bpp = bpp;
> + /*
> + * Locate the end of the bpp / refresh, and parse the extras
> + * if relevant
> + */
> + if (bpp_ptr && refresh_ptr)
Perhaps I'm paranoid, but I think it'd be better to check bpp_end_ptr
&& refresh_end_ptr in this conditional.
Sean
> + extra_ptr = max(bpp_end_ptr, refresh_end_ptr);
> + else if (bpp_ptr)
> + extra_ptr = bpp_end_ptr;
> + else if (refresh_ptr)
> + extra_ptr = refresh_end_ptr;
> +
> + if (extra_ptr) {
> + int remaining = strlen(name) - (extra_ptr - name);
> +
> + /*
> + * We still have characters to process, while
> + * we shouldn't have any
> + */
> + if (remaining > 0)
> + return false;
> }
> - mode->rb = rb;
> - mode->cvt = cvt;
> - mode->interlace = interlace;
> - mode->margins = margins;
> - mode->force = force;
>
> return true;
> }
> --
> git-series 0.8.10
^ permalink raw reply
* [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash
From: Han Xu @ 2016-11-16 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM4PR0701MB21308B262DB7B94E0F7FC34EFEF00@AM4PR0701MB2130.eurprd07.prod.outlook.com>
On Thu, Sep 15, 2016 at 06:50:55AM +0000, Krzeminski, Marcin (Nokia - PL/Wroclaw) wrote:
> Hello,
>
> > -----Original Message-----
> > From: linux-mtd [mailto:linux-mtd-bounces at lists.infradead.org] On Behalf
> > Of Han Xu
> > Sent: Wednesday, September 14, 2016 9:49 PM
> > To: Yunhui Cui <B56489@freescale.com>
> > Cc: Yunhui Cui <yunhui.cui@nxp.com>; David Woodhouse
> > <dwmw2@infradead.org>; linux-kernel at vger.kernel.org; linux-
> > mtd at lists.infradead.org; han.xu at freescale.com; Brian Norris
> > <computersforpeace@gmail.com>; jagannadh.teki at gmail.com; linux-arm-
> > kernel at lists.infradead.org; Yao Yuan <yao.yuan@nxp.com>
> > Subject: Re: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family
> > flash
> >
> > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui <B56489@freescale.com>
> > wrote:
> > > From: Yunhui Cui <yunhui.cui@nxp.com>
> > >
> > > With the physical sectors combination, S25FS-S family flash requires
> > > some special operations for read/write functions.
> > >
> > > Signed-off-by: Yunhui Cui <yunhui.cui@nxp.com>
> > > ---
> > > drivers/mtd/spi-nor/spi-nor.c | 56
> > > +++++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 56 insertions(+)
> > >
> > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb 100644
> > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > @@ -39,6 +39,10 @@
> > >
> > > #define SPI_NOR_MAX_ID_LEN 6
> > > #define SPI_NOR_MAX_ADDR_WIDTH 4
> > > +/* Added for S25FS-S family flash */
> > > +#define SPINOR_CONFIG_REG3_OFFSET 0x800004
> > > +#define CR3V_4KB_ERASE_UNABLE 0x8
> > > +#define SPINOR_S25FS_FAMILY_EXT_JEDEC 0x81
> > >
> > > struct flash_info {
> > > char *name;
> > > @@ -78,6 +82,7 @@ struct flash_info {
> > > };
> > >
> > > #define JEDEC_MFR(info) ((info)->id[0])
> > > +#define EXT_JEDEC(info) ((info)->id[5])
> > >
> > > static const struct flash_info *spi_nor_match_id(const char *name);
> > >
> > > @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] = {
> > > */
> > > { "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024, 64,
> > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > { "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024, 128,
> > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > + { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024, 512, 0)},
> > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
> > > { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512,
> > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256,
> > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1036,6 +1042,50
> > @@ static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
> > > return ERR_PTR(-ENODEV);
> > > }
> > >
> > > +/*
> > > + * The S25FS-S family physical sectors may be configured as a
> > > + * hybrid combination of eight 4-kB parameter sectors
> > > + * at the top or bottom of the address space with all
> > > + * but one of the remaining sectors being uniform size.
> > > + * The Parameter Sector Erase commands (20h or 21h) must
> > > + * be used to erase the 4-kB parameter sectors individually.
> > > + * The Sector (uniform sector) Erase commands (D8h or DCh)
> > > + * must be used to erase any of the remaining
> > > + * sectors, including the portion of highest or lowest address
> > > + * sector that is not overlaid by the parameter sectors.
> > > + * The uniform sector erase command has no effect on parameter
> > sectors.
> > > + */
> > > +static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor) {
> > > + u32 cr3v_addr = SPINOR_CONFIG_REG3_OFFSET;
> > > + u8 cr3v = 0x0;
> > > + int ret = 0x0;
> > > +
> > > + nor->cmd_buf[2] = cr3v_addr >> 16;
> > > + nor->cmd_buf[1] = cr3v_addr >> 8;
> > > + nor->cmd_buf[0] = cr3v_addr >> 0;
> > > +
> > > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, &cr3v, 1);
> > > + if (ret)
> > > + return ret;
> > > + if (cr3v & CR3V_4KB_ERASE_UNABLE)
> > > + return 0;
> > > + ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
> > > + if (ret)
> > > + return ret;
> > > + cr3v = CR3V_4KB_ERASE_UNABLE;
> > > + nor->program_opcode = SPINOR_OP_SPANSION_WRAR;
> > > + nor->write(nor, cr3v_addr, 1, &cr3v);
> > > +
> > > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, &cr3v, 1);
> > > + if (ret)
> > > + return ret;
> > > + if (!(cr3v & CR3V_4KB_ERASE_UNABLE))
> > > + return -EPERM;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
> > > size_t *retlen, u_char *buf) { @@ -1361,6
> > > +1411,12 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
> > enum read_mode mode)
> > > spi_nor_wait_till_ready(nor);
> > > }
> > >
> > > + if (EXT_JEDEC(info) == SPINOR_S25FS_FAMILY_EXT_JEDEC) {
> > > + ret = spansion_s25fs_disable_4kb_erase(nor);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > if (!mtd->name)
> > > mtd->name = dev_name(dev);
> > > mtd->priv = nor;
> > > --
> > > 2.1.0.27.g96db324
> > >
> > >
> > Hi Brian, I will ack this change but still feel it's kind of hacking code.
> >
> > Acked-by: Han xu <han.xu@nxp.com>
>
> I am new on the list so I am not sure if this topic has been discussed.
> Generally our product functionality relay on those 4KiB sectors.
> I know that this hack is already in u-boot, but if you mainstream this
> you will force users of those 4KiB sectors to do hack the hack...
> I believe the proper solution here is to use erase regions functionality,
> I send and RFS about that some time ago.
Do you mind to send me a link for reference?
Sincerely,
Han XU
>
> Thanks,
> Marcin
>
> > > ______________________________________________________
> > > Linux MTD discussion mailing list
> > > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> >
> >
> >
> > --
> > Sincerely,
> >
> > Han XU
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH v3 1/1] KVM: ARM64: Fix the issues when guest PMCCFILTR is configured
From: Wei Huang @ 2016-11-16 17:09 UTC (permalink / raw)
To: linux-arm-kernel
KVM calls kvm_pmu_set_counter_event_type() when PMCCFILTR is configured.
But this function can't deals with PMCCFILTR correctly because the evtCount
bits of PMCCFILTR, which is reserved 0, conflits with the SW_INCR event
type of other PMXEVTYPER<n> registers. To fix it, when eventsel == 0, this
function shouldn't return immediately; instead it needs to check further
if select_idx is ARMV8_PMU_CYCLE_IDX.
Another issue is that KVM shouldn't copy the eventsel bits of PMCCFILTER
blindly to attr.config. Instead it ought to convert the request to the
"cpu cycle" event type (i.e. 0x11).
To support this patch and to prevent duplicated definitions, a limited
set of ARMv8 perf event types were relocated from perf_event.c to
asm/perf_event.h.
Signed-off-by: Wei Huang <wei@redhat.com>
---
arch/arm64/include/asm/perf_event.h | 10 +++++++++-
arch/arm64/kernel/perf_event.c | 10 +---------
virt/kvm/arm/pmu.c | 8 +++++---
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
index 2065f46..38b6a2b 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -46,7 +46,15 @@
#define ARMV8_PMU_EVTYPE_MASK 0xc800ffff /* Mask for writable bits */
#define ARMV8_PMU_EVTYPE_EVENT 0xffff /* Mask for EVENT bits */
-#define ARMV8_PMU_EVTYPE_EVENT_SW_INCR 0 /* Software increment event */
+/*
+ * PMUv3 event types: required events
+ */
+#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
+#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
+#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
+#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
+#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
+#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
/*
* Event filters for PMUv3
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index a9310a6..57ae9d9 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -31,17 +31,9 @@
/*
* ARMv8 PMUv3 Performance Events handling code.
- * Common event types.
+ * Common event types (some are defined in asm/perf_event.h).
*/
-/* Required events. */
-#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
-#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
-#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
-#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
-#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
-#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
-
/* At least one of the following is required. */
#define ARMV8_PMUV3_PERFCTR_INST_RETIRED 0x08
#define ARMV8_PMUV3_PERFCTR_INST_SPEC 0x1B
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 6e9c40e..69ccce3 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -305,7 +305,7 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
continue;
type = vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
& ARMV8_PMU_EVTYPE_EVENT;
- if ((type == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
+ if ((type == ARMV8_PMUV3_PERFCTR_SW_INCR)
&& (enable & BIT(i))) {
reg = vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
reg = lower_32_bits(reg);
@@ -379,7 +379,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
eventsel = data & ARMV8_PMU_EVTYPE_EVENT;
/* Software increment event does't need to be backed by a perf event */
- if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
+ if (eventsel == ARMV8_PMUV3_PERFCTR_SW_INCR &&
+ select_idx != ARMV8_PMU_CYCLE_IDX)
return;
memset(&attr, 0, sizeof(struct perf_event_attr));
@@ -391,7 +392,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
attr.exclude_kernel = data & ARMV8_PMU_EXCLUDE_EL1 ? 1 : 0;
attr.exclude_hv = 1; /* Don't count EL2 events */
attr.exclude_host = 1; /* Don't count host events */
- attr.config = eventsel;
+ attr.config = (select_idx == ARMV8_PMU_CYCLE_IDX) ?
+ ARMV8_PMUV3_PERFCTR_CPU_CYCLES : eventsel;
counter = kvm_pmu_get_counter_value(vcpu, select_idx);
/* The initial sample period (overflow count) of an event. */
--
2.7.4
^ permalink raw reply related
* [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Anand Moon @ 2016-11-16 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479220154-25851-2-git-send-email-jbrunet@baylibre.com>
Hi Jerome.
On 15 November 2016 at 19:59, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On some platforms, energy efficient ethernet with rtl8211 devices is
> causing issue, like throughput drop or broken link.
>
> This was reported on the OdroidC2 (DWMAC + RTL8211F). While the issue root
> cause is not fully understood yet, disabling EEE advertisement prevent auto
> negotiation from enabling EEE.
>
> This patch provides options to disable 1000T and 100TX EEE advertisement
> individually for the realtek phys supporting this feature.
>
> Reported-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre TORGUE <alexandre.torgue@st.com>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Tested-by: Andre Roth <neolynx@gmail.com>
> ---
> drivers/net/phy/realtek.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 64 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> index aadd6e9f54ad..77235fd5faaf 100644
> --- a/drivers/net/phy/realtek.c
> +++ b/drivers/net/phy/realtek.c
> @@ -15,6 +15,12 @@
> */
> #include <linux/phy.h>
> #include <linux/module.h>
> +#include <linux/of.h>
> +
> +struct rtl8211x_phy_priv {
> + bool eee_1000t_disable;
> + bool eee_100tx_disable;
> +};
>
> #define RTL821x_PHYSR 0x11
> #define RTL821x_PHYSR_DUPLEX 0x2000
> @@ -93,12 +99,44 @@ static int rtl8211f_config_intr(struct phy_device *phydev)
> return err;
> }
>
> +static void rtl8211x_clear_eee_adv(struct phy_device *phydev)
> +{
> + struct rtl8211x_phy_priv *priv = phydev->priv;
> + u16 val;
> +
> + if (priv->eee_1000t_disable || priv->eee_100tx_disable) {
> + val = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_ADV,
> + MDIO_MMD_AN);
> +
> + if (priv->eee_1000t_disable)
> + val &= ~MDIO_AN_EEE_ADV_1000T;
> + if (priv->eee_100tx_disable)
> + val &= ~MDIO_AN_EEE_ADV_100TX;
> +
> + phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV,
> + MDIO_MMD_AN, val);
> + }
> +}
> +
> +static int rtl8211x_config_init(struct phy_device *phydev)
> +{
> + int ret;
> +
> + ret = genphy_config_init(phydev);
> + if (ret < 0)
> + return ret;
> +
> + rtl8211x_clear_eee_adv(phydev);
> +
> + return 0;
> +}
> +
> static int rtl8211f_config_init(struct phy_device *phydev)
> {
> int ret;
> u16 reg;
>
> - ret = genphy_config_init(phydev);
> + ret = rtl8211x_config_init(phydev);
> if (ret < 0)
> return ret;
>
> @@ -115,6 +153,26 @@ static int rtl8211f_config_init(struct phy_device *phydev)
> return 0;
> }
>
> +static int rtl8211x_phy_probe(struct phy_device *phydev)
> +{
> + struct device *dev = &phydev->mdio.dev;
> + struct device_node *of_node = dev->of_node;
> + struct rtl8211x_phy_priv *priv;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->eee_1000t_disable =
> + of_property_read_bool(of_node, "realtek,disable-eee-1000t");
> + priv->eee_100tx_disable =
> + of_property_read_bool(of_node, "realtek,disable-eee-100tx");
> +
> + phydev->priv = priv;
> +
> + return 0;
> +}
> +
> static struct phy_driver realtek_drvs[] = {
> {
> .phy_id = 0x00008201,
> @@ -140,7 +198,9 @@ static struct phy_driver realtek_drvs[] = {
> .phy_id_mask = 0x001fffff,
> .features = PHY_GBIT_FEATURES,
> .flags = PHY_HAS_INTERRUPT,
> + .probe = &rtl8211x_phy_probe,
> .config_aneg = genphy_config_aneg,
> + .config_init = &rtl8211x_config_init,
> .read_status = genphy_read_status,
> .ack_interrupt = rtl821x_ack_interrupt,
> .config_intr = rtl8211e_config_intr,
> @@ -152,7 +212,9 @@ static struct phy_driver realtek_drvs[] = {
> .phy_id_mask = 0x001fffff,
> .features = PHY_GBIT_FEATURES,
> .flags = PHY_HAS_INTERRUPT,
> + .probe = &rtl8211x_phy_probe,
> .config_aneg = &genphy_config_aneg,
> + .config_init = &rtl8211x_config_init,
> .read_status = &genphy_read_status,
> .ack_interrupt = &rtl821x_ack_interrupt,
> .config_intr = &rtl8211e_config_intr,
> @@ -164,6 +226,7 @@ static struct phy_driver realtek_drvs[] = {
> .phy_id_mask = 0x001fffff,
> .features = PHY_GBIT_FEATURES,
> .flags = PHY_HAS_INTERRUPT,
> + .probe = &rtl8211x_phy_probe,
> .config_aneg = &genphy_config_aneg,
> .config_init = &rtl8211f_config_init,
> .read_status = &genphy_read_status,
> --
> 2.7.4
>
How about adding callback functionality for .soft_reset to handle BMCR
where we update the Auto-Negotiation for the phy,
as per the datasheet of the rtl8211f.
-Best Regard
Anand Moon
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* [PATCH 0/8] DMA: s3c64xx: Conversion to the new channel request API
From: Krzysztof Kozlowski @ 2016-11-16 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116032620.GV3000@localhost>
On Wed, Nov 16, 2016 at 08:56:20AM +0530, Vinod Koul wrote:
> On Thu, Nov 10, 2016 at 04:17:48PM +0100, Sylwester Nawrocki wrote:
> > This patch series aims to convert the s3c64xx platform to use
> > the new DMA channel request API, i.e. this is only meaningful
> > for non-dt systems using s3c64xx SoCs.
> >
> > Presumably the first 2 or 4 patches in this series could be queued
> > for v4.10-rc1 and the remaining patches could be left for subsequent
> > release, to avoid non-trivial conflict with patches already applied
> > in the ASoC tree.
>
> I am fine with dma patch (expect the subsystem tag) and others except arm
> ones have acks, so I think we can merge this for v4.10-rc1. I cna create a
> immutable tag and people can merge into their tree in case they have
> dependencies.
>
> Btw need acks on ARM patches before I can apply
First two ARM acked. Vinod, could you prepare a tag with them?
As I understood, everything won't be applied because ASoC tree already
contains some work around this?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Florian Fainelli @ 2016-11-16 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479310731.17538.53.camel@baylibre.com>
On 11/16/2016 07:38 AM, Jerome Brunet wrote:
> On Wed, 2016-11-16 at 16:06 +0100, Andrew Lunn wrote:
>> On Wed, Nov 16, 2016 at 03:51:30PM +0100, Jerome Brunet wrote:
>>>
>>> On Wed, 2016-11-16 at 14:23 +0100, Andrew Lunn wrote:
>>>>
>>>>>
>>>>>
>>>>> There two kind of PHYs supporting eee, the one advertising eee
>>>>> by
>>>>> default (like realtek) and the one not advertising it (like
>>>>> micrel).
>>>
>>> This is just the default register value.
>>>
>>>>
>>>>
>>>> I don't know too much about EEE. So maybe a dumb question. Does
>>>> the
>>>> MAC need to be involved? Or is it just the PHY?
>>>>
>>>> If the MAC needs to be involved, the PHY should not be
>>>> advertising
>>>> EEE
>>>> unless the MAC asks for it by calling phy_init_eee(). If this is
>>>> true,
>>>> maybe we need to change the realtek driver, and others in that
>>>> class.
>>>
>>> As far I understand, the advertised capabilities are exchanged
>>> during
>>> the auto-negotiation.
>>>
>>> At this stage, if the advertisement is disabled (regarless of the
>>> actual support) on either side of the link, there will be no low
>>> power
>>> idle state on the Tx nor the Rx path.
>>>
>>> If the advertisement is enabled on both side but we don't call
>>> phy_init_eee, I suppose Tx won't enter LPI, but Rx could.
>>
>> What i was trying to find out is, if the MAC needs to support EEE as
>> well as the PHY, what happens when the MAC does not support EEE, but
>> the PHYs do negotiate EEE? Does it break?
>
> Interesting question. In a regular case, I suppose it should be fine.
> As you would have LPI only on the Rx path this should be transparent to
> the MAC. That's my understanding. Maybe people knowing EEE better than
> me could confirm (or not) ? Peppe? Alexandre?
EEE is a MAC and PHY feature, and both need to agree on what is enabled,
especially in the transmit path because the way packets may be
transmitted with or without EEE can be done differently at the HW level
(faster/slower return to idle, different clock source).
>
> I just checked with the OdroidC2, I disabled eee support by forcing
> "dma_cap.eee = 0" in stmmac_get_hw_features. As expected, no tx_LPI
> interrupts but plenty of rx_LPI interrupts.
>
> What was not expected is test failing like before.
> So in our case, having LPI on the Rx path is fine for receiving data,
> but not for sending.
OK, which really sounds like a potential interoperability problem, or
just the Realtek PHY with EEE enabled acting funky (irrespective of
being attached to stmmac).
--
Florian
^ permalink raw reply
* [PATCH 4/8] ARM: s3c64xx: Drop unused DMA fields from struct s3c64xx_spi_csinfo
From: Krzysztof Kozlowski @ 2016-11-16 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-5-git-send-email-s.nawrocki@samsung.com>
On Thu, Nov 10, 2016 at 04:17:52PM +0100, Sylwester Nawrocki wrote:
> There is no drivers using those fields so remove them and
> the remaining initializations.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Tested-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> ---
> arch/arm/plat-samsung/devs.c | 24 ------------------------
> include/linux/platform_data/spi-s3c64xx.h | 3 ---
> 2 files changed, 27 deletions(-)
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/8] ARM: s3c64xx: Add DMA slave maps for PL080 devices
From: Krzysztof Kozlowski @ 2016-11-16 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-3-git-send-email-s.nawrocki@samsung.com>
On Thu, Nov 10, 2016 at 04:17:50PM +0100, Sylwester Nawrocki wrote:
> This patch adds DMA slave map tables to the pl080 devices's
> platform_data in order to support the new channel request API.
> A few devices for which there was no DMA support with current
> code are omitted in the tables.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> arch/arm/mach-s3c64xx/pl080.c | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] bus: vexpress-config: fix device reference leak
From: Sudeep Holla @ 2016-11-16 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477997017-29103-1-git-send-email-johan@kernel.org>
On 01/11/16 10:43, Johan Hovold wrote:
> Make sure to drop the reference to the parent device taken by
> class_find_device() after populating the bus.
>
Thanks for the fix. I somehow missed this patch, sorry for that.
Not sure if arm-soc guys take this as a fix for v4.9, and I have already
sent PR for v4.10. I will repost this along with the ack and check with
them.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] ARM: davinci: PM: fix build when da850 not compiled in
From: Kevin Hilman @ 2016-11-16 16:44 UTC (permalink / raw)
To: linux-arm-kernel
Currently, suspend/resume support is only available on da850 platforms,
and the platform PM code has dependencies on da850 functions. However,
CONFIG_SUSPEND might be enabled even when da850 support is not, causing
build failure:
arch/arm/mach-davinci/built-in.o: In function `davinci_pm_init':
pm_domain.c:(.init.text+0x1fb8): undefined reference to `da8xx_get_mem_ctlr'
pm_domain.c:(.init.text+0x20b0): undefined reference to `da8xx_syscfg1_base'
Fix this by only building the PM core when da850 is enabled.
Reported-by: Sekhar Nori <nsekhar@ti.com>
Fixes: aa9aa1ec2df6 ARM: davinci: PM: rework init, remove platform device
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/mach-davinci/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index da4c336b4637..0a2e6da45f28 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -36,5 +36,7 @@ obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD) += board-omapl138-hawk.o
# Power Management
obj-$(CONFIG_CPU_IDLE) += cpuidle.o
-obj-$(CONFIG_SUSPEND) += pm.o sleep.o
obj-$(CONFIG_HAVE_CLK) += pm_domain.o
+ifeq ($(CONFIG_SUSPEND),y)
+obj-$(CONFIG_ARCH_DAVINCI_DA850) += pm.o sleep.o
+endif
--
2.9.3
^ permalink raw reply related
* [PATCH RFT] irqchip: mxs: Enable SKIP_SET_WAKE and MASK_ON_SUSPEND
From: Stefan Wahren @ 2016-11-16 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <40c3be7e-08c3-955c-746a-6906160e1e0a@rempel-privat.de>
> Oleksij Rempel <linux@rempel-privat.de> hat am 12. November 2016 um 20:24
> geschrieben:
>
>
> Am 11.11.2016 um 18:26 schrieb Stefan Wahren:
> > The ICOLL controller doesn't provide any facility to configure the
> > wakeup sources. That's the reason why this implementation lacks
> > the irq_set_wake implementation. But this prevent us from properly
> > entering power management states like "suspend to idle".
> >
> > So enable the flags IRQCHIP_SKIP_SET_WAKE and IRQCHIP_MASK_ON_SUSPEND
> > to let the irqchip core allows and handles the power management.
> >
> > This patch has been tested with a MX23 and a MX28 board. Any further
> > tests especially with ASM9260 would be appreciated.
>
> Hi, I wont be able to test this patch on ASM9260 until March.
> Please roll it out, so far it looks ok for me.
Is this an "Acked-by" ?
>
>
> > Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> > ---
> > drivers/irqchip/irq-mxs.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/irqchip/irq-mxs.c b/drivers/irqchip/irq-mxs.c
> > index 1730470..05fa9f7 100644
> > --- a/drivers/irqchip/irq-mxs.c
> > +++ b/drivers/irqchip/irq-mxs.c
> > @@ -131,12 +131,16 @@ static void asm9260_unmask_irq(struct irq_data *d)
> > .irq_ack = icoll_ack_irq,
> > .irq_mask = icoll_mask_irq,
> > .irq_unmask = icoll_unmask_irq,
> > + .flags = IRQCHIP_MASK_ON_SUSPEND |
> > + IRQCHIP_SKIP_SET_WAKE,
> > };
> >
> > static struct irq_chip asm9260_icoll_chip = {
> > .irq_ack = icoll_ack_irq,
> > .irq_mask = asm9260_mask_irq,
> > .irq_unmask = asm9260_unmask_irq,
> > + .flags = IRQCHIP_MASK_ON_SUSPEND |
> > + IRQCHIP_SKIP_SET_WAKE,
> > };
> >
> > asmlinkage void __exception_irq_entry icoll_handle_irq(struct pt_regs
> > *regs)
> >
>
>
> --
> Regards,
> Oleksij
>
^ permalink raw reply
* [PATCH 2/2] ARM: bcm2835: Add names for the Raspberry Pi Zero GPIO lines
From: Stefan Wahren @ 2016-11-16 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zil0r71o.fsf@eliezer.anholt.net>
> Eric Anholt <eric@anholt.net> hat am 15. November 2016 um 18:23 geschrieben:
>
>
> Stefan Wahren <stefan.wahren@i2se.com> writes:
>
> > This adds the GPIO names for the Raspberry Pi Zero. Since there are no
> > schematics for the RPi Zero use the same as the Model A+.
>
> These look good to me. I don't have a Zero schematic, but I compared to
> dt-blob.
>
> I've pulled these two to -next.
Thanks. Unfortunately the link to the dt-blob is outdated. The newer ones [1]
contains the definition of the Raspberry Pi Zero and it differs from Model A+
Please drop the complete series and i'll send a V2. Sorry about this.
[1] - https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts
Stefan
^ permalink raw reply
* [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
From: Will Deacon @ 2016-11-16 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114055515.GH381@linaro.org>
Hi Akashi,
On Mon, Nov 14, 2016 at 02:55:16PM +0900, AKASHI Takahiro wrote:
> On Fri, Nov 11, 2016 at 11:19:04AM +0800, Dennis Chen wrote:
> > On Fri, Nov 11, 2016 at 11:50:50AM +0900, AKASHI Takahiro wrote:
> > > On Thu, Nov 10, 2016 at 05:27:20PM +0000, Will Deacon wrote:
> > > > On Wed, Nov 02, 2016 at 01:51:53PM +0900, AKASHI Takahiro wrote:
> > > > > +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> > > > > +{
> > > > > + int start_rgn, end_rgn;
> > > > > + int i, ret;
> > > > > +
> > > > > + if (!size)
> > > > > + return;
> > > > > +
> > > > > + ret = memblock_isolate_range(&memblock.memory, base, size,
> > > > > + &start_rgn, &end_rgn);
> > > > > + if (ret)
> > > > > + return;
> > > > > +
> > > > > + /* remove all the MAP regions */
> > > > > + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> > > > > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > > > > + memblock_remove_region(&memblock.memory, i);
> > > > > +
> > > > > + for (i = start_rgn - 1; i >= 0; i--)
> > > > > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > > > > + memblock_remove_region(&memblock.memory, i);
> > > > > +
> > > > > + /* truncate the reserved regions */
> > > > > + memblock_remove_range(&memblock.reserved, 0, base);
> > > > > + memblock_remove_range(&memblock.reserved,
> > > > > + base + size, (phys_addr_t)ULLONG_MAX);
> > > > > +}
> > > >
> > > > This duplicates a bunch of the logic in memblock_mem_limit_remove_map. Can
> > > > you not implement that in terms of your new, more general, function? e.g.
> > > > by passing base == 0, and size == limit?
> > >
> > > Obviously it's possible.
> > > I actually talked to Dennis before about merging them,
> > > but he was against my idea.
> > >
> > Oops! I thought we have reached agreement in the thread:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/442817.html
> > So feel free to do that as Will'll do
>
> OK, but I found that the two functions have a bit different semantics
> in clipping memory range, in particular, when the range [base,base+size)
> goes across several regions with a gap.
> (This does not happen in my arm64 kdump, though.)
> That is, 'limit' in memblock_mem_limit_remove_map() means total size of
> available memory, while 'size' in memblock_cap_memory_range() indicates
> the size of _continuous_ memory range.
I thought limit was just a physical address, and then
memblock_mem_limit_remove_map operated on the end of the nearest memblock?
You could leave the __find_max_addr call in memblock_mem_limit_remove_map,
given that I don't think you need/want it for memblock_cap_memory_range.
> So I added an extra argument, exact, to a common function to specify
> distinct behaviors. Confusing? Please see the patch below.
Oh yikes, this certainly wasn't what I had in mind! My observation was
just that memblock_mem_limit_remove_map(limit) does:
1. memblock_isolate_range(limit - limit+ULLONG_MAX)
2. memblock_remove_region(all non-nomap regions in the isolated region)
3. truncate reserved regions to limit
and your memblock_cap_memory_range(base, size) does:
1. memblock_isolate_range(base - base+size)
2, memblock_remove_region(all non-nomap regions above and below the
isolated region)
3. truncate reserved regions around the isolated region
so, assuming we can invert the isolation in one of the cases, then they
could share the same underlying implementation.
I'm probably just missing something here, because the patch you've ended
up with is far more involved than I anticipated...
Will
^ permalink raw reply
* [PATCH] ARM: dts: imx: add SPI to GW54xx
From: Tim Harvey @ 2016-11-16 16:26 UTC (permalink / raw)
To: linux-arm-kernel
The GW54xx revision E adds SPI via an off-board connector.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index b6982959..6eb4fc9 100644
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -149,6 +149,14 @@
<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
};
+&ecspi2 {
+ fsl,spi-num-chipselects = <1>;
+ cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi2>;
+ status = "okay";
+};
+
&fec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
@@ -511,6 +519,15 @@
>;
};
+ pinctrl_ecspi2: escpi2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1
+ MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1
+ MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1
+ MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x100b1
+ >;
+ };
+
pinctrl_flexcan1: flexcan1grp {
fsl,pins = <
MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x1b0b1
--
1.9.1
^ 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