* [PATCH 5/8] pinctrl: aspeed: Enable capture of off-SCU pinmux state
From: Joel Stanley @ 2016-09-29 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a266046d34009e6e92c4c76699c550c2ba44bd5c.1474986045.git-series.andrew@aj.id.au>
On Wed, Sep 28, 2016 at 12:20 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> The System Control Unit IP in the Aspeed SoCs is typically where the
> pinmux configuration is found.
>
> But not always.
>
> On the AST2400 and AST2500 a number of pins depend on state in one of
> the SIO, LPC or GFX IP blocks, so add support to at least capture what
> that state is. The pinctrl engine for the Aspeed SoCs doesn't try to
> inspect or modify the state of the off-SCU IP blocks. Instead, it logs
> the state requirement with the expectation that the platform
> designer/maintainer arranges for the appropriate configuration to be
> applied through the associated drivers.
This is unfortunate.
This patch kicks the can down the road, but doesn't solve the problem
for a user who wants to configure some functionality that depends on
the non-SCU bits. Because of this I'm not sure if we want to put it in
the tree.
However, I'm not sure what a proper solution would look like. Perhaps
Linus can point out another SoC that has a similar problem?
Cheers,
Joel
>
> The IP block of interest is encoded in the reg member of struct
> aspeed_sig_desc. For compatibility with the existing code, the SCU is
> defined to have an IP value of 0.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> drivers/pinctrl/aspeed/pinctrl-aspeed.c | 53 +++++++++++++++++++++++---
> drivers/pinctrl/aspeed/pinctrl-aspeed.h | 16 +++++++-
> 2 files changed, 61 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> index 49aeba912531..21ef195d586f 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> @@ -14,6 +14,8 @@
> #include "../core.h"
> #include "pinctrl-aspeed.h"
>
> +const char *const aspeed_pinmux_ips[] = { "SCU", "SIO", "GFX", "LPC" };
> +
> int aspeed_pinctrl_get_groups_count(struct pinctrl_dev *pctldev)
> {
> struct aspeed_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
> @@ -78,7 +80,9 @@ int aspeed_pinmux_get_fn_groups(struct pinctrl_dev *pctldev,
> static inline void aspeed_sig_desc_print_val(
> const struct aspeed_sig_desc *desc, bool enable, u32 rv)
> {
> - pr_debug("SCU%x[0x%08x]=0x%x, got 0x%x from 0x%08x\n", desc->reg,
> + pr_debug("Want %s%lX[0x%08X]=0x%X, got 0x%X from 0x%08X\n",
> + aspeed_pinmux_ips[SIG_DESC_IP_FROM_REG(desc->reg)],
> + SIG_DESC_OFFSET_FROM_REG(desc->reg),
> desc->mask, enable ? desc->enable : desc->disable,
> (rv & desc->mask) >> __ffs(desc->mask), rv);
> }
> @@ -105,6 +109,8 @@ static bool aspeed_sig_desc_eval(const struct aspeed_sig_desc *desc,
> unsigned int raw;
> u32 want;
>
> + WARN_ON(SIG_DESC_IP_FROM_REG(desc->reg) != ASPEED_IP_SCU);
> +
> if (regmap_read(map, desc->reg, &raw) < 0)
> return false;
>
> @@ -142,9 +148,19 @@ static bool aspeed_sig_expr_eval(const struct aspeed_sig_expr *expr,
>
> for (i = 0; i < expr->ndescs; i++) {
> const struct aspeed_sig_desc *desc = &expr->descs[i];
> + size_t ip = SIG_DESC_IP_FROM_REG(desc->reg);
> +
> + if (ip == ASPEED_IP_SCU) {
> + if (!aspeed_sig_desc_eval(desc, enabled, map))
> + return false;
> + } else {
> + size_t offset = SIG_DESC_OFFSET_FROM_REG(desc->reg);
> + const char *ip_name = aspeed_pinmux_ips[ip];
> +
> + pr_debug("Ignoring configuration of field %s%X[0x%08X]\n",
> + ip_name, offset, desc->mask);
> + }
>
> - if (!aspeed_sig_desc_eval(desc, enabled, map))
> - return false;
> }
>
> return true;
> @@ -170,7 +186,14 @@ static bool aspeed_sig_expr_set(const struct aspeed_sig_expr *expr,
> for (i = 0; i < expr->ndescs; i++) {
> bool ret;
> const struct aspeed_sig_desc *desc = &expr->descs[i];
> +
> + size_t offset = SIG_DESC_OFFSET_FROM_REG(desc->reg);
> + size_t ip = SIG_DESC_IP_FROM_REG(desc->reg);
> + bool is_scu = (ip == ASPEED_IP_SCU);
> + const char *ip_name = aspeed_pinmux_ips[ip];
> +
> u32 pattern = enable ? desc->enable : desc->disable;
> + u32 val = (pattern << __ffs(desc->mask));
>
> /*
> * Strap registers are configured in hardware or by early-boot
> @@ -179,11 +202,27 @@ static bool aspeed_sig_expr_set(const struct aspeed_sig_expr *expr,
> * deconfigured and is the reason we re-evaluate after writing
> * all descriptor bits.
> */
> - if (desc->reg == HW_STRAP1 || desc->reg == HW_STRAP2)
> + if (is_scu && (offset == HW_STRAP1 || offset == HW_STRAP2))
> continue;
>
> - ret = regmap_update_bits(map, desc->reg, desc->mask,
> - pattern << __ffs(desc->mask)) == 0;
> + /*
> + * Sometimes we need help from IP outside the SCU to activate a
> + * mux request. Report that we need its cooperation.
> + */
> + if (enable && !is_scu) {
> + pr_debug("Pinmux request for %s requires cooperation of %s IP: Need (%s%X[0x%08X] = 0x%08X\n",
> + expr->function, ip_name, ip_name, offset,
> + desc->mask, val);
> + }
> +
> + /* And only read/write SCU registers */
> + if (!is_scu) {
> + pr_debug("Skipping configuration of field %s%X[0x%08X]\n",
> + ip_name, offset, desc->mask);
> + continue;
> + }
> +
> + ret = regmap_update_bits(map, desc->reg, desc->mask, val) == 0;
>
> if (!ret)
> return ret;
> @@ -343,6 +382,8 @@ int aspeed_pinmux_set_mux(struct pinctrl_dev *pctldev, unsigned int function,
> const struct aspeed_sig_expr **funcs;
> const struct aspeed_sig_expr ***prios;
>
> + pr_debug("Muxing pin %d for %s\n", pin, pfunc->name);
> +
> if (!pdesc)
> return -EINVAL;
>
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.h b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> index 3e72ef8c54bf..4384407d77fb 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> @@ -232,6 +232,15 @@
> * group.
> */
>
> +#define ASPEED_IP_SCU 0
> +#define ASPEED_IP_SIO 1
> +#define ASPEED_IP_GFX 2
> +#define ASPEED_IP_LPC 3
> +
> +#define SIG_DESC_TO_REG(ip, offset) (((ip) << 24) | (offset))
> +#define SIG_DESC_IP_FROM_REG(reg) (((reg) >> 24) & GENMASK(7, 0))
> +#define SIG_DESC_OFFSET_FROM_REG(reg) ((reg) & GENMASK(11, 0))
> +
> /*
> * The "Multi-function Pins Mapping and Control" table in the SoC datasheet
> * references registers by the device/offset mnemonic. The register macros
> @@ -261,7 +270,10 @@
> * A signal descriptor, which describes the register, bits and the
> * enable/disable values that should be compared or written.
> *
> - * @reg: The register offset from base in bytes
> + * @reg: Split into three fields:
> + * 31:24: IP selector
> + * 23:12: Reserved
> + * 11:0: Register offset
> * @mask: The mask to apply to the register. The lowest set bit of the mask is
> * used to derive the shift value.
> * @enable: The value that enables the function. Value should be in the LSBs,
> @@ -270,7 +282,7 @@
> * LSBs, not at the position of the mask.
> */
> struct aspeed_sig_desc {
> - unsigned int reg;
> + u32 reg;
> u32 mask;
> u32 enable;
> u32 disable;
> --
> git-series 0.8.10
^ permalink raw reply
* [PATCH] MAINTAINERS: add myself as Marvell berlin SoC co-maintainers
From: Jisheng Zhang @ 2016-09-29 6:55 UTC (permalink / raw)
To: linux-arm-kernel
I would like to help maintaining Marvell berlin SoCs.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b003d0c..b1e5243 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1411,6 +1411,7 @@ F: arch/arm/configs/mvebu_*_defconfig
ARM/Marvell Berlin SoC support
M: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+M: Jisheng Zhang <jszhang@marvell.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-berlin/
--
2.9.3
^ permalink raw reply related
* [PATCH] arm64: set path to Image.gz in the mkspec to avoid rpm build issue
From: Michal Marek @ 2016-09-29 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160928094913.GD24658@arm.com>
On 2016-09-28 11:49, Will Deacon wrote:
> [Adding Michal Marek]
>
> On Tue, Sep 27, 2016 at 08:53:47AM -0700, Vadim Lomovtsev wrote:
>> In addition to http://www.spinics.net/lists/arm-kernel/msg527466.html
>>
>> While building rpm-pkg target it fails to copy kernel image
>> from default location to rpm buildroot directory.
>>
>> Since we have arch variable set to aarch64 while Image.gz
>> is located at arch/arm64/boot it's necessary to specify
>> correct path to cp command as it implemeted for ppc64 build.
The variable should point to the actual file. ppc64 should be fixed as well.
Michal
^ permalink raw reply
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Jisheng Zhang @ 2016-09-29 7:34 UTC (permalink / raw)
To: linux-arm-kernel
On Marvell berlin arm64 platforms, I see the preemptoff tracer report
a max 26543 us latency at __purge_vmap_area_lazy, this latency is an
awfully bad for STB. And the ftrace log also shows __free_vmap_area
contributes most latency now. I noticed that Joel mentioned the same
issue[1] on x86 platform and gave two solutions, but it seems no patch
is sent out for this purpose.
This patch adopts Joel's first solution, but I use 16MB per core
rather than 8MB per core for the number of lazy_max_pages. After this
patch, the preemptoff tracer reports a max 6455us latency, reduced to
1/4 of original result.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1603.2/04803.html
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
mm/vmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 91f44e7..66f377a 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -596,7 +596,7 @@ static unsigned long lazy_max_pages(void)
log = fls(num_online_cpus());
- return log * (32UL * 1024 * 1024 / PAGE_SIZE);
+ return log * (16UL * 1024 * 1024 / PAGE_SIZE);
}
static atomic_t vmap_lazy_nr = ATOMIC_INIT(0);
--
2.9.3
^ permalink raw reply related
* [PATCH] MAINTAINERS: update entry for atmel_serial driver
From: Nicolas Ferre @ 2016-09-29 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929063148.GA418@kroah.com>
Le 29/09/2016 ? 08:31, Greg Kroah-Hartman a ?crit :
> On Wed, Sep 28, 2016 at 05:47:35PM +0200, Nicolas Ferre wrote:
>> Change maintainer for the serial driver found on most of the
>> Microchip / Atmel MPUs and take advantage of the move to rename
>> and reorder the entry.
>> I'm happy that Richard is taking over the maintenance of this
>> driver.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> Acked-by: Richard Genoud <richard.genoud@gmail.com>
>> ---
>> MAINTAINERS | 11 ++++++-----
>> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> This doesn't apply to my tty-next tree at all, what did you make it
> against?
Yesterdays' linux-next (next-20160928 tag). I thought it would be the
best for easy pick-up by anybody, particularly on a highly shared file
like MAINTAINERS.
Tell me if you want me to collect all tags, rebase on tty-next and re-send.
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v6 0/3] arm64 kexec-tools patches
From: Simon Horman @ 2016-09-29 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923085840.GA22928@localhost.localdomain>
On Wed, Sep 28, 2016 at 06:05:14PM +0200, Matthias Brugger wrote:
>
>
> On 21/09/16 20:14, Geoff Levand wrote:
> >This series adds the core support for kexec re-boot on ARM64.
> >
>
> I also tested on seattle.
>
> Tested-By: Matthias Brugger <mbrugger@suse.com>
On Fri, Sep 23, 2016 at 02:28:40PM +0530, Pratyush Anand wrote:
> Hi Geoff,
>
> On 21/09/2016:06:14:25 PM, Geoff Levand wrote:
> > This series adds the core support for kexec re-boot on ARM64.
>
> I tested this series with mustang and seattle and they work.
>
> So you can use my "Tested-By: Pratyush Anand <panand@redhat.com>".
>
> Just one Nitpick: In patch 2/3 arm64_header_check_msb(),
> arm64_header_page_size() and arm64_header_placement() have been defined but they
> have not been used anywhere. So, may be they can be removed.
Thanks everyone, I have queued this up with the above tags.
Please consider a follow-up patch to remove the functions mentioned above.
FWIW I tested v5 of this patchset on Renesas Gen3 R-Car H3 and M3-W and
it seems to work fine.
^ permalink raw reply
* drm/mediatek: fixed the calc method of data rate per lane
From: CK Hu @ 2016-09-29 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472191831-7150-1-git-send-email-jitao.shi@mediatek.com>
Hi, Jitao:
Sorry for late reply.
Some comments inline.
On Fri, 2016-08-26 at 14:10 +0800, Jitao Shi wrote:
> Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
> Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
> signal will cause h-time larger than normal and reduce FPS.
> Need to multiply a coefficient to offset the extra signal's effect.
> coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
> Ths_exit)/(htotal*bpp/lane_number))
>
> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 111 ++++++++++++++++++++++--------------
> 1 file changed, 67 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 28b2044..506aa22 100644
[snip...]
>
> -static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> +static void dsi_phy_timconfig(struct mtk_dsi *dsi, u32 phy_timing0,
> + u32 phy_timing1, u32 phy_timing2,
> + u32 phy_timing3)
> {
> - u32 timcon0, timcon1, timcon2, timcon3;
> - unsigned int ui, cycle_time;
> - unsigned int lpx;
> -
> - ui = 1000 / dsi->data_rate + 0x01;
> - cycle_time = 8000 / dsi->data_rate + 0x01;
> - lpx = 5;
> -
> - timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
> - timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
> - (4 * lpx);
> - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> - (NS_TO_CYCLE(0x150, cycle_time) << 16);
> - timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> - NS_TO_CYCLE(0x40, cycle_time);
> -
> - writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
> - writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> - writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
> - writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
> + writel(phy_timing0, dsi->regs + DSI_PHY_TIMECON0);
> + writel(phy_timing1, dsi->regs + DSI_PHY_TIMECON1);
> + writel(phy_timing2, dsi->regs + DSI_PHY_TIMECON2);
> + writel(phy_timing3, dsi->regs + DSI_PHY_TIMECON3);
> }
>
> static void mtk_dsi_enable(struct mtk_dsi *dsi)
> @@ -202,19 +186,57 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> {
> struct device *dev = dsi->dev;
> int ret;
> + u64 bit_clock, total_bits;
> + u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
> + u32 phy_timing0, phy_timing1, phy_timing2, phy_timing3;
>
> if (++dsi->refcount != 1)
> return 0;
>
> + phy_timing0 = LPX(5) | HS_PRPR(6) | HS_ZERO(10) | HS_TRAIL(8);
> + phy_timing1 = TA_GO(20) | TA_SURE(7) | TA_GET(25) | DA_HS_EXIT(7);
> + phy_timing2 = CLK_ZERO(38) | CLK_TRAIL(22);
> + phy_timing3 = CLK_HS_PRPR(8) | CLK_HS_POST(21) | CLK_HS_EXIT(10);
The original phy_timing2 and phy_timing3 is defined as
timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
(NS_TO_CYCLE(0x150, cycle_time) << 16);
timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8
|
NS_TO_CYCLE(0x40, cycle_time);
They are varied by cycle_time. I think you should not use a fixed value
for them.
> +
> + switch (dsi->format) {
> + case MIPI_DSI_FMT_RGB565:
> + bit_per_pixel = 16;
> + break;
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + bit_per_pixel = 18;
> + break;
> + case MIPI_DSI_FMT_RGB666:
> + case MIPI_DSI_FMT_RGB888:
> + default:
> + bit_per_pixel = 24;
> + break;
> + }
> /**
> - * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
> - * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
> - * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> - * we set mipi_ratio is 1.05.
> + * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
> + * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
> + * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
> + * + Thstrail + Ths_exit + Ths_zero) /
> + * (htotal * byte_per_pixel /lane_number)
> */
> - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> + bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
> + htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
> + dsi->vm.hsync_len;
> + htotal_bits = htotal * bit_per_pixel;
> +
> + /**
> + * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
> + */
> + overhead_cycles = (phy_timing0 & 0xff) + (phy_timing0 >> 8 & 0xff) +
> + (phy_timing0 >> 16 & 0xff) +
> + (phy_timing0 >> 24 & 0xff) +
> + (phy_timing1 >> 24 & 0xff);
I think phy_timing0 and phy_timing1 is defined as
phy_timing0 = LPX(a) | HS_PRPR(b) | HS_ZERO(c) | HS_TRAIL(d);
phy_timing1 = TA_GO(e) | TA_SURE(f) | TA_GET(g) | DA_HS_EXIT(h);
So, it could be a more simple way to assign overhead_cycles like this
overhead_cycles = a + b + c + d + h;
Because these variable are constant, maybe you can define them as
symbols.
> + overhead_bits = overhead_cycles * dsi->lanes * 8;
> + total_bits = htotal_bits + overhead_bits;
> +
> + dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
> + htotal_bits * dsi->lanes);
>
> - ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
> + ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
> if (ret < 0) {
> dev_err(dev, "Failed to set data rate: %d\n", ret);
> goto err_refcount;
> @@ -236,7 +258,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>
> mtk_dsi_enable(dsi);
> mtk_dsi_reset(dsi);
> - dsi_phy_timconfig(dsi);
> + dsi_phy_timconfig(dsi, phy_timing0, phy_timing1, phy_timing2,
> + phy_timing3);
>
> return 0;
>
Regards,
CK
^ permalink raw reply
* [PATCH 5/8] pinctrl: aspeed: Enable capture of off-SCU pinmux state
From: Andrew Jeffery @ 2016-09-29 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8Xc7y3GtcJCVYYs-JKTqBZvqVeZaz5MUk=UX151SX1xEFw@mail.gmail.com>
On Thu, 2016-09-29 at 16:15 +0930, Joel Stanley wrote:
> On Wed, Sep 28, 2016 at 12:20 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> > The System Control Unit IP in the Aspeed SoCs is typically where the
> > pinmux configuration is found.
> >
> > But not always.
> >
> > On the AST2400 and AST2500 a number of pins depend on state in one of
> > the SIO, LPC or GFX IP blocks, so add support to at least capture what
> > that state is. The pinctrl engine for the Aspeed SoCs doesn't try to
> > inspect or modify the state of the off-SCU IP blocks. Instead, it logs
> > the state requirement with the expectation that the platform
> > designer/maintainer arranges for the appropriate configuration to be
> > applied through the associated drivers.
> This is unfortunate.
>
> This patch kicks the can down the road, but doesn't solve the problem
> for a user who wants to configure some functionality that depends on
> the non-SCU bits. Because of this I'm not sure if we want to put it in
> the tree.
I agree that there's not much functionality from a user's perspective,
but the "kicking the can down the road" assessment might be a little
harsh. Given the lack of user functionality it becomes more difficult
to argue for the patch's inclusion given the additional complexity, but
it does mean that the g4/g5 drivers can completely specify their
dependencies and not have the aspeed pinctrl core do the wrong thing
when it encounters the non-SCU IP offsets. It gets us half-way to
having the pinctrl driver actually configure the state (knowing what it
needs to configure), which I feel is more than a kick-the-can-down-the-
road boondoggle.
>
> However, I'm not sure what a proper solution would look like.
So if we accept that a proper solution includes specifying the off-SCU
dependencies, the remaining question is how do we tastefully apply the
desired state on register-spaces the pinctrl driver doesn't own.
> Perhaps
> Linus can point out another SoC that has a similar problem?
Or failing that, an approach that is acceptable...
Cheers,
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160929/31192dfd/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 7/7] i2c: bcm2835: Add support for dynamic clock
From: Martin Sperl @ 2016-09-29 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r383g1kb.fsf@eliezer.anholt.net>
On 28.09.2016 23:24, Eric Anholt wrote:
> Noralf Tr?nnes <noralf@tronnes.org> writes:
>
>> Support a dynamic clock by reading the frequency and setting the
>> divisor in the transfer function instead of during probe.
> Is this fixing some particular case you could note in the commit
> message? As is, it makes me think that we should be using a notifier
> for when the parent clock (that's the one I assume you're talking about
> being dynamic) changes. But maybe you're working around a variable VPU
> clock being set by the firmware, because we don't have a notifier for
> it?
>
> I'm a bit worried because I think this is going to be pretty expensive
> to be doing per transfer.
Well, the clocks are all configured without CLK_GET_RATE_NOCACHE et. al.,
so the value is read from cache, which is not (very) expensive
(see clk_core_get_rate).
This also means that any clock change of the VPU done by the firmware
does not propagate to the linux kernel anyway and the unchanged
cached value is returned.
To make this work it would require a notification mechanism from the
firmware to trigger a re-validation of all the caches. (or some sort of
watchdog
process).
Adding a notifier to each driver (I2C, SPI) instead is - imo - a lot of
unnecessary
code complexity, as any currently running transfer would still be impacted,
because changing the clock-divider in flight is a asking for trouble.
But then changing the vpu-clock speed while a I2s/SPI/... transfer is
running is
also asking for trouble....
The only place where - IMO - a notifier would make sense is with the
auxiliar
UART driver(8250_bcm2835aux.c), as there we only read the clock rates
when setting/changing the baud rate. But - again - this would require some
notification by the firmware in the first place and any reception in the
window of change would go wrong because of unexpected effective baud
rate changes.
So as far as I can tell the change to read the current clock rate in the
transfer function is a reasonable approach and the clock framework should
handle the communication with the firmware about such changes.
(And I remember having had some discussions around this subject
with Phil Elwell or popcornmix some time ago on github where it boiled
down to: what is the "right" interface? - I can not find the reference
right now)
Reviewed-by: Martin Sperl <kernel@martin.sperl.org>
Thanks, Martin
^ permalink raw reply
* [PATCH] MAINTAINERS: update entry for atmel_serial driver
From: Greg Kroah-Hartman @ 2016-09-29 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3dc3a39b-5cae-1ad1-df44-bed4703121c3@atmel.com>
On Thu, Sep 29, 2016 at 09:37:46AM +0200, Nicolas Ferre wrote:
> Le 29/09/2016 ? 08:31, Greg Kroah-Hartman a ?crit :
> > On Wed, Sep 28, 2016 at 05:47:35PM +0200, Nicolas Ferre wrote:
> >> Change maintainer for the serial driver found on most of the
> >> Microchip / Atmel MPUs and take advantage of the move to rename
> >> and reorder the entry.
> >> I'm happy that Richard is taking over the maintenance of this
> >> driver.
> >>
> >> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> >> Acked-by: Richard Genoud <richard.genoud@gmail.com>
> >> ---
> >> MAINTAINERS | 11 ++++++-----
> >> 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > This doesn't apply to my tty-next tree at all, what did you make it
> > against?
>
> Yesterdays' linux-next (next-20160928 tag). I thought it would be the
> best for easy pick-up by anybody, particularly on a highly shared file
> like MAINTAINERS.
>
> Tell me if you want me to collect all tags, rebase on tty-next and re-send.
It's ok, I've fixed it up by hand, it's a tough file to handle at times
with lots of different trees touching it like you mention.
greg k-h
^ permalink raw reply
* [PATCH] arm64: set path to Image.gz in the mkspec to avoid rpm build issue
From: Vadim Lomovtsev @ 2016-09-29 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9900a5d1-d133-12dc-0ff1-9370e6dab7a7@suse.com>
On Thu, Sep 29, 2016 at 09:23:51AM +0200, Michal Marek wrote:
> On 2016-09-28 11:49, Will Deacon wrote:
> > [Adding Michal Marek]
> >
> > On Tue, Sep 27, 2016 at 08:53:47AM -0700, Vadim Lomovtsev wrote:
> >> In addition to http://www.spinics.net/lists/arm-kernel/msg527466.html
> >>
> >> While building rpm-pkg target it fails to copy kernel image
> >> from default location to rpm buildroot directory.
> >>
> >> Since we have arch variable set to aarch64 while Image.gz
> >> is located at arch/arm64/boot it's necessary to specify
> >> correct path to cp command as it implemeted for ppc64 build.
>
> The variable should point to the actual file. ppc64 should be fixed as well.
>
> Michal
Understood. Thanks for feed-back.
Vadim
^ permalink raw reply
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Chris Wilson @ 2016-09-29 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929073411.3154-1-jszhang@marvell.com>
On Thu, Sep 29, 2016 at 03:34:11PM +0800, Jisheng Zhang wrote:
> On Marvell berlin arm64 platforms, I see the preemptoff tracer report
> a max 26543 us latency at __purge_vmap_area_lazy, this latency is an
> awfully bad for STB. And the ftrace log also shows __free_vmap_area
> contributes most latency now. I noticed that Joel mentioned the same
> issue[1] on x86 platform and gave two solutions, but it seems no patch
> is sent out for this purpose.
>
> This patch adopts Joel's first solution, but I use 16MB per core
> rather than 8MB per core for the number of lazy_max_pages. After this
> patch, the preemptoff tracer reports a max 6455us latency, reduced to
> 1/4 of original result.
My understanding is that
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 91f44e78c516..3f7c6d6969ac 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -626,7 +626,6 @@ void set_iounmap_nonlazy(void)
static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
int sync, int force_flush)
{
- static DEFINE_SPINLOCK(purge_lock);
struct llist_node *valist;
struct vmap_area *va;
struct vmap_area *n_va;
@@ -637,12 +636,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
* should not expect such behaviour. This just simplifies locking for
* the case that isn't actually used at the moment anyway.
*/
- if (!sync && !force_flush) {
- if (!spin_trylock(&purge_lock))
- return;
- } else
- spin_lock(&purge_lock);
-
if (sync)
purge_fragmented_blocks_allcpus();
@@ -667,7 +660,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
__free_vmap_area(va);
spin_unlock(&vmap_area_lock);
}
- spin_unlock(&purge_lock);
}
/*
should now be safe. That should significantly reduce the preempt-disabled
section, I think.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply related
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Jisheng Zhang @ 2016-09-29 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929081818.GE28107@nuc-i3427.alporthouse.com>
On Thu, 29 Sep 2016 09:18:18 +0100 Chris Wilson wrote:
> On Thu, Sep 29, 2016 at 03:34:11PM +0800, Jisheng Zhang wrote:
> > On Marvell berlin arm64 platforms, I see the preemptoff tracer report
> > a max 26543 us latency at __purge_vmap_area_lazy, this latency is an
> > awfully bad for STB. And the ftrace log also shows __free_vmap_area
> > contributes most latency now. I noticed that Joel mentioned the same
> > issue[1] on x86 platform and gave two solutions, but it seems no patch
> > is sent out for this purpose.
> >
> > This patch adopts Joel's first solution, but I use 16MB per core
> > rather than 8MB per core for the number of lazy_max_pages. After this
> > patch, the preemptoff tracer reports a max 6455us latency, reduced to
> > 1/4 of original result.
>
> My understanding is that
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 91f44e78c516..3f7c6d6969ac 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -626,7 +626,6 @@ void set_iounmap_nonlazy(void)
> static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> int sync, int force_flush)
> {
> - static DEFINE_SPINLOCK(purge_lock);
> struct llist_node *valist;
> struct vmap_area *va;
> struct vmap_area *n_va;
> @@ -637,12 +636,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> * should not expect such behaviour. This just simplifies locking for
> * the case that isn't actually used at the moment anyway.
> */
> - if (!sync && !force_flush) {
> - if (!spin_trylock(&purge_lock))
> - return;
> - } else
> - spin_lock(&purge_lock);
> -
> if (sync)
> purge_fragmented_blocks_allcpus();
>
> @@ -667,7 +660,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> __free_vmap_area(va);
> spin_unlock(&vmap_area_lock);
Hi Chris,
Per my test, the bottleneck now is __free_vmap_area() over the valist, the
iteration is protected with spinlock vmap_area_lock. So the larger lazy max
pages, the longer valist, the bigger the latency.
So besides above patch, we still need to remove vmap_are_lock or replace with
mutex.
Thanks,
Jisheng
> }
> - spin_unlock(&purge_lock);
> }
>
> /*
>
>
> should now be safe. That should significantly reduce the preempt-disabled
> section, I think.
> -Chris
>
^ permalink raw reply
* [RFC PATCH 00/11] pci: support for configurable PCI endpoint
From: Kishon Vijay Abraham I @ 2016-09-29 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E8BB69.4020804@ti.com>
Hi Arnd,
On Monday 26 September 2016 11:38 AM, Kishon Vijay Abraham I wrote:
> Hi Arnd,
>
> On Thursday 22 September 2016 07:04 PM, Arnd Bergmann wrote:
>> On Thursday, September 15, 2016 2:03:05 PM CEST Kishon Vijay Abraham I wrote:
>>> On Wednesday 14 September 2016 06:55 PM, Arnd Bergmann wrote:
>>>> On Wednesday, September 14, 2016 10:41:56 AM CEST Kishon Vijay Abraham I wrote:
>>>> I've added the drivers/ntb maintainers to Cc, given that there is
>>>> a certain degree of overlap between your work and the existing
>>>> code, I think they should be part of the discussion.
>>>>
>>>>> Known Limitation:
>>>>> *) Does not support multi-function devices
>>>>
>>>> If I understand it right, this was a problem for USB and adding
>>>> it later made it somewhat inconsistent. Maybe we can at least
>>>> try to come up with an idea of how multi-function devices
>>>> could be handled even if we don't implement it until someone
>>>> actually needs it.
>>>
>>> Actually IMO multi-function device in PCI should be much simpler than it is for
>>> USB. In the case of USB, all the functions in a multi-function device will
>>> share the same *usb configuration* . (USB device can have multiple
>>> configuration but only one can be enabled at a time). A multi-function USB
>>> device will still have a single vendor-id/product-id/class... So I think a
>>> separate library (composite.c) in USB makes sense.
>>
>> Ok, makes sense.
>>
>>> But in the case of PCI, every function can be treated independently since all
>>> the functions have it's own 4KB configuration space. Each function can be
>>> configured independently. Each can have it's own vendor-id/product-id/class..
>>> I'm not sure if we'll need a separate library for PCI like we have for USB.
>>
>> I think it depends on whether we want to add the software multi-function
>> support you mention.
>>
>>> Now the restriction for not allowing multi-function device is because of the
>>> following structure definition.
>>>
>>> struct pci_epc {
>>> ..
>>> struct pci_epf *epf;
>>> ..
>>> };
>>>
>>> EPC has a single reference to EPF and it is used *only* to notify the function
>>> driver when the link is up. (If this can be changed to use notification
>>> mechanism, multi-function devices can be supported here)
>>>
>>> One more place where this restriction arises is in designware driver
>>>
>>> struct dw_pcie_ep {
>>> ..
>>> u8 bar_to_atu[6];
>>> ..
>>> };
>>>
>>> We use single ATU window to configure a BAR (in BAR). If there are multiple
>>> functions, then this should also be modified since each function has 6 BARs.
>>>
>>> This can be fixed without much effort unless some other issue props up.
>>
>> Ok.
>>
>>>>
>>>> Is your hardware able to make the PCIe endpoint look like
>>>> a device with multiple PCI functions, or would one have to
>>>> do this in software inside of a single PCI function if we
>>>> ever need it?
>>>
>>> The hardware I have doesn't support multiple PCI functions (like having a
>>> separate configuration space for each function). It has a dedicated space for
>>> configuration space supporting only one function. [Section 24.9.7.3.2
>>> PCIe_SS_EP_CFG_DBICS Register Description in [1]].
>>>
>>> yeah, it has to be done in software (but that won't be multi-function device in
>>> PCI terms).
>>>
>>> [1] -> http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf
>>
>> Ok, so in theory there can be other hardware (and quite likely is)
>> that supports multiple functions, and we can extend the framework
>> to support them without major obstacles, but your hardware doesn't,
>> so you kept it simple with one hardcoded function, right?
>
> right, PCIe can have upto 8 functions. So the issues with the current framework
> has to be fixed. I don't expect major obstacles with this as of now.
>>
>> Seems completely reasonable to me.
>>
>>>>> TODO:
>>>>> *) access buffers in RC
>>>>> *) raise MSI interrupts
>>>>> *) Enable user space control for the RC side PCI driver
>>>>
>>>> The user space control would end up just being one of several
>>>> gadget drivers, right? E.g. gadget drivers for standard hardware
>>>> (8250 uart, ATA, NVMe, some ethernet) could be done as kernel
>>>> drivers while a user space driver can be used for things that
>>>> are more unusual and that don't need to interface to another
>>>> part of the kernel?
>>>
>>> Actually I didn't mean that. It was more with respect to the host side PCI test
>>> driver (drivers/misc/pci_endpoint_test.c). Right now it validates BAR, irq
>>> itself. I wanted to change this so that the user controls which tests to run.
>>> (Like for USB gadget zero tests, testusb.c invokes ioctls to perform various
>>> tests). Similarly I want to have a userspace program invoke pci_endpoint_test
>>> to perform various PCI tests.
>>
>> Ok, I see. So what I described above would be yet another function
>> driver that can be implemented, but so far, you have not planned
>> to do that because there was not need, right?
>
> right. I felt pci_endpoint_test is the generic function that would be of
> interest to all the vendors. Any new function can be added by taking
> pci_endpoint_test as a reference.
>
> The simple usecase I plan to work on after completing the framework is to have
> a camera sensor in one board and display in another board (the boards connected
> using PCIe) and the display showing the the camera capture.
>>
>>>>
>>>>> *) Adapt all other users of designware to use the new design (only
>>>>> dra7xx has been adapted)
>>>>
>>>> I don't fully understand this part. Does every designware based
>>>> driver need modifications, or are the changes to the
>>>> generic parts of the designware driver enough to make it
>>>> work for the simpler platforms?
>>>
>>> I have changed the core designware driver structures (like previously the
>>> platform drivers will only use pcie_port, but now I introduced struct dw_pcie
>>> to support both host and endpoint). This will break (compilation failure) all
>>> the designware based drivers (except dra7xx). All these drivers should be
>>> adapted to the new change (even if they work only in host mode these has to be
>>> adapted).
>>
>> Ah, so we have to do two separate modifications to each designware driver:
>>
>> a) make it work with your patch (mandatory)
>> b) make it support endpoint mode (optional)
>
> yes.
>>
>>>>> HOW TO:
>>>>>
>>>>> ON THE EP SIDE:
>>>>> ***************
>>>>>
>>>>> /* EP function is configured using configfs */
>>>>> # mount -t configfs none /sys/kernel/config
>>>>>
>>>>> /* PCI EP core layer creates "pci_ep" entry in configfs */
>>>>> # cd /sys/kernel/config/pci_ep/
>>>>>
>>>>> /*
>>>>> * This is the 1st step in creating an endpoint function. This
>>>>> * creates the endpoint function device *instance*. The string
>>>>> * before the .<num> suffix will identify the driver this
>>>>> * EP function will bind to.
>>>>> * Just pci_epf_test is also valid. The .<num> suffix is used
>>>>> * if there are multiple PCI controllers and all of them wants
>>>>> * to use the same function.
>>>>> */
>>>>> # mkdir pci_epf_test.0
>>>>
>>>> I haven't used USB gadgets, but I assume this is modeled around
>>>> the same interface. If there are notable differences, please mention
>>>> what they are. Otherwise the general concept seems rather nice to me.
>>>
>>> Yeah, both USB gadget and PCI endpoint use configfs interface but the semantics
>>> are quite different.
>>>
>>> Every directory in *usb_gadget* corresponds to a gadget device, and the gadget
>>> device has a functions sub-directory which has the USB functions. And these
>>> directories have fields or attributes specific to USB.
>>>
>>> But in the case of PCI, every directory in *pci_ep* corresponds to a PCI
>>> function and it has fields or attributes specific to PCI function.
>>
>> Ok, I see.
>>
>>> The main reason for using configfs for PCI endpoint is to give the users to
>>> control "which function has to be bound to which controller". The same concept
>>> is used for USB gadget as well but there it is "which gadget device has to be
>>> bound to which controller".
>>
>> We should still find out whether it's important that you can have
>> a single PCI function with a software multi-function support of some
>> sort. We'd still be limited to six BARs in total, and would also need
>> something to identify those sub-functions, so implementing that might
>> get quite hairy.
Thought a bit on how to implement this and felt we should have the following
entities:-
* Function (or main function)
* sub-Function
* device
Function: a single PCI function (as defined in the PCI specification with a
separate configuration space). It will have control over the PCI header, manage
BAR's and interrupts. It may or may not have sub-functions (sub-functions can
be one or many).
Managing BAR's: The sub-functions will not have information
about BAR's. It will just request the number of
address space it requires to the main *function*. The
main function will allocate one BAR for each such
request based on the BAR availability.
Managing interrupts:
FOR MSI: Say each main function is capable of supporting 32 MSI
interrupts. Each sub-function can request 'n' number
of interrupts. (The sub-function will not be aware of
the MSI number allocated to it). For each
sub-function the interrupts will be numbered from
'1..n'. The main function will map the sub-function
interrupt to MSI interrupt number.
For legacy: No management is required, since one interrupt
line will be shared by all sub-functions. The host
driver will check the interrupt status register.
Is there any thing else that has to be managed by the main Function?
Here the framework should be modified to add a new interface between the
sub-function and main Function. A *simple* main Function should also be added
to manage only the BARs and interrupts. For any special use case, new main
Function has to be created.
The host side driver for this main function will be bound to it using the
existing PCI host side mechanism. (using device id/vendor id/class code etc..).
sub-Function: Not defined in PCI specification. It will be *part* of the main
function. There can be one or more sub-function within a main function. Each
sub-function within a main function will be independent of each other.
It will request the number of local address space required and the number of
MSI interrupts from the main function.
Each sub-function should have a separate host side driver. But how do we bind
the host side driver with the sub-function? Here the existing host side PCI
framework won't work.
Some options for binding sub-function to it's host side driver:
Have a separate vendor-id/product id for each sub function. (But the *pci_dev*
for the sub-function will not be created by host side PCI framework. The PCI
framework shouldn't also have to do it because this is not standard).
The main *function* driver will scan the list of it's sub-functions (We can
make the 1st BAR to be used by main *Function* and have these informations
there.) and for each function it creates a new *pci_dev* allocating the memory
resources. This way the sub-function host side driver can be created just like
a regular PCI driver. I'm not sure if creating a pci_dev from a pci driver will
have any adverse effects.
The other option is to define a new type of device (say pci_func_dev) and make
the main *function* driver create these devices when it is getting probed. For
binding, we can maybe just use a compatible string populated by the
sub-function driver when it registers with the main function driver. Since this
doesn't use an existing data structure, this should not be very difficult to
implement.
With either options, lspci won't list any sub-functions.
device: one or more function (main function) will constitute a device. This
shouldn't be too difficult to implement.
I think most of the complexity lies in the design of sub-function. Please let
me know your thoughts and other ideas.
Thanks
Kishon
^ permalink raw reply
* [PATCH v12 0/8] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
From: wangxiongfeng (C) @ 2016-09-29 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473763144-5653-1-git-send-email-fu.wei@linaro.org>
for sbsa watchdog part, Tested-by: wangxiongfeng2 at huawei.com on D05 board.
On 2016/9/13 18:38, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei@linaro.org>
>
> This patchset:
> (1)Preparation for adding GTDT support in arm_arch_timer:
> 1. Move some enums and marcos to header file;
> 2. Add a new enum for spi type;
> 3. Improve printk relevant code.
>
> (2)Introduce ACPI GTDT parser: drivers/acpi/arm64/acpi_gtdt.c
> Parse all kinds of timer in GTDT table of ACPI:arch timer,
> memory-mapped timer and SBSA Generic Watchdog timer.
> This driver can help to simplify all the relevant timer drivers,
> and separate all the ACPI GTDT knowledge from them.
>
> (3)Simplify ACPI code for arm_arch_timer
>
> (4)Add GTDT support for ARM memory-mapped timer
>
> This patchset depends on the following patchset:
> [UPDATE PATCH V11 1/8] ACPI: I/O Remapping Table (IORT) initial support
> https://lkml.org/lkml/2016/9/12/949
>
> This patchset has been tested on the following platforms:
> (1)ARM Foundation v8 model
>
> Changelog:
> v12: https://lkml.org/lkml/2016/9/13/
> Rebase to latest Linux 4.8-rc6
> Delete the confusing "skipping" in the error message.
>
> V11: https://lkml.org/lkml/2016/9/6/354
> Rebase to latest Linux 4.8-rc5
> Delete typedef (suggested by checkpatch.pl)
>
> V10: https://lkml.org/lkml/2016/7/26/215
> Drop the "readq" patch.
> Rebase to latest Linux 4.7.
>
> V9: https://lkml.org/lkml/2016/7/25/345
> Improve pr_err message in acpi gtdt driver.
> Update Commit message for 7/9
> shorten the irq mapping function name
> Improve GTDT driver for memory-mapped timer
>
> v8: https://lkml.org/lkml/2016/7/19/660
> Improve "pr_fmt(fmt)" definition: add "ACPI" in front of "GTDT",
> and also improve printk message.
> Simplify is_timer_block and is_watchdog.
> Merge acpi_gtdt_desc_init and gtdt_arch_timer_init into acpi_gtdt_init();
> Delete __init in include/linux/acpi.h for GTDT API
> Make ARM64 select GTDT.
> Delete "#include <linux/module.h>" from acpi_gtdt.c
> Simplify GT block parse code.
>
> v7: https://lkml.org/lkml/2016/7/13/769
> Move the GTDT driver to drivers/acpi/arm64
> Add add the ARM64-specific ACPI Support maintainers in MAINTAINERS
> Merge 3 patches of GTDT parser driver.
> Fix the for_each_platform_timer bug.
>
> v6: https://lkml.org/lkml/2016/6/29/580
> split the GTDT driver to 4 parts: basic, arch_timer, memory-mapped timer,
> and SBSA Generic Watchdog timer
> Improve driver by suggestions and example code from Daniel Lezcano
>
> v5: https://lkml.org/lkml/2016/5/24/356
> Sorting out all patches, simplify the API of GTDT driver:
> GTDT driver just fills the data struct for arm_arch_timer driver.
>
> v4: https://lists.linaro.org/pipermail/linaro-acpi/2016-March/006667.html
> Delete the kvm relevant patches
> Separate two patches for sorting out the code for arm_arch_timer.
> Improve irq info export code to allow missing irq info in GTDT table.
>
> v3: https://lkml.org/lkml/2016/2/1/658
> Improve GTDT driver code:
> (1)improve pr_* by defining pr_fmt(fmt)
> (2)simplify gtdt_sbsa_gwdt_init
> (3)improve gtdt_arch_timer_data_init, if table is NULL, it will try
> to get GTDT table.
> Move enum ppi_nr to arm_arch_timer.h, and add enum spi_nr.
> Add arm_arch_timer get ppi from DT and GTDT support for kvm.
>
> v2: https://lkml.org/lkml/2015/12/2/10
> Rebase to latest kernel version(4.4-rc3).
> Fix the bug about the config problem,
> use CONFIG_ACPI_GTDT instead of CONFIG_ACPI in arm_arch_timer.c
>
> v1: The first upstreaming version: https://lkml.org/lkml/2015/10/28/553
>
> Fu Wei (8):
> clocksource/drivers/arm_arch_timer: Move enums and defines to header
> file
> clocksource/drivers/arm_arch_timer: Add a new enum for spi type
> clocksource/drivers/arm_arch_timer: Improve printk relevant code
> acpi/arm64: Add GTDT table parse driver
> clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
> acpi/arm64: Add memory-mapped timer support in GTDT driver
> clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped
> timer
> acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver
>
> arch/arm64/Kconfig | 1 +
> drivers/acpi/arm64/Kconfig | 3 +
> drivers/acpi/arm64/Makefile | 1 +
> drivers/acpi/arm64/gtdt.c | 309 +++++++++++++++++++++++++++++++++++
> drivers/clocksource/Kconfig | 2 +-
> drivers/clocksource/arm_arch_timer.c | 225 +++++++++++++++++--------
> drivers/watchdog/Kconfig | 1 +
> include/clocksource/arm_arch_timer.h | 32 ++++
> include/linux/acpi.h | 7 +
> 9 files changed, 510 insertions(+), 71 deletions(-)
> create mode 100644 drivers/acpi/arm64/gtdt.c
>
^ permalink raw reply
* [PATCH] drm/mediatek: fix a typo
From: Matthias Brugger @ 2016-09-29 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475121682.18843.2.camel@mtksdaap41>
On 29/09/16 06:01, CK Hu wrote:
> Acked-by: CK Hu <ck.hu@mediatek.com>
>
> On Thu, 2016-09-29 at 11:22 +0800, Bibby Hsieh wrote:
>> Fix the typo: OD_RELAYMODE->OD_CFG
>>
Although it is quite clear what the patch does, could you write one
sentence to explain what it does. Maybe explain even which effect it
has, which error get fixed etc.
As we are getting public available boards now, we should take more care
about fixes. If you have a fix for a commit introduced in an earlier
version of linux and it should be fixed for this version as well (e.g.
v4.6 does have the feature but it does not work correctly) then please
add these two lines before your Signed-off-by:
Fixes: <commit-hash> ("<commit subject line>")
Cc: stable at vger.kernel.org # v4.6+
Where v4.6+ stands for the oldest version where this should get fixed.
Thanks a lot,
Matthias
>> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
>> ---
>> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>> index df33b3c..aa5f20f 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>> @@ -123,7 +123,7 @@ static void mtk_od_config(struct mtk_ddp_comp *comp, unsigned int w,
>> unsigned int bpc)
>> {
>> writel(w << 16 | h, comp->regs + DISP_OD_SIZE);
>> - writel(OD_RELAYMODE, comp->regs + OD_RELAYMODE);
>> + writel(OD_RELAYMODE, comp->regs + OD_CFG);
>> mtk_dither_set(comp, bpc, DISP_OD_CFG);
>> }
>>
>
>
^ permalink raw reply
* Crash seen on ARM Juno r1 with 4.8-rc8 when Coresight is enabled
From: Rabin Vincent @ 2016-09-29 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkypz383Smuqv3B5K3i9mzGxMdc1OJdc_tWQZ5qHWQCeJw@mail.gmail.com>
On Wed, Sep 28, 2016 at 11:41:41AM -0600, Mathieu Poirier wrote:
> On 28 September 2016 at 10:35, Venkatesh Vivekanandan
> <venkatesh.vivekanandan@broadcom.com> wrote:
> > [ 5.479353] Unable to handle kernel NULL pointer dereference at
> > virtual address 00000000
> > [ 5.487372] pgd = ffff000008db1000
> > [ 5.490739] [00000000] *pgd=00000009ffffe003,
> > *pud=00000009ffffd003, *pmd=0000000000000000
> > [ 5.498940] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > [ 5.504451] Modules linked in:
> > [ 5.507474] CPU: 0 PID: 449 Comm: kworker/0:1 Not tainted 4.8.0-rc8-dirty #1
> > [ 5.514447] Hardware name: ARM Juno development board (r1) (DT)
> > [ 5.520310] Workqueue: events amba_deferred_retry_func
> > [ 5.525394] task: ffff800976bfd780 task.stack: ffff8009760bc000
> > [ 5.531253] PC is at strcmp+0x1c/0x160
> > [ 5.534962] LR is at coresight_orphan_match+0x78/0xc8
> > [ 5.539957] pc : [<ffff00000835f14c>] lr : [<ffff00000870231c>]
> > pstate: 40000145
> > [ 5.547272] sp : ffff8009760bfa00
> > [ 5.550547] x29: ffff8009760bfa00 x28: ffff8009762c7f00
> > [ 5.555807] x27: ffff000008d66e46 x26: 0000000000000000
> > [ 5.561066] x25: 0000000000000001 x24: ffff000008702048
> > [ 5.566325] x23: 0000000000000000 x22: ffff800973ce5000
> > [ 5.571584] x21: ffff800973ce0800 x20: 0000000000000000
> > [ 5.576843] x19: ffff800976b08600 x18: 0000000000000000
> > [ 5.582101] x17: 0000000000000000 x16: ffff000008e52fff
> > [ 5.587360] x15: ffff000008e52fff x14: ffffffffffffffff
> > [ 5.592619] x13: ffff000008ca5000 x12: 0000000000000008
> > [ 5.597878] x11: 0000000000000020 x10: 0101010101010101
> > [ 5.603137] x9 : 0000000000000000 x8 : 7fff7f7f7f7f7f7f
> > [ 5.608396] x7 : 0000000000000000 x6 : 000000008008cb22
> > [ 5.613655] x5 : 22cb080000000000 x4 : ffff800973ce0828
> > [ 5.618914] x3 : 0000000000000000 x2 : 3030303031303032
> > [ 5.624173] x1 : 0000000000000000 x0 : ffff8009760f1d08
> > [ 5.629432]
>
> Thanks you for reporting this Vankatesh,
>
> Sudeep and Suzuki, can you guys help me with this - I don't have an R1
> to test with.
I've seen this too, on other platforms. This should fix it:
8<-----------
>From a9da7d7b47e67dd6ffcafddadb50e6f97503f296 Mon Sep 17 00:00:00 2001
From: Rabin Vincent <rabinv@axis.com>
Date: Tue, 30 Aug 2016 08:54:21 +0200
Subject: [PATCH] coresight: check for NULL child_name
Connection child names associated to ports can sometimes be NULL, which
is the case when booting a system on QEMU or when the Coresight power
domain isn't switched on. fadf3a44e974 ("coresight: checking for NULL
string in coresight_name_match()") fixed one place to handle this but
the same check is needed in coresight_orphan_match() to prevent a crash
there.
Signed-off-by: Rabin Vincent <rabinv@axis.com>
---
drivers/hwtracing/coresight/coresight.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index d08d1ab..ceeaaea 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -725,7 +725,8 @@ static int coresight_orphan_match(struct device *dev, void *data)
/* We have found at least one orphan connection */
if (conn->child_dev == NULL) {
/* Does it match this newly added device? */
- if (!strcmp(dev_name(&csdev->dev), conn->child_name)) {
+ if (conn->child_name &&
+ !strcmp(dev_name(&csdev->dev), conn->child_name)) {
conn->child_dev = csdev;
} else {
/* This component still has an orphan */
--
2.1.4
^ permalink raw reply related
* [PATCH] ARM: *: mm: Implement get_user_pages_fast()
From: Rabin Vincent @ 2016-09-29 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACOPJM6AC5TwSEPUA7Df8F-FuChrjVP1TWVNeSrHt6ZaSyFiGg@mail.gmail.com>
On Tue, Sep 20, 2016 at 07:00:28PM -0700, Yuriy Romanenko wrote:
> +int get_user_pages_fast(unsigned long start, int nr_pages, int write,
> + struct page **pages)
> +{
> + struct mm_struct *mm = current->mm;
> + int ret;
> + unsigned long page_addr = (start & PAGE_MASK);
> + int nr = 0;
> +
> + struct gup_private_data private_data = {
> + .nr = 0,
> + .pages = pages,
> + .write = write
> + };
> +
> + struct mm_walk gup_walk = {
> + .pte_entry = gup_pte_entry,
> + .pte_hole = gup_pte_hole_entry,
> + .mm = mm,
> + .private = (void *)&private_data
> + };
> +
> + ret = walk_page_range(page_addr,
> + page_addr + nr_pages * PAGE_SIZE,
> + &gup_walk);
> + nr = ret ? ret : nr_pages;
walk_page_range() can't be called without the mmap_sem.
* Locking:
* Callers of walk_page_range() and walk_page_vma() should hold
* @walk->mm->mmap_sem, because these function traverse vma list and/or
* access to vma's data.
*/
int walk_page_range(unsigned long start, unsigned long end,
struct mm_walk *walk)
{
int err = 0;
unsigned long next;
struct vm_area_struct *vma;
if (start >= end)
return -EINVAL;
if (!walk->mm)
return -EINVAL;
VM_BUG_ON_MM(!rwsem_is_locked(&walk->mm->mmap_sem), walk->mm);
^ permalink raw reply
* Crash seen on ARM Juno r1 with 4.8-rc8 when Coresight is enabled
From: Sudeep Holla @ 2016-09-29 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkypz383Smuqv3B5K3i9mzGxMdc1OJdc_tWQZ5qHWQCeJw@mail.gmail.com>
Hi Mathieu,
On 28/09/16 18:41, Mathieu Poirier wrote:
> On 28 September 2016 at 10:35, Venkatesh Vivekanandan
> <venkatesh.vivekanandan@broadcom.com> wrote:
>> Hi All,
>>
>> I am trying to boot 4.8-rc8 in ARM Juno r1 board with coresight
>> enabled and could see crash. When coresight is disabled at kernel
>> config, then it boots to the linux prompt with rootfs in USB.
>>
>> I am using UEFI binary that came along with Juno-r1 board.
>>
>> Used following Image and dtb,
>>
[...]
>
> Thanks you for reporting this Vankatesh,
>
> Sudeep and Suzuki, can you guys help me with this - I don't have an R1
> to test with.
>
R1 and R2 are almost same except A57 is replaced by A72.
Anyways I reported the exact crash along with the fix sometime in June.
It got missed in v4.8, but is already queued in linux-next(in-fact twice
;), from your tree as well as greg's).
e05b386c878d coresight: access conn->child_name only if it's initialised
b8392153721c coresight: access conn->child_name only if it's initialised
--
Regards,
Sudeep
^ permalink raw reply
* Crash seen on ARM Juno r1 with 4.8-rc8 when Coresight is enabled
From: Sudeep Holla @ 2016-09-29 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929084953.GA24154@lnxartpec.se.axis.com>
On 29/09/16 09:49, Rabin Vincent wrote:
> On Wed, Sep 28, 2016 at 11:41:41AM -0600, Mathieu Poirier wrote:
[...]
>> Thanks you for reporting this Vankatesh,
>>
>> Sudeep and Suzuki, can you guys help me with this - I don't have an R1
>> to test with.
>
> I've seen this too, on other platforms. This should fix it:
>
> 8<-----------
> From a9da7d7b47e67dd6ffcafddadb50e6f97503f296 Mon Sep 17 00:00:00 2001
> From: Rabin Vincent <rabinv@axis.com>
> Date: Tue, 30 Aug 2016 08:54:21 +0200
> Subject: [PATCH] coresight: check for NULL child_name
>
> Connection child names associated to ports can sometimes be NULL, which
> is the case when booting a system on QEMU or when the Coresight power
> domain isn't switched on. fadf3a44e974 ("coresight: checking for NULL
> string in coresight_name_match()") fixed one place to handle this but
> the same check is needed in coresight_orphan_match() to prevent a crash
> there.
>
Thanks Rabin, we have exact same fix in linux-next already.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2] usb: ohci-at91: Use descriptor-based gpio APIs
From: Wenyou Yang @ 2016-09-29 9:59 UTC (permalink / raw)
To: linux-arm-kernel
Use the descriptor-based interface to manipulate GPIOs, instead of
the legacy integer-based interface.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
Changes in v2:
- Retain the vbus_pin_active_low[] member and its manipulations.
drivers/usb/host/ohci-at91.c | 121 +++++++++++--------------------------------
1 file changed, 31 insertions(+), 90 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index d177372..98047bf 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -14,8 +14,8 @@
#include <linux/clk.h>
#include <linux/dma-mapping.h>
+#include <linux/gpio/consumer.h>
#include <linux/of_platform.h>
-#include <linux/of_gpio.h>
#include <linux/platform_device.h>
#include <linux/platform_data/atmel.h>
#include <linux/io.h>
@@ -36,8 +36,8 @@
#define AT91_MAX_USBH_PORTS 3
struct at91_usbh_data {
- int vbus_pin[AT91_MAX_USBH_PORTS]; /* port power-control pin */
- int overcurrent_pin[AT91_MAX_USBH_PORTS];
+ struct gpio_desc *vbus_pin[AT91_MAX_USBH_PORTS];
+ struct gpio_desc *overcurrent_pin[AT91_MAX_USBH_PORTS];
u8 ports; /* number of ports on root hub */
u8 overcurrent_supported;
u8 vbus_pin_active_low[AT91_MAX_USBH_PORTS];
@@ -243,11 +243,8 @@ static void ohci_at91_usb_set_power(struct at91_usbh_data *pdata, int port, int
if (!valid_port(port))
return;
- if (!gpio_is_valid(pdata->vbus_pin[port]))
- return;
-
- gpio_set_value(pdata->vbus_pin[port],
- pdata->vbus_pin_active_low[port] ^ enable);
+ gpiod_set_value(pdata->vbus_pin[port],
+ pdata->vbus_pin_active_low[port] ^ enable);
}
static int ohci_at91_usb_get_power(struct at91_usbh_data *pdata, int port)
@@ -255,11 +252,8 @@ static int ohci_at91_usb_get_power(struct at91_usbh_data *pdata, int port)
if (!valid_port(port))
return -EINVAL;
- if (!gpio_is_valid(pdata->vbus_pin[port]))
- return -EINVAL;
-
- return gpio_get_value(pdata->vbus_pin[port]) ^
- pdata->vbus_pin_active_low[port];
+ return gpiod_get_value(pdata->vbus_pin[port]) ^
+ pdata->vbus_pin_active_low[port];
}
/*
@@ -406,16 +400,13 @@ static irqreturn_t ohci_hcd_at91_overcurrent_irq(int irq, void *data)
{
struct platform_device *pdev = data;
struct at91_usbh_data *pdata = dev_get_platdata(&pdev->dev);
- int val, gpio, port;
+ int val, port;
/* From the GPIO notifying the over-current situation, find
* out the corresponding port */
at91_for_each_port(port) {
- if (gpio_is_valid(pdata->overcurrent_pin[port]) &&
- gpio_to_irq(pdata->overcurrent_pin[port]) == irq) {
- gpio = pdata->overcurrent_pin[port];
+ if (gpiod_to_irq(pdata->overcurrent_pin[port]) == irq)
break;
- }
}
if (port == AT91_MAX_USBH_PORTS) {
@@ -423,7 +414,7 @@ static irqreturn_t ohci_hcd_at91_overcurrent_irq(int irq, void *data)
return IRQ_HANDLED;
}
- val = gpio_get_value(gpio);
+ val = gpiod_get_value(pdata->overcurrent_pin[port]);
/* When notified of an over-current situation, disable power
on the corresponding port, and mark this port in
@@ -454,9 +445,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct at91_usbh_data *pdata;
int i;
- int gpio;
int ret;
- enum of_gpio_flags flags;
+ int err;
u32 ports;
/* Right now device-tree probed devices don't get dma_mask set.
@@ -477,38 +467,16 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
pdata->ports = ports;
at91_for_each_port(i) {
- /*
- * do not configure PIO if not in relation with
- * real USB port on board
- */
- if (i >= pdata->ports) {
- pdata->vbus_pin[i] = -EINVAL;
- pdata->overcurrent_pin[i] = -EINVAL;
+ pdata->vbus_pin[i] = devm_gpiod_get_optional(&pdev->dev,
+ "atmel,vbus-gpio",
+ GPIOD_IN);
+ if (IS_ERR(pdata->vbus_pin[i])) {
+ err = PTR_ERR(pdata->vbus_pin[i]);
+ dev_err(&pdev->dev, "unable to claim gpio \"vbus\": %d\n", err);
continue;
}
- gpio = of_get_named_gpio_flags(np, "atmel,vbus-gpio", i,
- &flags);
- pdata->vbus_pin[i] = gpio;
- if (!gpio_is_valid(gpio))
- continue;
- pdata->vbus_pin_active_low[i] = flags & OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_request(gpio, "ohci_vbus");
- if (ret) {
- dev_err(&pdev->dev,
- "can't request vbus gpio %d\n", gpio);
- continue;
- }
- ret = gpio_direction_output(gpio,
- !pdata->vbus_pin_active_low[i]);
- if (ret) {
- dev_err(&pdev->dev,
- "can't put vbus gpio %d as output %d\n",
- gpio, !pdata->vbus_pin_active_low[i]);
- gpio_free(gpio);
- continue;
- }
+ pdata->vbus_pin_active_low[i] = gpiod_get_value(pdata->vbus_pin[i]);
ohci_at91_usb_set_power(pdata, i, 1);
}
@@ -518,37 +486,21 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
break;
pdata->overcurrent_pin[i] =
- of_get_named_gpio_flags(np, "atmel,oc-gpio", i, &flags);
-
- if (!gpio_is_valid(pdata->overcurrent_pin[i]))
- continue;
- gpio = pdata->overcurrent_pin[i];
-
- ret = gpio_request(gpio, "ohci_overcurrent");
- if (ret) {
- dev_err(&pdev->dev,
- "can't request overcurrent gpio %d\n",
- gpio);
+ devm_gpiod_get_optional(&pdev->dev,
+ "atmel,oc-gpio", GPIOD_IN);
+ if (IS_ERR(pdata->overcurrent_pin[i])) {
+ err = PTR_ERR(pdata->overcurrent_pin[i]);
+ dev_err(&pdev->dev, "unable to claim gpio \"overcurrent\": %d\n", err);
continue;
}
- ret = gpio_direction_input(gpio);
- if (ret) {
- dev_err(&pdev->dev,
- "can't configure overcurrent gpio %d as input\n",
- gpio);
- gpio_free(gpio);
- continue;
- }
-
- ret = request_irq(gpio_to_irq(gpio),
- ohci_hcd_at91_overcurrent_irq,
- IRQF_SHARED, "ohci_overcurrent", pdev);
- if (ret) {
- gpio_free(gpio);
- dev_err(&pdev->dev,
- "can't get gpio IRQ for overcurrent\n");
- }
+ ret = devm_request_irq(&pdev->dev,
+ gpiod_to_irq(pdata->overcurrent_pin[i]),
+ ohci_hcd_at91_overcurrent_irq,
+ IRQF_SHARED,
+ "ohci_overcurrent", pdev);
+ if (ret)
+ dev_info(&pdev->dev, "failed to request gpio \"overcurrent\" IRQ\n");
}
device_init_wakeup(&pdev->dev, 1);
@@ -561,19 +513,8 @@ static int ohci_hcd_at91_drv_remove(struct platform_device *pdev)
int i;
if (pdata) {
- at91_for_each_port(i) {
- if (!gpio_is_valid(pdata->vbus_pin[i]))
- continue;
+ at91_for_each_port(i)
ohci_at91_usb_set_power(pdata, i, 0);
- gpio_free(pdata->vbus_pin[i]);
- }
-
- at91_for_each_port(i) {
- if (!gpio_is_valid(pdata->overcurrent_pin[i]))
- continue;
- free_irq(gpio_to_irq(pdata->overcurrent_pin[i]), pdev);
- gpio_free(pdata->overcurrent_pin[i]);
- }
}
device_init_wakeup(&pdev->dev, 0);
--
2.7.4
^ permalink raw reply related
* [PATCH v1] usb: ohci-at91: Set RemoteWakeupConnected bit explicitly.
From: Wenyou Yang @ 2016-09-29 10:07 UTC (permalink / raw)
To: linux-arm-kernel
The reset value of RWC is 0, set RemoteWakeupConnected bit explicitly
before calling ohci_run, it also fixes the issue that the mass
storage stick connected wasn't suspended when the system suspend.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
drivers/usb/host/ohci-at91.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 98047bf..ff0d31a 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -202,6 +202,12 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
ohci->num_ports = board->ports;
at91_start_hc(pdev);
+ /*
+ * The RemoteWakeupConnected bit has to be set explicitly
+ * before calling ohci_run. The reset value of this bit is 0.
+ */
+ ohci->hc_control = OHCI_CTRL_RWC;
+
retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval == 0) {
device_wakeup_enable(hcd->self.controller);
@@ -554,9 +560,6 @@ ohci_hcd_at91_drv_suspend(struct device *dev)
* REVISIT: some boards will be able to turn VBUS off...
*/
if (!ohci_at91->wakeup) {
- ohci->hc_control = ohci_readl(ohci, &ohci->regs->control);
- ohci->hc_control &= OHCI_CTRL_RWC;
- ohci_writel(ohci, ohci->hc_control, &ohci->regs->control);
ohci->rh_state = OHCI_RH_HALTED;
/* flush the writes */
--
2.7.4
^ permalink raw reply related
* [PATCH 3.12 003/119] arm64: Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO
From: Jiri Slaby @ 2016-09-29 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a528a0fa6d67ebe60bfc762c72b316d28ed21dea.1475144721.git.jslaby@suse.cz>
From: James Hogan <james.hogan@imgtec.com>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit 3146bc64d12377a74dbda12b96ea32da3774ae07 upstream.
AT_VECTOR_SIZE_ARCH should be defined with the maximum number of
NEW_AUX_ENT entries that ARCH_DLINFO can contain, but it wasn't defined
for arm64 at all even though ARCH_DLINFO will contain one NEW_AUX_ENT
for the VDSO address.
This shouldn't be a problem as AT_VECTOR_SIZE_BASE includes space for
AT_BASE_PLATFORM which arm64 doesn't use, but lets define it now and add
the comment above ARCH_DLINFO as found in several other architectures to
remind future modifiers of ARCH_DLINFO to keep AT_VECTOR_SIZE_ARCH up to
date.
Fixes: f668cd1673aa ("arm64: ELF definitions")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
arch/arm64/include/asm/elf.h | 1 +
arch/arm64/include/uapi/asm/auxvec.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index e7fa87f9201b..a4e1758c44dc 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -124,6 +124,7 @@ extern unsigned long randomize_et_dyn(unsigned long base);
#define SET_PERSONALITY(ex) clear_thread_flag(TIF_32BIT);
+/* update AT_VECTOR_SIZE_ARCH if the number of NEW_AUX_ENT entries changes */
#define ARCH_DLINFO \
do { \
NEW_AUX_ENT(AT_SYSINFO_EHDR, \
diff --git a/arch/arm64/include/uapi/asm/auxvec.h b/arch/arm64/include/uapi/asm/auxvec.h
index 22d6d8885854..4cf0c17787a8 100644
--- a/arch/arm64/include/uapi/asm/auxvec.h
+++ b/arch/arm64/include/uapi/asm/auxvec.h
@@ -19,4 +19,6 @@
/* vDSO location */
#define AT_SYSINFO_EHDR 33
+#define AT_VECTOR_SIZE_ARCH 1 /* entries in ARCH_DLINFO */
+
#endif
--
2.10.0
^ permalink raw reply related
* [PATCH] Adding Support for Coresight Components on Zynq 7000.
From: Muhammad Abdul WAHAB @ 2016-09-29 10:26 UTC (permalink / raw)
To: linux-arm-kernel
The Coresight components are present on the Zynq SoC but the corresponding
device tree entries are missing. This patch adds device tree entries for
coresight components while explaining how it was done in order to allow
porting towards other boards easily.
By adding the entries for Coresight components in the device tree: if no
files are created in sysfile system, you need to contact the board designer
to sort out the problem. On some boards, Coresight components are not
powered on boot.
Signed-off-by: Muhammad Abdul Wahab <muhammadabdul.wahab@centralesupelec.fr>
---
The documentation file was very helpful
(Documentation/devicetree/bindings/arm/coresight.txt). However, few details
can be added to make it more clear for beginners.
Things to modify in device tree when changing the board are mainly:
- address
- `clocks` field
- some references in other entries may be missing (e.g. for `CPU` field in
ETM/PTM component, references need to be created)
Furthermore, the `reg` field should be adapted according to
`#address-cells` and `#size-cells`. It may appear obvious, not for
beginners.
## Testing
The trace sink components need to be enabled by accessing through sysfile
system.
echo 1 > /sys/bus/coresight/devices/@addr.etb/enable\_sink
Then enable the CS source component:
echo 1 > /sys/bus/coresight/devices/@addr.ptm/enable\_source
By default, CS Source components are configured to trace the kernel.
Then the trace can be read by dumping ETB.
dd if=/dev/@addr.etb of=trace_kernel.bin
The trace can be visualized by:
hexdump -C trace_kernel.bin
Or stored using:
hexdump -C trace_kernel.bin > trace_kernel.txt
The trace need to be decoded to be readable. All these above steps can now
be performed with Perf Library which was not available at the time I was
playing with DT entries.
--- linux-4.7/arch/arm/boot/dts/zynq-7000.dtsi.orig 2016-07-24
21:23:50.000000000 +0200
+++ linux-4.7/arch/arm/boot/dts/zynq-7000.dtsi 2016-09-28
19:13:52.651881000 +0200
@@ -363,5 +363,159 @@
reg = <0xf8005000 0x1000>;
timeout-sec = <10>;
};
+
+ etb at F8801000 {
+ compatible = "arm,coresight-etb10", "arm,primecell";
+ reg = <0xf8801000 0x1000>;
+ coresight-default-sink;
+ clocks = <&clkc 47>;
+ clock-names = "apb_pclk";
+
+ port {
+
+ endpoint at 0 {
+ slave-mode;
+ remote-endpoint = <0x8>;
+ linux,phandle = <0xd>;
+ phandle = <0xd>;
+ };
+ };
+ };
+
+ tpiu at F8803000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0xf8803000 0x1000>;
+ clocks = <&clkc 47>, <&clkc 16>;
+ clock-names = "apb_pclk", "fclk1";
+ clock-frequency=<0xee6b280>;
+
+ port {
+
+ endpoint at 0 {
+ slave-mode;
+ remote-endpoint = <0x9>;
+ linux,phandle = <0xe>;
+ phandle = <0xe>;
+ };
+ };
+ };
+
+ funnel at F8804000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0xf8804000 0x1000>;
+ clocks = <&clkc 47>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+
+ port at 0 {
+ reg = <0x0>;
+
+ endpoint {
+ remote-endpoint = <0xa>;
+ linux,phandle = <0xf>;
+ phandle = <0xf>;
+ };
+ };
+
+ port at 1 {
+ reg = <0x0>;
+
+ endpoint {
+ slave-mode;
+ remote-endpoint = <0xb>;
+ linux,phandle = <0x11>;
+ phandle = <0x11>;
+ };
+ };
+
+ port at 2 {
+ reg = <0x1>;
+
+ endpoint {
+ slave-mode;
+ remote-endpoint = <0xc>;
+ linux,phandle = <0x13>;
+ phandle = <0x13>;
+ };
+ };
+ };
+ };
+
+ replicator {
+ compatible = "arm,coresight-replicator";
+
+ ports {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+
+ port at 0 {
+ reg = <0x0>;
+
+ endpoint {
+ remote-endpoint = <0xd>;
+ linux,phandle = <0x8>;
+ phandle = <0x8>;
+ };
+ };
+
+ port at 1 {
+ reg = <0x1>;
+
+ endpoint {
+ remote-endpoint = <0xe>;
+ linux,phandle = <0x9>;
+ phandle = <0x9>;
+ };
+ };
+
+ port at 2 {
+ reg = <0x0>;
+
+ endpoint {
+ slave-mode;
+ remote-endpoint = <0xf>;
+ linux,phandle = <0xa>;
+ phandle = <0xa>;
+ };
+ };
+ };
+ };
+
+ ptm0 at F889C000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0xf889c000 0x1000>;
+ cpu = <0x10>;
+ clocks = <&clkc 47>;
+ clock-names = "apb_pclk";
+
+ port {
+
+ endpoint {
+ remote-endpoint = <0x11>;
+ linux,phandle = <0xb>;
+ phandle = <0xb>;
+ };
+ };
+ };
+
+ ptm1 at F889D000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0xf889d000 0x1000>;
+ cpu = <0x12>;
+ clocks = <&clkc 47>;
+ clock-names = "apb_pclk";
+
+ port {
+
+ endpoint {
+ remote-endpoint = <0x13>;
+ linux,phandle = <0xc>;
+ phandle = <0xc>;
+ };
+ };
+ };
};
};
^ permalink raw reply
* [PATCH] Adding missing features of Coresight PTM components
From: Muhammad Abdul WAHAB @ 2016-09-29 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In the current driver for Coresight components, two features of PTM
components are missing:
1. Branch Broadcasting (present also in ETM but called Branch Output)
2. Return Stack (only present in PTM v1.0 and PTMv1.1)
These features can be added simply to the code using `mode` field of
`etm_config` struct.
### Modifications in coresight-etm.h
Two defines are added in register definition part of `coresight_etm.h` file
that corresponds to the bitfield of these options. Two defines for mode
field are added as well in the same file. The `ETM_MODE_ALL` field is
modified accordingly.
### Modifs in coresight-etm3x-sysfs.c
As the return stack feature is only available in PTM components, a test is
made to make sure that for ETM components, this part is never executed.
In addition, these two options (Branch Broadcasting and Return Stack) must
not be enabled at the same time because the obtained trace is unpredictable
in this case (as described in
[PFT architecture v1.1](https://goo.gl/lZ72R1)). For now, a warning is
shown to alert user that the behavior is unpredictable. However, only one
option could be allowed to trace. The user need to change configuration
of PTM.
To enable these features, the correct value should be written in `mode`
file. The values are :
1. Branch Broadcasting (1 << 5)
2. Return Stack (1 << 6)
Signed-off-by: Muhammad Abdul Wahab <muhammadabdul.wahab@centralesupelec.fr>
---
#### Purpose
1. **Branch Broadcast** : The branch broadcast feature is present in ETM
components as well and is called Branch output. It allows to retrieve
addresses for direct branch addresses alongside the indirect branch
addresses. For example, it could be useful in cases when tracing without
source code.
2. **Return Stack** : The return stack option allows to retrieve the return
addresses of function calls. It can be useful to avoid CRA
(Code Reuse Attacks) by keeping a shadowstack.
### Testing
The trace sink components need to be enabled by accessing through sys file
system.
echo 1 > /sys/bus/coresight/devices/@addr.etb/enable\_sink
Then enable the CS source component:
echo 1 > /sys/bus/coresight/devices/@addr.ptm/enable\_source
By default, CS Source components are configured to trace the kernel.
Then the trace can be read by dumping ETB.
dd if=/dev/@addr.etb of=trace_kernel.bin
The trace can be visualized by
hexdump -C trace_kernel.bin
Or stored using
hexdump -C trace_kernel.bin > trace_kernel.txt
The trace need to be decoded to be readable.All these above steps can now
be performed with Perf Library which was not available at the time I was
playing with DT entries.
diff -uprN -X linux-4.7-vanilla/Documentation/dontdiff
linux-4.7-vanilla/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
linux-4.7/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
---
linux-4.7-vanilla/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
2016-07-24 21:23:50.000000000 +0200
+++ linux-4.7/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
2016-09-28 15:36:39.886542702 +0200
@@ -145,7 +145,7 @@ static ssize_t mode_store(struct device
goto err_unlock;
}
config->ctrl |= ETMCR_STALL_MODE;
- } else
+ } else
config->ctrl &= ~ETMCR_STALL_MODE;
if (config->mode & ETM_MODE_TIMESTAMP) {
@@ -163,6 +163,20 @@ static ssize_t mode_store(struct device
else
config->ctrl &= ~ETMCR_CTXID_SIZE;
+ if (config->mode & ETM_MODE_BBROAD)
+ config->ctrl |= ETMCR_BRANCH_BROADCAST;
+ else
+ config->ctrl &= ~ETMCR_BRANCH_BROADCAST;
+
+ if (drvdata->arch == (PFT_ARCH_V1_0 | PFT_ARCH_V1_1)) {
+ if (config->mode & ETM_MODE_RET_STACK) {
+ if (config->mode & ETM_MODE_BBROAD)
+ dev_warn(drvdata->dev, "behavior is unpredictable\n");
+ config->ctrl |= ETMCR_RETURN_STACK_EN;
+ } else
+ config->ctrl &= ~ETMCR_RETURN_STACK_EN;
+ }
+
if (config->mode & (ETM_MODE_EXCL_KERN | ETM_MODE_EXCL_USER))
etm_config_trace_mode(config);
diff -uprN -X linux-4.7-vanilla/Documentation/dontdiff
linux-4.7-vanilla/drivers/hwtracing/coresight/coresight-etm.h
linux-4.7/drivers/hwtracing/coresight/coresight-etm.h
--- linux-4.7-vanilla/drivers/hwtracing/coresight/coresight-etm.h
2016-07-24 21:23:50.000000000 +0200
+++ linux-4.7/drivers/hwtracing/coresight/coresight-etm.h 2016-09-28
15:35:59.862544418 +0200
@@ -89,11 +89,13 @@
/* ETMCR - 0x00 */
#define ETMCR_PWD_DWN BIT(0)
#define ETMCR_STALL_MODE BIT(7)
+#define ETMCR_BRANCH_BROADCAST BIT(8)
#define ETMCR_ETM_PRG BIT(10)
#define ETMCR_ETM_EN BIT(11)
#define ETMCR_CYC_ACC BIT(12)
#define ETMCR_CTXID_SIZE (BIT(14)|BIT(15))
#define ETMCR_TIMESTAMP_EN BIT(28)
+#define ETMCR_RETURN_STACK_EN BIT(29) /* PTM v1.0 & PTM v1.1 */
/* ETMCCR - 0x04 */
#define ETMCCR_FIFOFULL BIT(23)
/* ETMPDCR - 0x310 */
@@ -110,8 +112,11 @@
#define ETM_MODE_STALL BIT(2)
#define ETM_MODE_TIMESTAMP BIT(3)
#define ETM_MODE_CTXID BIT(4)
+#define ETM_MODE_BBROAD BIT(5)
+#define ETM_MODE_RET_STACK BIT(6)
#define ETM_MODE_ALL (ETM_MODE_EXCLUDE | ETM_MODE_CYCACC | \
ETM_MODE_STALL | ETM_MODE_TIMESTAMP | \
+ ETM_MODE_BBROAD | ETM_MODE_RET_STACK | \
ETM_MODE_CTXID | ETM_MODE_EXCL_KERN | \
ETM_MODE_EXCL_USER)
^ 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