* [PATCH v7 0/6] provide power off support for iMX6 with external PMIC
From: Oleksij Rempel @ 2018-05-17 5:50 UTC (permalink / raw)
To: linux-arm-kernel
2018.05.17:
update patches to version v7
This patch series is providing power off support for Freescale/NXP iMX6 based
boards with external power management integrated circuit (PMIC).
As a first step the PMIC is configured to turn off the system if the
standby pin is asserted. On second step we assert the standby pin.
For this reason we need to use pm_power_off_prepare.
Usage of stnadby pin for power off is described in official iMX6
documentation.
2018.03.05:
As this patch set touches multiple subsystems I think it would make
sense for Shawn Guo to take the all patch set.
The only part which didn't receive an ACK is regulator stuff. So I would
hope that Mark Brown can ACK it.
Kind regards,
Oleksij Rempel
2017.12.06:
Adding Linus. Probably there is no maintainer for this patch set.
No changes are made, tested on v4.15-rc1.
2017.10.27:
Last version of this patch set was send at 20 Jun 2017, this is a rebase against
kernel v4.14-rc6. Probably this set got lost. If I forgot to address some comments,
please point me.
changes:
v7:
- use EXPORT_SYMBOL_GPL(pm_power_off_prepare) instead of EXPORT_SYMBOL
- call imx6q_suspend_finish() directly without cpu_suspend()
v6:
- rename imx6_pm_poweroff to imx6_pm_stby_poweroff
- fix "MPIC_STBY_REQ" typo in the comment.
v5:
- remove useless includes from pm-imx6.c patch
- add Acked-by to "regulator: pfuze100: add fsl,pmic-stby-poweroff property"
patch
v4:
- update comment in "regulator: pfuze100: add fsl,pmic-stby-poweroff ..."
patch
- add Acked-by to "ARM: imx6q: provide documentation for new ..."
patch
v3:
- set pm_power_off_prepare = NULL on .remove.
- documentation and spelling fixes.
- use %pf instead of lookup_symbol_name.
Oleksij Rempel (6):
ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff
property
ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff"
is set
kernel/reboot.c: export pm_power_off_prepare
regulator: pfuze100: add fsl,pmic-stby-poweroff property
regulator: pfuze100-regulator: provide pm_power_off_prepare handler
ARM: dts: imx6: RIoTboard provide standby on power off option
.../devicetree/bindings/clock/imx6q-clock.txt | 8 ++
.../bindings/regulator/pfuze100.txt | 7 ++
arch/arm/boot/dts/imx6dl-riotboard.dts | 5 +
arch/arm/mach-imx/pm-imx6.c | 25 +++++
drivers/regulator/pfuze100-regulator.c | 92 +++++++++++++++++++
kernel/reboot.c | 1 +
6 files changed, 138 insertions(+)
--
2.17.0
^ permalink raw reply
* [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules
From: Eric W. Biederman @ 2018-05-17 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510194422.GX16141@n2100.armlinux.org.uk>
Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> On Thu, May 10, 2018 at 01:39:18PM -0600, Mathieu Poirier wrote:
>> Hi Russell,
>>
>> On 10 May 2018 at 02:40, Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
>> > This does not leak information from other namespaces because of the
>> > uniqueness of the global PID. However, what it does leak is the value
>> > of the global PID which is meaningless in the namespace. So, before
>> > the event stream is delivered to userspace, this value needs to be
>> > re-written to the namespace's PID value.
>>
>> Unfortunately that can't be done. The trace stream is compressed and
>> needs to be decompressed using an external library. I think the only
>> option is to return an error if a user is trying to use this feature
>> from a namespace.
>
> That sounds like a sensible approach, and that should get rid of the
> vpid stuff too.
>
> Eric, would this solve all your concerns?
It does, and I have given my ack to the respin.
I am moderately concerned about using the global pid with hardware. But
pids are a core abstraction that aren't going anywhere. As long as
hardware does not impose constraints on pids that software already does
not we should be fine.
Eric
^ permalink raw reply
* [PATCH] dmaengine: qcom: bam_dma: check if the runtime pm enabled
From: Vinod @ 2018-05-17 5:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514161852.9620-1-srinivas.kandagatla@linaro.org>
On 14-05-18, 17:18, Srinivas Kandagatla wrote:
> Disabling pm runtime at probe is not sufficient to get BAM working
> on remotely controller instances. pm_runtime_get_sync() would return
> -EACCES in such cases.
> So check if runtime pm is enabled before returning error from bam functions.
>
> Fixes: 5b4a68952a89 ("dmaengine: qcom: bam_dma: disable runtime pm on remote controlled")
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> drivers/dma/qcom/bam_dma.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index d29275b97e84..5f4babebc508 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -540,7 +540,7 @@ static void bam_free_chan(struct dma_chan *chan)
> int ret;
>
> ret = pm_runtime_get_sync(bdev->dev);
> - if (ret < 0)
> + if (pm_runtime_enabled(bdev->dev) && ret < 0)
would it make sense to first check enabled and do _get_sync()
if (pm_runtime_enabled()) {
ret = pm_runtime_get_sync() {
...
}
}
thus making clear in code that we do calls only when it is enabled. Also you can
add a local macro for this code and use that rather than copy pasting :)
--
~Vinod
^ permalink raw reply
* [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Mark Brown @ 2018-05-17 5:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511103822.31698-6-radu.pirea@microchip.com>
On Fri, May 11, 2018 at 01:38:21PM +0300, Radu Pirea wrote:
> +config SPI_AT91_USART
> + tristate "Atmel USART Controller as SPI"
> + depends on HAS_DMA
> + depends on (ARCH_AT91 || COMPILE_TEST)
> + select MFD_AT91_USART
> + help
> + This selects a driver for the AT91 USART Controller as SPI Master,
> + present on AT91 and SAMA5 SoC series.
> +
This looks like there's some tab/space mixing going on here.
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for AT91 USART Controllers as SPI
> + *
> + * Copyright (C) 2018 Microchip Technology Inc.
Make the entire block a C++ comment so it looks more intentional rather
tha mixing C and C++.
> +static inline void at91_usart_spi_tx(struct at91_usart_spi *aus)
> +{
> + unsigned int len = aus->current_transfer->len;
> + unsigned int remaining = aus->current_tx_remaining_bytes;
> + const u8 *tx_buf = aus->current_transfer->tx_buf;
> +
> + if (tx_buf && remaining) {
> + if (at91_usart_spi_tx_ready(aus))
> + spi_writel(aus, THR, tx_buf[len - remaining]);
> + aus->current_tx_remaining_bytes--;
Missing braces here - we only write to the FIFO if there's space but we
unconditionally decrement the counter.
> + } else {
> + if (at91_usart_spi_tx_ready(aus))
> + spi_writel(aus, THR, US_DUMMY_TX);
> + }
> +}
This looks like you're open coding SPI_CONTROLLER_MUST_TX
> + int len = aus->current_transfer->len;
> + int remaining = aus->current_rx_remaining_bytes;
> + u8 *rx_buf = aus->current_transfer->rx_buf;
> +
> + if (aus->current_rx_remaining_bytes) {
> + rx_buf[len - remaining] = spi_readb(aus, RHR);
> + aus->current_rx_remaining_bytes--;
> + } else {
> + spi_readb(aus, RHR);
> + }
Similarly for _MUST_RX.
> + controller->flags = SPI_MASTER_MUST_RX | SPI_MASTER_MUST_TX;
You're actually setting both flags... this means that the handling for
cases with missing TX or RX buffers can't happen.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/75f75572/attachment-0001.sig>
^ permalink raw reply
* [PATCH] clk: imx6sl: correct ocram_podf clock type
From: Anson Huang @ 2018-05-17 5:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526533248-21990-1-git-send-email-Anson.Huang@nxp.com>
IMX6SL_CLK_OCRAM_PODF is a busy divider, its name in
CCM_CDHIPR register of Reference Manual CCM chapter
is axi_podf_busy, correct its clock type.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/clk/imx/clk-imx6sl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx6sl.c b/drivers/clk/imx/clk-imx6sl.c
index 9642cdf..66b1dd1 100644
--- a/drivers/clk/imx/clk-imx6sl.c
+++ b/drivers/clk/imx/clk-imx6sl.c
@@ -330,7 +330,7 @@ static void __init imx6sl_clocks_init(struct device_node *ccm_node)
clks[IMX6SL_CLK_PERIPH2] = imx_clk_busy_mux("periph2", base + 0x14, 26, 1, base + 0x48, 3, periph2_sels, ARRAY_SIZE(periph2_sels));
/* name parent_name reg shift width */
- clks[IMX6SL_CLK_OCRAM_PODF] = imx_clk_divider("ocram_podf", "ocram_sel", base + 0x14, 16, 3);
+ clks[IMX6SL_CLK_OCRAM_PODF] = imx_clk_busy_divider("ocram_podf", "ocram_sel", base + 0x14, 16, 3, base + 0x48, 0);
clks[IMX6SL_CLK_PERIPH_CLK2_PODF] = imx_clk_divider("periph_clk2_podf", "periph_clk2_sel", base + 0x14, 27, 3);
clks[IMX6SL_CLK_PERIPH2_CLK2_PODF] = imx_clk_divider("periph2_clk2_podf", "periph2_clk2_sel", base + 0x14, 0, 3);
clks[IMX6SL_CLK_IPG] = imx_clk_divider("ipg", "ahb", base + 0x14, 8, 2);
--
2.7.4
^ permalink raw reply related
* [PATCH] clk: imx6sx: disable unnecessary clocks during clock initialization
From: Anson Huang @ 2018-05-17 5:00 UTC (permalink / raw)
To: linux-arm-kernel
Disable those unnecessary clocks during kernel boot up to save power,
those modules clock should be managed by modules driver in runtime.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/clk/imx/clk-imx6sx.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
index 0178ee2..10c771b 100644
--- a/drivers/clk/imx/clk-imx6sx.c
+++ b/drivers/clk/imx/clk-imx6sx.c
@@ -97,12 +97,7 @@ static int const clks_init_on[] __initconst = {
IMX6SX_CLK_IPMUX1, IMX6SX_CLK_IPMUX2, IMX6SX_CLK_IPMUX3,
IMX6SX_CLK_WAKEUP, IMX6SX_CLK_MMDC_P0_FAST, IMX6SX_CLK_MMDC_P0_IPG,
IMX6SX_CLK_ROM, IMX6SX_CLK_ARM, IMX6SX_CLK_IPG, IMX6SX_CLK_OCRAM,
- IMX6SX_CLK_PER2_MAIN, IMX6SX_CLK_PERCLK, IMX6SX_CLK_M4,
- IMX6SX_CLK_QSPI1, IMX6SX_CLK_QSPI2, IMX6SX_CLK_UART_IPG,
- IMX6SX_CLK_UART_SERIAL, IMX6SX_CLK_I2C3, IMX6SX_CLK_ECSPI5,
- IMX6SX_CLK_CAN1_IPG, IMX6SX_CLK_CAN1_SERIAL, IMX6SX_CLK_CAN2_IPG,
- IMX6SX_CLK_CAN2_SERIAL, IMX6SX_CLK_CANFD, IMX6SX_CLK_EPIT1,
- IMX6SX_CLK_EPIT2,
+ IMX6SX_CLK_PER2_MAIN, IMX6SX_CLK_PERCLK, IMX6SX_CLK_TZASC1,
};
static const struct clk_div_table clk_enet_ref_table[] = {
--
2.7.4
^ permalink raw reply related
* [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Mark Brown @ 2018-05-17 4:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c23cdde58b9f724f51787c6c38478df983be6efa.camel@microchip.com>
On Tue, May 15, 2018 at 12:22:24PM +0300, Radu Pirea wrote:
> On Mon, 2018-05-14 at 20:38 +0300, Andy Shevchenko wrote:
> > So, what is not going as expected in "SPI core takes care of CSs"
> > case?
> > Did you use oscilloscope for that?
> Yes, I used and CSs was not asserted. Anyway, I will will try again.
If the core chip select handling is not working properly for some reason
then the core chip select handling should be fixed rather than just open
coding in your driver - probably it's also broken for other users.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/795c8270/attachment-0001.sig>
^ permalink raw reply
* [GIT PULL] ARM: mediatek: soc driver updates for v4.18
From: Mark Brown @ 2018-05-17 4:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bd033549-4998-e376-eb92-16111ec71a07@gmail.com>
On Mon, May 14, 2018 at 01:32:49PM +0200, Matthias Brugger wrote:
> ----------------------------------------------------------------
> Matthias Brugger (1):
> Merge commit 'f15cd6d99198e9c15229aefec639a34a6e8174c6' into
> v.4.17-next/soc-test
There is a signed tag for this - please don't ever pull anything from me
without a signed tag, while I try to avoid rewriting history it does
sometimes happen but if I've made a signed tag part of that is me saying
I know other people might've merged the commit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/8f7bd0fc/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2] pinctrl: pinctrl-single: Add functions to save and restore pinctrl context
From: Keerthy @ 2018-05-17 4:40 UTC (permalink / raw)
To: linux-arm-kernel
This adds a pair of context save/restore functions to save/restore the
state of a set of pinctrl registers. The context is lost during rtc only
suspend with ddr in self-refresh on am43xx. Currently the save/restore
is being done unconditionally. This will be optimized later with a
pdata-quirk function which will allow is to save/restore only when doing
the rtc only mode with ddr in self refresh.
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
Changes in v2:
* As this is needed only the in the suspend/resume path
removed the cpu_pm notifier and added the save/restore in
the suspend/resume calls.
* Saving/Restoring unconditionally at the moment. This will
be optimized later with the help of a pdata-quirk function.
drivers/pinctrl/pinctrl-single.c | 72 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index a7c5eb3..9c3c005 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -144,6 +144,7 @@ struct pcs_soc_data {
* struct pcs_device - pinctrl device instance
* @res: resources
* @base: virtual address of the controller
+ * @saved_vals: saved values for the controller
* @size: size of the ioremapped area
* @dev: device entry
* @np: device tree node
@@ -172,11 +173,13 @@ struct pcs_soc_data {
struct pcs_device {
struct resource *res;
void __iomem *base;
+ void *saved_vals;
unsigned size;
struct device *dev;
struct device_node *np;
struct pinctrl_dev *pctl;
unsigned flags;
+#define PCS_CONTEXT_LOSS_OFF (1 << 3)
#define PCS_QUIRK_SHARED_IRQ (1 << 2)
#define PCS_FEAT_IRQ (1 << 1)
#define PCS_FEAT_PINCONF (1 << 0)
@@ -1576,6 +1579,67 @@ static int pcs_irq_init_chained_handler(struct pcs_device *pcs,
}
#ifdef CONFIG_PM
+static int pcs_save_context(struct pcs_device *pcs)
+{
+ int i, mux_bytes;
+ u64 *regsl;
+ u32 *regsw;
+ u16 *regshw;
+
+ mux_bytes = pcs->width / BITS_PER_BYTE;
+
+ if (!pcs->saved_vals)
+ pcs->saved_vals = devm_kzalloc(pcs->dev, pcs->size, GFP_ATOMIC);
+
+ switch (pcs->width) {
+ case 64:
+ regsl = (u64 *)pcs->saved_vals;
+ for (i = 0; i < pcs->size / mux_bytes; i++)
+ regsl[i] = pcs->read(pcs->base + i * mux_bytes);
+ break;
+ case 32:
+ regsw = (u32 *)pcs->saved_vals;
+ for (i = 0; i < pcs->size / mux_bytes; i++)
+ regsw[i] = pcs->read(pcs->base + i * mux_bytes);
+ break;
+ case 16:
+ regshw = (u16 *)pcs->saved_vals;
+ for (i = 0; i < pcs->size / mux_bytes; i++)
+ regshw[i] = pcs->read(pcs->base + i * mux_bytes);
+ break;
+ }
+
+ return 0;
+}
+
+static void pcs_restore_context(struct pcs_device *pcs)
+{
+ int i, mux_bytes;
+ u64 *regsl;
+ u32 *regsw;
+ u16 *regshw;
+
+ mux_bytes = pcs->width / BITS_PER_BYTE;
+
+ switch (pcs->width) {
+ case 64:
+ regsl = (u64 *)pcs->saved_vals;
+ for (i = 0; i < pcs->size / mux_bytes; i++)
+ pcs->write(regsl[i], pcs->base + i * mux_bytes);
+ break;
+ case 32:
+ regsw = (u32 *)pcs->saved_vals;
+ for (i = 0; i < pcs->size / mux_bytes; i++)
+ pcs->write(regsw[i], pcs->base + i * mux_bytes);
+ break;
+ case 16:
+ regshw = (u16 *)pcs->saved_vals;
+ for (i = 0; i < pcs->size / mux_bytes; i++)
+ pcs->write(regshw[i], pcs->base + i * mux_bytes);
+ break;
+ }
+}
+
static int pinctrl_single_suspend(struct platform_device *pdev,
pm_message_t state)
{
@@ -1585,6 +1649,9 @@ static int pinctrl_single_suspend(struct platform_device *pdev,
if (!pcs)
return -EINVAL;
+ if (pcs->flags & PCS_CONTEXT_LOSS_OFF)
+ pcs_save_context(pcs);
+
return pinctrl_force_sleep(pcs->pctl);
}
@@ -1596,6 +1663,9 @@ static int pinctrl_single_resume(struct platform_device *pdev)
if (!pcs)
return -EINVAL;
+ if (pcs->flags & PCS_CONTEXT_LOSS_OFF)
+ pcs_restore_context(pcs);
+
return pinctrl_force_default(pcs->pctl);
}
#endif
@@ -1824,7 +1894,7 @@ static int pcs_remove(struct platform_device *pdev)
};
static const struct pcs_soc_data pinctrl_single_am437x = {
- .flags = PCS_QUIRK_SHARED_IRQ,
+ .flags = PCS_QUIRK_SHARED_IRQ | PCS_CONTEXT_LOSS_OFF,
.irq_enable_mask = (1 << 29), /* OMAP_WAKEUP_EN */
.irq_status_mask = (1 << 30), /* OMAP_WAKEUP_EVENT */
};
--
1.9.1
^ permalink raw reply related
* [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order
From: Viresh Kumar @ 2018-05-17 4:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <71309e94-90d4-2b58-729b-9ab488c6d554@gmail.com>
On 16-05-18, 12:24, Florian Fainelli wrote:
> On 05/15/2018 09:32 PM, Viresh Kumar wrote:
> > On 15-05-18, 20:49, Markus Mayer wrote:
> >> From: Markus Mayer <mmayer@broadcom.com>
> >>
> >> Most CPUfreq drivers (at least on ARM) seem to be sorting the available
> >> frequencies from lowest to highest. To match this behaviour, we reverse
> >> the sorting order in brcmstb-avs-cpufreq, so it is now also lowest to
> >> highest.
> >
> > The reasoning isn't correct. Just because everyone else is doing it
> > doesn't make it right and so you shouldn't change just because of
> > that.
> >
> > What you must written instead in the commit log is that the cpufreq
> > core performs better if the table is sorted (in any order), and so we
> > must sort it as well.
>
> Is there a reason why set_freq_table_sorted() tries an ascending or
> descending sort, but does not enforce one versus another for all drivers?
set_freq_table_sorted() doesn't sort the frequency table but checks if
the table is already sorted in a particular order. And then
cpufreq_frequency_table_target() is optimized based on this flag. We
don't have to enforce any particular ordering here.
> > But I feel the table is already sorted for your platform, isn't it?
> > And I don't see a clear advantage of merging this patch.
>
> The patch changes the order to have the lowest to highest, whereas the
> current implementation has them from highest to lowest. From what you
> are saying, it sounds like this is unnecessary, since the sorting is
> already making things efficient enough, so this is just a cosmetic thing?
Right. It shouldn't make any performance improvements.
--
viresh
^ permalink raw reply
* [PATCH v3 08/14] media: v4l: Add definitions for MPEG2 frame format and header metadata
From: kbuild test robot @ 2018-05-17 4:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507124500.20434-9-paul.kocialkowski@bootlin.com>
Hi Florent,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.17-rc5 next-20180516]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Paul-Kocialkowski/Sunxi-Cedrus-driver-for-the-Allwinner-Video-Engine-using-media-requests/20180508-004955
base: git://linuxtv.org/media_tree.git master
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
>> ./usr/include/linux/v4l2-controls.h:1082: found __[us]{8,16,32,64} type without #include <linux/types.h>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 30376 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/fa20e902/attachment-0001.gz>
^ permalink raw reply
* [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list
From: Baoquan He @ 2018-05-17 2:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517021024.GI24627@MiWiFi-R3L-srv>
On 05/17/18 at 10:10am, Baoquan He wrote:
> On 05/07/18 at 02:59pm, AKASHI Takahiro wrote:
> > James,
> >
> > On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
> > > Hi Akashi,
> > >
> > > On 25/04/18 07:26, AKASHI Takahiro wrote:
> > > > We need to prevent firmware-reserved memory regions, particularly EFI
> > > > memory map as well as ACPI tables, from being corrupted by loading
> > > > kernel/initrd (or other kexec buffers). We also want to support memory
> > > > allocation in top-down manner in addition to default bottom-up.
> > > > So let's have arm64 specific arch_kexec_walk_mem() which will search
> > > > for available memory ranges in usable memblock list,
> > > > i.e. !NOMAP & !reserved,
> > >
> > > > instead of system resource tree.
> > >
> > > Didn't we try to fix the system-resource-tree in order to fix regular-kexec to
> > > be safe in the EFI-memory-map/ACPI-tables case?
> > >
> > > It would be good to avoid having two ways of doing this, and I would like to
> > > avoid having extra arch code...
> >
> > I know what you mean.
> > /proc/iomem or system resource is, in my opinion, not the best place to
> > describe memory usage of kernel but rather to describe *physical* hardware
> > layout. As we are still discussing about "reserved" memory, I don't want
> > to depend on it.
> > Along with memblock list, we will have more accurate control over memory
> > usage.
>
> In kexec-tools, we see any usable memory as candidate which can be used
Here I said 'any', it's not accurate. Those memory which need be passed
to 2nd kernel for use need be excluded, just as we have done in
kexec-tools.
> to load kexec kernel image/initrd etc. However kexec loading is a
> preparation work, it just books those position for later kexec kernel
> jumping after "kexec -e", that is why we need kexec_buf to remember
> them and do the real content copy of kernel/initrd. Here you use
> memblock to search available memory, isn't it deviating too far away
> from the original design in kexec-tools. Assume kexec loading and
> kexec_file loading should be consistent on loading even though they are
> done in different space, kernel space and user space.
>
> I didn't follow the earlier post, may miss something.
>
> Thanks
> Baoquan
>
> >
> > >
> > > > diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> > > > new file mode 100644
> > > > index 000000000000..f9ebf54ca247
> > > > --- /dev/null
> > > > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > > > @@ -0,0 +1,57 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * kexec_file for arm64
> > > > + *
> > > > + * Copyright (C) 2018 Linaro Limited
> > > > + * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > + *
> > >
> > > > + * Most code is derived from arm64 port of kexec-tools
> > >
> > > How does kexec-tools walk memblock?
> >
> > Will remove this comment from this patch.
> > Obviously, this comment is for the rest of the code which will be
> > added to succeeding patches (patch #5 and #7).
> >
> >
> > >
> > > > + */
> > > > +
> > > > +#define pr_fmt(fmt) "kexec_file: " fmt
> > > > +
> > > > +#include <linux/ioport.h>
> > > > +#include <linux/kernel.h>
> > > > +#include <linux/kexec.h>
> > > > +#include <linux/memblock.h>
> > > > +
> > > > +int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > > > + int (*func)(struct resource *, void *))
> > > > +{
> > > > + phys_addr_t start, end;
> > > > + struct resource res;
> > > > + u64 i;
> > > > + int ret = 0;
> > > > +
> > > > + if (kbuf->image->type == KEXEC_TYPE_CRASH)
> > > > + return func(&crashk_res, kbuf);
> > > > +
> > > > + if (kbuf->top_down)
> > > > + for_each_mem_range_rev(i, &memblock.memory, &memblock.reserved,
> > > > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > > > + &start, &end, NULL) {
> > >
> > > for_each_free_mem_range_reverse() is a more readable version of this helper.
> >
> > OK. I used to use my own limited list of reserved memory instead of
> > memblock.reserved here to exclude verbose ranges.
> >
> >
> > > > + if (!memblock_is_map_memory(start))
> > > > + continue;
> > >
> > > Passing MEMBLOCK_NONE means this walk will never find MEMBLOCK_NOMAP memory.
> >
> > Sure, I confirmed it.
> >
> > >
> > > > + res.start = start;
> > > > + res.end = end;
> > > > + ret = func(&res, kbuf);
> > > > + if (ret)
> > > > + break;
> > > > + }
> > > > + else
> > > > + for_each_mem_range(i, &memblock.memory, &memblock.reserved,
> > > > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > > > + &start, &end, NULL) {
> > >
> > > for_each_free_mem_range()?
> >
> > OK.
> >
> > > > + if (!memblock_is_map_memory(start))
> > > > + continue;
> > > > +
> > > > + res.start = start;
> > > > + res.end = end;
> > > > + ret = func(&res, kbuf);
> > > > + if (ret)
> > > > + break;
> > > > + }
> > > > +
> > > > + return ret;
> > > > +}
> > > >
> > >
> > > With these changes, what we have is almost:
> > > arch/powerpc/kernel/machine_kexec_file_64.c::arch_kexec_walk_mem() !
> > > (the difference being powerpc doesn't yet support crash-kernels here)
> > >
> > > If the argument is walking memblock gives a better answer than the stringy
> > > walk_system_ram_res() thing, is there any mileage in moving this code into
> > > kexec_file.c, and using it if !IS_ENABLED(CONFIG_ARCH_DISCARD_MEMBLOCK)?
> > >
> > > This would save arm64/powerpc having near-identical implementations.
> > > 32bit arm keeps memblock if it has kexec, so it may be useful there too if
> > > kexec_file_load() support is added.
> >
> > Thanks. I've forgot ppc.
> >
> > -Takahiro AKASHI
> >
> >
> > >
> > > Thanks,
> > >
> > > James
> >
> > _______________________________________________
> > kexec mailing list
> > kexec at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list
From: Baoquan He @ 2018-05-17 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507055906.GE11326@linaro.org>
On 05/07/18 at 02:59pm, AKASHI Takahiro wrote:
> James,
>
> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
> > Hi Akashi,
> >
> > On 25/04/18 07:26, AKASHI Takahiro wrote:
> > > We need to prevent firmware-reserved memory regions, particularly EFI
> > > memory map as well as ACPI tables, from being corrupted by loading
> > > kernel/initrd (or other kexec buffers). We also want to support memory
> > > allocation in top-down manner in addition to default bottom-up.
> > > So let's have arm64 specific arch_kexec_walk_mem() which will search
> > > for available memory ranges in usable memblock list,
> > > i.e. !NOMAP & !reserved,
> >
> > > instead of system resource tree.
> >
> > Didn't we try to fix the system-resource-tree in order to fix regular-kexec to
> > be safe in the EFI-memory-map/ACPI-tables case?
> >
> > It would be good to avoid having two ways of doing this, and I would like to
> > avoid having extra arch code...
>
> I know what you mean.
> /proc/iomem or system resource is, in my opinion, not the best place to
> describe memory usage of kernel but rather to describe *physical* hardware
> layout. As we are still discussing about "reserved" memory, I don't want
> to depend on it.
> Along with memblock list, we will have more accurate control over memory
> usage.
In kexec-tools, we see any usable memory as candidate which can be used
to load kexec kernel image/initrd etc. However kexec loading is a
preparation work, it just books those position for later kexec kernel
jumping after "kexec -e", that is why we need kexec_buf to remember
them and do the real content copy of kernel/initrd. Here you use
memblock to search available memory, isn't it deviating too far away
from the original design in kexec-tools. Assume kexec loading and
kexec_file loading should be consistent on loading even though they are
done in different space, kernel space and user space.
I didn't follow the earlier post, may miss something.
Thanks
Baoquan
>
> >
> > > diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> > > new file mode 100644
> > > index 000000000000..f9ebf54ca247
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > > @@ -0,0 +1,57 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * kexec_file for arm64
> > > + *
> > > + * Copyright (C) 2018 Linaro Limited
> > > + * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > + *
> >
> > > + * Most code is derived from arm64 port of kexec-tools
> >
> > How does kexec-tools walk memblock?
>
> Will remove this comment from this patch.
> Obviously, this comment is for the rest of the code which will be
> added to succeeding patches (patch #5 and #7).
>
>
> >
> > > + */
> > > +
> > > +#define pr_fmt(fmt) "kexec_file: " fmt
> > > +
> > > +#include <linux/ioport.h>
> > > +#include <linux/kernel.h>
> > > +#include <linux/kexec.h>
> > > +#include <linux/memblock.h>
> > > +
> > > +int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > > + int (*func)(struct resource *, void *))
> > > +{
> > > + phys_addr_t start, end;
> > > + struct resource res;
> > > + u64 i;
> > > + int ret = 0;
> > > +
> > > + if (kbuf->image->type == KEXEC_TYPE_CRASH)
> > > + return func(&crashk_res, kbuf);
> > > +
> > > + if (kbuf->top_down)
> > > + for_each_mem_range_rev(i, &memblock.memory, &memblock.reserved,
> > > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > > + &start, &end, NULL) {
> >
> > for_each_free_mem_range_reverse() is a more readable version of this helper.
>
> OK. I used to use my own limited list of reserved memory instead of
> memblock.reserved here to exclude verbose ranges.
>
>
> > > + if (!memblock_is_map_memory(start))
> > > + continue;
> >
> > Passing MEMBLOCK_NONE means this walk will never find MEMBLOCK_NOMAP memory.
>
> Sure, I confirmed it.
>
> >
> > > + res.start = start;
> > > + res.end = end;
> > > + ret = func(&res, kbuf);
> > > + if (ret)
> > > + break;
> > > + }
> > > + else
> > > + for_each_mem_range(i, &memblock.memory, &memblock.reserved,
> > > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > > + &start, &end, NULL) {
> >
> > for_each_free_mem_range()?
>
> OK.
>
> > > + if (!memblock_is_map_memory(start))
> > > + continue;
> > > +
> > > + res.start = start;
> > > + res.end = end;
> > > + ret = func(&res, kbuf);
> > > + if (ret)
> > > + break;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > >
> >
> > With these changes, what we have is almost:
> > arch/powerpc/kernel/machine_kexec_file_64.c::arch_kexec_walk_mem() !
> > (the difference being powerpc doesn't yet support crash-kernels here)
> >
> > If the argument is walking memblock gives a better answer than the stringy
> > walk_system_ram_res() thing, is there any mileage in moving this code into
> > kexec_file.c, and using it if !IS_ENABLED(CONFIG_ARCH_DISCARD_MEMBLOCK)?
> >
> > This would save arm64/powerpc having near-identical implementations.
> > 32bit arm keeps memblock if it has kexec, so it may be useful there too if
> > kexec_file_load() support is added.
>
> Thanks. I've forgot ppc.
>
> -Takahiro AKASHI
>
>
> >
> > Thanks,
> >
> > James
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH 0/3] coresight: Don't use contextID with PID namespaces
From: Eric W. Biederman @ 2018-05-17 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526404417-32507-1-git-send-email-mathieu.poirier@linaro.org>
Mathieu Poirier <mathieu.poirier@linaro.org> writes:
> Since the in-kernel value of a PID differs from what is seen from
> PID namespaces, using contextID tracing with PID namespaces makes the
> feature confusing to use and potentially subject to leaking out internal
> kernel information.
>
> This set returns an error if contextID and PID namespaces are used in
> conjunction and gets rid of the vpid-to-pid translation function as it
> is no longer needed.
I looked the file can only be written by root. So limiting things to
the initial pid namespace seems like the right solutions. Especially as
the trace stream will include the global pid and be available to the
tracer.
This sounds like a simple code with a minimal chance of breaking
userspace.
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
^ permalink raw reply
* [PATCH v2] media: helene: add I2C device probe function
From: Katsuhiro Suzuki @ 2018-05-17 1:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK3bHNVH1476vtJOTR0oFpFC8bvwLecYmgJEQCGp0Y+E4=LSsA@mail.gmail.com>
Hello Abylay,
> -----Original Message-----
> From: Abylay Ospan <aospan@netup.ru>
> Sent: Wednesday, May 16, 2018 7:54 PM
> To: Suzuki, Katsuhiro/?? ?? <suzuki.katsuhiro@socionext.com>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>; linux-media
> <linux-media@vger.kernel.org>; Masami Hiramatsu <masami.hiramatsu@linaro.org>;
> Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH v2] media: helene: add I2C device probe function
>
> Hi Katsuhiro,
>
> Thanks for patch.
>
> What is the purpose to rework helene_set_params(_t|_s) ?
> other part of this patch looks ok for me, but not tested due to lack of spare time ;(
>
I'm using Socionext SC1501A (or MN88443x) ISDB-S/ISDB-T demodulator with this
tuner. This demodulator has 1 port, and can use ISDB-S or ISDB-T exclusively.
So I think I cannot use ISDB-S features of this tuner if I use helene_attach(),
and I cannot use ISDB-T if I use helene_attach_s() too.
Regards,
--
Katsuhiro Suzuki
>
> 2018-05-16 4:37 GMT-04:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com
> <mailto:suzuki.katsuhiro@socionext.com> >:
>
>
> This patch adds I2C probe function to use dvb_module_probe()
> with this driver.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com
> <mailto:suzuki.katsuhiro@socionext.com> >
>
> ---
>
> Changes since v1:
> - Add documents for dvb_frontend member of helene_config
> ---
> drivers/media/dvb-frontends/helene.c | 88 ++++++++++++++++++++++++++--
> drivers/media/dvb-frontends/helene.h | 3 +
> 2 files changed, 87 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/helene.c
> b/drivers/media/dvb-frontends/helene.c
> index a0d0b53c91d7..04033f0c278b 100644
> --- a/drivers/media/dvb-frontends/helene.c
> +++ b/drivers/media/dvb-frontends/helene.c
> @@ -666,7 +666,7 @@ static int helene_set_params_s(struct dvb_frontend *fe)
> return 0;
> }
>
> -static int helene_set_params(struct dvb_frontend *fe)
> +static int helene_set_params_t(struct dvb_frontend *fe)
> {
> u8 data[MAX_WRITE_REGSIZE];
> u32 frequency;
> @@ -835,6 +835,19 @@ static int helene_set_params(struct dvb_frontend *fe)
> return 0;
> }
>
> +static int helene_set_params(struct dvb_frontend *fe)
> +{
> + struct dtv_frontend_properties *p = &fe->dtv_property_cache;
> +
> + if (p->delivery_system == SYS_DVBT ||
> + p->delivery_system == SYS_DVBT2 ||
> + p->delivery_system == SYS_ISDBT ||
> + p->delivery_system == SYS_DVBC_ANNEX_A)
> + return helene_set_params_t(fe);
> +
> + return helene_set_params_s(fe);
> +}
> +
> static int helene_get_frequency(struct dvb_frontend *fe, u32 *frequency)
> {
> struct helene_priv *priv = fe->tuner_priv;
> @@ -843,7 +856,7 @@ static int helene_get_frequency(struct dvb_frontend *fe,
> u32 *frequency)
> return 0;
> }
>
> -static const struct dvb_tuner_ops helene_tuner_ops = {
> +static const struct dvb_tuner_ops helene_tuner_ops_t = {
> .info = {
> .name = "Sony HELENE Ter tuner",
> .frequency_min = 1000000,
> @@ -853,7 +866,7 @@ static const struct dvb_tuner_ops helene_tuner_ops = {
> .init = helene_init,
> .release = helene_release,
> .sleep = helene_sleep,
> - .set_params = helene_set_params,
> + .set_params = helene_set_params_t,
> .get_frequency = helene_get_frequency,
> };
>
> @@ -871,6 +884,20 @@ static const struct dvb_tuner_ops helene_tuner_ops_s
> = {
> .get_frequency = helene_get_frequency,
> };
>
> +static const struct dvb_tuner_ops helene_tuner_ops = {
> + .info = {
> + .name = "Sony HELENE Sat/Ter tuner",
> + .frequency_min = 500000,
> + .frequency_max = 1200000000,
> + .frequency_step = 1000,
> + },
> + .init = helene_init,
> + .release = helene_release,
> + .sleep = helene_sleep,
> + .set_params = helene_set_params,
> + .get_frequency = helene_get_frequency,
> +};
> +
> /* power-on tuner
> * call once after reset
> */
> @@ -1032,7 +1059,7 @@ struct dvb_frontend *helene_attach(struct
> dvb_frontend *fe,
> if (fe->ops.i2c_gate_ctrl)
> fe->ops.i2c_gate_ctrl(fe, 0);
>
> - memcpy(&fe->ops.tuner_ops, &helene_tuner_ops,
> + memcpy(&fe->ops.tuner_ops, &helene_tuner_ops_t,
> sizeof(struct dvb_tuner_ops));
> fe->tuner_priv = priv;
> dev_info(&priv->i2c->dev,
> @@ -1042,6 +1069,59 @@ struct dvb_frontend *helene_attach(struct
> dvb_frontend *fe,
> }
> EXPORT_SYMBOL(helene_attach);
>
> +static int helene_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct helene_config *config = client->dev.platform_data;
> + struct dvb_frontend *fe = config->fe;
> + struct device *dev = &client->dev;
> + struct helene_priv *priv;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->i2c_address = client->addr;
> + priv->i2c = client->adapter;
> + priv->set_tuner_data = config->set_tuner_priv;
> + priv->set_tuner = config->set_tuner_callback;
> + priv->xtal = config->xtal;
> +
> + if (fe->ops.i2c_gate_ctrl)
> + fe->ops.i2c_gate_ctrl(fe, 1);
> +
> + if (helene_x_pon(priv) != 0)
> + return -EINVAL;
> +
> + if (fe->ops.i2c_gate_ctrl)
> + fe->ops.i2c_gate_ctrl(fe, 0);
> +
> + memcpy(&fe->ops.tuner_ops, &helene_tuner_ops,
> + sizeof(struct dvb_tuner_ops));
> + fe->tuner_priv = priv;
> + i2c_set_clientdata(client, priv);
> +
> + dev_info(dev, "Sony HELENE attached on addr=%x at I2C adapter %p\n",
> + priv->i2c_address, priv->i2c);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id helene_id[] = {
> + { "helene", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, helene_id);
> +
> +static struct i2c_driver helene_driver = {
> + .driver = {
> + .name = "helene",
> + },
> + .probe = helene_probe,
> + .id_table = helene_id,
> +};
> +module_i2c_driver(helene_driver);
> +
> MODULE_DESCRIPTION("Sony HELENE Sat/Ter tuner driver");
> MODULE_AUTHOR("Abylay Ospan <aospan at netup.ru <mailto:aospan@netup.ru>
> >");
> MODULE_LICENSE("GPL");
> diff --git a/drivers/media/dvb-frontends/helene.h
> b/drivers/media/dvb-frontends/helene.h
> index c9fc81c7e4e7..8562d01bc93e 100644
> --- a/drivers/media/dvb-frontends/helene.h
> +++ b/drivers/media/dvb-frontends/helene.h
> @@ -39,6 +39,7 @@ enum helene_xtal {
> * @set_tuner_callback: Callback function that notifies the parent
> driver
> * which tuner is active now
> * @xtal: Cristal frequency as described by &enum helene_xtal
> + * @fe: Frontend for which connects this tuner
> */
> struct helene_config {
> u8 i2c_address;
> @@ -46,6 +47,8 @@ struct helene_config {
> void *set_tuner_priv;
> int (*set_tuner_callback)(void *, int);
> enum helene_xtal xtal;
> +
> + struct dvb_frontend *fe;
> };
>
> #if IS_REACHABLE(CONFIG_DVB_HELENE)
> --
> 2.17.0
>
>
>
>
>
>
> --
>
> Abylay Ospan,
> NetUP Inc.
> http://www.netup.tv <http://www.netup.tv/>
^ permalink raw reply
* [PATCH] media: helene: fix tuning frequency of satellite
From: Katsuhiro Suzuki @ 2018-05-17 0:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK3bHNUVqd2GODY3k4fzWwtZkZZKMH5Qxs+oiWCODcU9gdYK0A@mail.gmail.com>
Hello Abylay,
> -----Original Message-----
> From: Abylay Ospan <aospan@netup.ru>
> Sent: Wednesday, May 16, 2018 7:56 PM
> To: Suzuki, Katsuhiro/?? ?? <suzuki.katsuhiro@socionext.com>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>; linux-media
> <linux-media@vger.kernel.org>; Masami Hiramatsu <masami.hiramatsu@linaro.org>;
> Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH] media: helene: fix tuning frequency of satellite
>
> True.
> I'm curious but how did it worked before ...
> Which hardware (dvb adapter) are you using ?
>
I'm using evaluation boards of my company. So it's not exist in market...
Tuner module is SONY SUT-PJ series for ISDB-S/ISDB-T (not for DVB).
Regards,
--
Katsuhiro Suzuki
> 2018-05-16 4:41 GMT-04:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com
> <mailto:suzuki.katsuhiro@socionext.com> >:
>
>
> This patch fixes tuning frequency of satellite to kHz. That as same
> as terrestrial one.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com
> <mailto:suzuki.katsuhiro@socionext.com> >
> ---
> drivers/media/dvb-frontends/helene.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-frontends/helene.c
> b/drivers/media/dvb-frontends/helene.c
> index 04033f0c278b..0a4f312c4368 100644
> --- a/drivers/media/dvb-frontends/helene.c
> +++ b/drivers/media/dvb-frontends/helene.c
> @@ -523,7 +523,7 @@ static int helene_set_params_s(struct dvb_frontend *fe)
> enum helene_tv_system_t tv_system;
> struct dtv_frontend_properties *p = &fe->dtv_property_cache;
> struct helene_priv *priv = fe->tuner_priv;
> - int frequencykHz = p->frequency;
> + int frequencykHz = p->frequency / 1000;
> uint32_t frequency4kHz = 0;
> u32 symbol_rate = p->symbol_rate/1000;
>
> --
> 2.17.0
>
>
>
>
>
>
> --
>
> Abylay Ospan,
> NetUP Inc.
> http://www.netup.tv <http://www.netup.tv/>
^ permalink raw reply
* 答复: 答复: [PATCH v9 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs
From: liwei (CM) @ 2018-05-17 0:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLf_r=NHHP2ZNEJOoLORXztF1KnU+tq-+COt4CPMLAsiA@mail.gmail.com>
Hi, Rob
-----????-----
???: Rob Herring [mailto:robh at kernel.org]
????: 2018?5?16? 21:16
???: liwei (CM)
??: mark.rutland at arm.com; catalin.marinas at arm.com; will.deacon at arm.com; vinholikatti at gmail.com; jejb at linux.vnet.ibm.com; martin.petersen at oracle.com; khilman at baylibre.com; arnd at arndb.de; gregory.clement at free-electrons.com; thomas.petazzoni at free-electrons.com; yamada.masahiro at socionext.com; riku.voipio at linaro.org; treding at nvidia.com; krzk at kernel.org; devicetree at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-scsi at vger.kernel.org; zangleigang; Gengjianfeng; guodong.xu at linaro.org
??: Re: ??: [PATCH v9 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs
On Tue, Apr 24, 2018 at 8:54 AM, liwei (CM) <liwei213@huawei.com> wrote:
> Hi, Rob
>
> Thanks for your patience.
>
> Hi, Arnd
>
> From Rob's suggestion, we have to list the properties node in ufs-hisi.txt bingings even if documented in the common binding.
>
> -----????-----
> ???: Rob Herring [mailto:robh at kernel.org]
> ????: 2018?4?24? 20:58
> ???: liwei (CM)
> ??: mark.rutland at arm.com; catalin.marinas at arm.com; will.deacon at arm.com; vinholikatti at gmail.com; jejb at linux.vnet.ibm.com; martin.petersen at oracle.com; khilman at baylibre.com; arnd at arndb.de; gregory.clement at free-electrons.com; thomas.petazzoni at free-electrons.com; yamada.masahiro at socionext.com; riku.voipio at linaro.org; treding at nvidia.com; krzk at kernel.org; devicetree at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-scsi at vger.kernel.org; zangleigang; Gengjianfeng; guodong.xu at linaro.org
> ??: Re: [PATCH v9 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs
>
> On Tue, Apr 17, 2018 at 10:08:11PM +0800, Li Wei wrote:
>> add ufs node document for Hisilicon.
>>
>> Signed-off-by: Li Wei <liwei213@huawei.com>
>> ---
>> Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 29 ++++++++++++++++++++++
>> .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 10 +++++---
>> 2 files changed, 36 insertions(+), 3 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
>> new file mode 100644
>> index 000000000000..d49ab7d8f31d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
>> @@ -0,0 +1,29 @@
>> +* Hisilicon Universal Flash Storage (UFS) Host Controller
>> +
>> +UFS nodes are defined to describe on-chip UFS hardware macro.
>> +Each UFS Host Controller should have its own node.
>> +
>> +Required properties:
>> +- compatible : compatible list, contains one of the following -
>> + "hisilicon,hi3660-ufs", "jedec,ufs-1.1" for hisi ufs
>> + host controller present on Hi36xx chipset.
>> +- reg : should contain UFS register address space & UFS SYS CTRL register address,
>> +- interrupt-parent : interrupt device
>> +- interrupts : interrupt number
>> +- resets : reset node register, the "arst" corresponds to reset the APB/AXI bus.
>
> arst belongs in reset-names.
>
> OK, I will fix it in next patch;
>
>> +- reset-names : describe reset node register
>
> What happened to clocks? You still have to list which ones apply even if
> documented in the common binding.
>
> OK, I will fix it in next patch;
>
>> +
>> +Example:
>> +
>> + ufs: ufs at ff3b0000 {
>> + compatible = "hisilicon,hi3660-ufs", "jedec,ufs-1.1";
>> + /* 0: HCI standard */
>> + /* 1: UFS SYS CTRL */
>> + reg = <0x0 0xff3b0000 0x0 0x1000>,
>> + <0x0 0xff3b1000 0x0 0x1000>;
>> + interrupt-parent = <&gic>;
>> + interrupts = <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>;
>> + /* offset: 0x84; bit: 7 */
>> + resets = <&crg_rst 0x84 7>;
>> + reset-names = "arst";
>> + };
>> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> index c39dfef76a18..adcfb79f63f5 100644
>> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> @@ -41,6 +41,8 @@ Optional properties:
>> -lanes-per-direction : number of lanes available per direction - either 1 or 2.
>> Note that it is assume same number of lanes is used both
>> directions at once. If not specified, default is 2 lanes per direction.
>> +- resets : reset node register, the "rst" corresponds to reset the whole UFS IP.
>> +- reset-names : describe reset node register
>
> Does your controller have 1 or 2 resets? There's no point in adding this
> here if it doesn't apply to your controller.
>
> There are 2 reset in our soc init, the "rst" corresponds to reset the whole UFS IP, and " arst " only reset the APB/AXI bus.
> Discussed with our soc colleagues that "arst" is assert by default and needs to deassert,but it done in bootloader,so will remove 'arst' in next patch.
>
> About the 'reset' property?it seems that Arnd Bergmann has different suggestion?he suggested that add 'rst' to ufshcd-pltfrm because it seems common.
> But it looks like only our soc init needs it. What's your opinion? Does it still needs add to common bindings?
For a single reset, then I'm fine with it being in the common
bindings. If there are multiple then it should be in the specific
bindings as the reset names are likely different.
OK, I will remove the 'arst' and keep only 'rst' in tne common bingings.
Rob
^ permalink raw reply
* Re: [PATCH v10 00/27] ARM: davinci: convert to common clock framework
From: Adam Ford @ 2018-05-17 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509172606.29387-1-david@lechnology.com>
On Wed, May 9, 2018 at 12:25 PM, David Lechner <david@lechnology.com> wrote:
> This series converts mach-davinci to use the common clock framework.
>
> The series works like this, the first 3 patches fix some issues with the clock
> drivers that have already been accepted into the mainline kernel.
>
> Then, starting with "ARM: davinci: pass clock as parameter to
> davinci_timer_init()", we get the mach code ready for the switch by adding the
> code needed for the new clock drivers and adding #ifndef CONFIG_COMMON_CLK
> around the legacy clocks so that we can switch easily between the old and the
> new.
>
> "ARM: davinci: switch to common clock framework" actually flips the switch
> to start using the new clock drivers. Then the next 8 patches remove all
> of the old clock code.
>
> The final four patches add device tree clock support to the one SoC that
> supports it.
>
> This series has been tested on TI OMAP-L138 LCDK (both device tree and legacy
> board file).
>
I am find. I don't know what I did wrong, but it's working fine. If
you want to add my 'tested-by' go ahead.
Tested-by: Adam Ford <aford173@gmail.com> #da850-evm, ethernet, spi
flash, SD, UART
>
> Changes:
>
> v10 changes (also see individual patches for details):
> - Reworked device tree bindings for DaVinci timer.
> - Dropped helper functions to conditionally call devm_* versions of functions
> - Fix some typos
> - Fix some rebasing issues introduced in v9
>
> v9 changes (also see individual patches for details):
> - Rebased on linux-davnci/master (f5e3203bb775)
> - Dropped drivers/clk patches that landed in v4.17
> - New drivers/clk patches for early boot special case
> - New patch for ti,davinci-timer device tree bindings
> - Updated mach/davinci patches to register clocks in early boot when needed
>
> v8 changes (also see individual patches for details):
> - Rebased on linux-davinci/master
> - Dropped use of __init and __initconst attributes in clk drivers
> - Add clkdev lookups for PLL SYSCLKs
> - Fix genpd clock reference counting issue
> - Fix PSC clock driver loading order issue
> - Fix typo in device tree and add more power-domains properties
>
> v7 changes (also see individual patches for details):
> - Rebased on linux-davinci/master (v4.16-rc)
> - Convert clock drivers to platform devices
> - New patch "ARM: davinci: pass clock as parameter to davinci_timer_init()"
> - Fix issues with lcdk and aemif clock lookups and power domains
> - Fixed other minor issues brought up in v6 review
>
> v6 changes (also see individual patches for details):
> - All of the device tree bindings are changed
> - All of the clock drivers are changed significantly
> - Fixed issues brought up during review of v5
> - "ARM: davinci: move davinci_clk_init() to init_time" is removed from this
> series and submitted separately
>
> v5 changes:
> - Basically, this is an entirely new series
> - Patches are broken up into bite-sized pieces
> - Converted PSC clock driver to use regmap
> - Restored "force" flag for certain DA850 clocks
> - Added device tree bindings
> - Moved more of the clock init to drivers/clk
> - Fixed frequency scaling (maybe*)
>
> * I have frequency scaling using cpufreq-dt, so I know the clocks are doing
> what they need to do to make this work, but I haven't figured out how to
> test davinci-cpufreq driver yet. (Patches to make cpufreq-dt work will be
> sent separately after this series has landed.)
>
>
> Dependencies:
>
> There are still some outstanding fixes to get everything working correctly.
> These are all just runtime dependencies and only needed for certain platforms.
>
> - "drm/tilcdc: Fix setting clock divider for omap-l138"[1]
> - "clk: davinci: pll-dm355: fix SYSCLKn parent names"[2]
> - "remoteproc/davinci: common clock framework related fixes"[3]
>
> [1]: https://patchwork.freedesktop.org/patch/210696/
> [2]: https://lkml.org/lkml/2018/5/9/626
> [3]: https://lkml.org/lkml/2018/5/2/201
>
> You can find a working branch with everything included (plus a few extras, like
> cpufreq-dt) in the "common-clk-v10" branch of https://github.com/dlech/ev3dev-kernel.git.
>
>
> Testing/debugging for the uninitiated:
>
> I only have one device to test with, which is based on da850, so I will
> have to rely on others to do some testing here. Since we are dealing with
> clocks, if something isn't working, you most likely won't see output on
> the serial port. To figure out what is going on, you need to enable...
>
> CONFIG_DEBUG_LL=y
> CONFIG_EARLY_PRINTK=y
>
> and add "earlyprintk clk_ignore_unused" to the kernel command line options.
> You may need to select a different UART for this depending on your board. I
> think UART1 is the default in the kernel configuration.
>
> On da850 devices comment out the lines:
>
> /* pll1_sysclk2 is not affected by CPU scaling, so use it for async3 */
> parent = clk_hw_get_parent_by_index(&mux->hw, 1);
> if (parent)
> clk_set_parent(mux->hw.clk, parent->clk);
> else
> dev_warn(dev, "Failed to find async3 parent clock\n");
>
> in da8xx-cfgchip.c or, if using device tree, comment out the lines:
>
> assigned-clocks = <&async3_clk>;
> assigned-clock-parents = <&pll1_sysclk 2>;
>
> in da850.dtsi when doing earlyprintk, otherwise the UART1 and UART2 clock
> source will change during boot and cause garbled output after a point.
>
>
> David Lechner (27):
> clk: davinci: pll: allow dev == NULL
> clk: davinci: da850-pll: change PLL0 to CLK_OF_DECLARE
> clk: davinci: psc: allow for dev == NULL
> ARM: davinci: pass clock as parameter to davinci_timer_init()
> ARM: davinci: da830: add new clock init using common clock framework
> ARM: davinci: da850: add new clock init using common clock framework
> ARM: davinci: dm355: add new clock init using common clock framework
> ARM: davinci: dm365: add new clock init using common clock framework
> ARM: davinci: dm644x: add new clock init using common clock framework
> ARM: davinci: dm646x: add new clock init using common clock framework
> ARM: davinci: da8xx: add new USB PHY clock init using common clock
> framework
> ARM: davinci: da8xx: add new sata_refclk init using common clock
> framework
> ARM: davinci: remove CONFIG_DAVINCI_RESET_CLOCKS
> ARM: davinci_all_defconfig: remove CONFIG_DAVINCI_RESET_CLOCKS
> ARM: davinci: switch to common clock framework
> ARM: davinci: da830: Remove legacy clock init
> ARM: davinci: da850: Remove legacy clock init
> ARM: davinci: dm355: Remove legacy clock init
> ARM: davinci: dm365: Remove legacy clock init
> ARM: davinci: dm644x: Remove legacy clock init
> ARM: davinci: dm646x: Remove legacy clock init
> ARM: davinci: da8xx: Remove legacy USB and SATA clock init
> ARM: davinci: remove legacy clocks
> dt-bindings: timer: new bindings for TI DaVinci timer
> ARM: davinci: add device tree support to timer
> ARM: davinci: da8xx-dt: switch to device tree clocks
> ARM: dts: da850: Add clocks
>
> .../bindings/timer/ti,davinci-timer.txt | 37 +
> arch/arm/Kconfig | 5 +-
> arch/arm/boot/dts/da850-enbw-cmc.dts | 4 +
> arch/arm/boot/dts/da850-evm.dts | 4 +
> arch/arm/boot/dts/da850-lcdk.dts | 9 +
> arch/arm/boot/dts/da850-lego-ev3.dts | 4 +
> arch/arm/boot/dts/da850.dtsi | 168 ++++
> arch/arm/configs/davinci_all_defconfig | 1 -
> arch/arm/mach-davinci/Kconfig | 13 +-
> arch/arm/mach-davinci/Makefile | 4 +-
> arch/arm/mach-davinci/board-da830-evm.c | 12 +-
> arch/arm/mach-davinci/board-da850-evm.c | 2 +
> arch/arm/mach-davinci/board-dm355-evm.c | 2 +
> arch/arm/mach-davinci/board-dm355-leopard.c | 2 +
> arch/arm/mach-davinci/board-dm365-evm.c | 2 +
> arch/arm/mach-davinci/board-dm644x-evm.c | 2 +
> arch/arm/mach-davinci/board-dm646x-evm.c | 2 +
> arch/arm/mach-davinci/board-mityomapl138.c | 2 +
> arch/arm/mach-davinci/board-neuros-osd2.c | 2 +
> arch/arm/mach-davinci/board-omapl138-hawk.c | 11 +-
> arch/arm/mach-davinci/board-sffsdr.c | 2 +
> arch/arm/mach-davinci/clock.c | 745 -----------------
> arch/arm/mach-davinci/clock.h | 76 --
> arch/arm/mach-davinci/common.c | 3 -
> arch/arm/mach-davinci/da830.c | 462 ++---------
> arch/arm/mach-davinci/da850.c | 778 +++---------------
> arch/arm/mach-davinci/da8xx-dt.c | 66 --
> arch/arm/mach-davinci/davinci.h | 8 +
> arch/arm/mach-davinci/devices-da8xx.c | 43 +-
> arch/arm/mach-davinci/devices.c | 1 -
> arch/arm/mach-davinci/dm355.c | 406 ++-------
> arch/arm/mach-davinci/dm365.c | 485 +----------
> arch/arm/mach-davinci/dm644x.c | 344 +-------
> arch/arm/mach-davinci/dm646x.c | 372 +--------
> arch/arm/mach-davinci/include/mach/clock.h | 3 -
> arch/arm/mach-davinci/include/mach/common.h | 11 +-
> arch/arm/mach-davinci/include/mach/da8xx.h | 6 +-
> arch/arm/mach-davinci/pm_domain.c | 5 +
> arch/arm/mach-davinci/psc.c | 137 ---
> arch/arm/mach-davinci/psc.h | 12 -
> arch/arm/mach-davinci/time.c | 39 +-
> arch/arm/mach-davinci/usb-da8xx.c | 242 +-----
> drivers/clk/davinci/pll-da830.c | 4 +-
> drivers/clk/davinci/pll-da850.c | 36 +-
> drivers/clk/davinci/pll-dm355.c | 8 +-
> drivers/clk/davinci/pll-dm365.c | 8 +-
> drivers/clk/davinci/pll-dm644x.c | 8 +-
> drivers/clk/davinci/pll-dm646x.c | 8 +-
> drivers/clk/davinci/pll.c | 110 +--
> drivers/clk/davinci/pll.h | 30 +-
> drivers/clk/davinci/psc-dm355.c | 2 +-
> drivers/clk/davinci/psc-dm365.c | 2 +-
> drivers/clk/davinci/psc-dm644x.c | 2 +-
> drivers/clk/davinci/psc-dm646x.c | 2 +-
> drivers/clk/davinci/psc.c | 27 +-
> include/linux/clk/davinci.h | 29 +
> 56 files changed, 860 insertions(+), 3950 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/timer/ti,davinci-timer.txt
> delete mode 100644 arch/arm/mach-davinci/clock.c
> delete mode 100644 arch/arm/mach-davinci/psc.c
> create mode 100644 include/linux/clk/davinci.h
>
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH] drivers/perf: arm-ccn: stop spamming dmesg in event_init
From: Kim Phillips @ 2018-05-17 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cee9c043-3d64-56b9-4f23-e8c8370387dd@gmail.com>
[adding acme, LKML, linux-perf-users, and other potentially interested]
On Wed, 9 May 2018 17:22:42 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 05/09/2018 04:41 PM, Kim Phillips wrote:
> > On Wed, 9 May 2018 17:06:43 +0100
> > Pawel Moll <pawel.moll@arm.com> wrote:
> >
> >> On Wed, 2018-05-09 at 00:40 +0100, Kim Phillips wrote:
> >>> On Fri, 4 May 2018 11:41:17 +0100 Mark Rutland <mark.rutland@arm.com> wrote:
> >>>
> >>> [adding Pawel, arm-ccn driver author]
> >>
> >> We had this discussion way too many times for my liking. As I said
> >> before - *I* will be fine with the debug messages in the CCN driver.
> >> Now, if there ever turns out to be other user of this thing and gets
> >
> > Sure, this isn't just about Pawel using the driver he wrote - we know
> > you know how to use it because you wrote it. No, it's about all the
> > other potential users out there, esp. first time users, as I once was.
> >
> >> into problems with event configuration, I'd hope that he/she can count
> >> on support from the knowledgable people here... (just checked and both
> >
> > I abhor having to suggest our users email this list in order to find out
> > how to use the PMU drivers. First time users are going to tend to
> > steer completely away if they don't have the patience to debug a silent
> > PMU, rather than email this mailing list - sorry, but that's just
> > adding a huge usage barrier - for what - fuzzer runner's convenience?
> >
> >> RHEL 7.5 and Ubuntu 16.04.3 kernels on AArch64 come with
> >> CONFIG_DYNAMIC_DEBUG=y, so it's a matter of explaining what has to be
> >> enabled where; sadly this information did not find its way into the
> >> commit description)
> >
> > I can't think of a more difficult to find, more far-away, alien
> > place for end users to find help with perf, sorry.
> >
> >>>> The ARM CCN PMU driver uses dev_warn() to complain about parameters
> >>> in
> >>>> the user-provided perf_event_attr. This means that under normal
> >>>> operation (e.g. a single invocation of the perf tool), dmesg may be
> >>>> spammed with multiple messages.
> >>
> >> Surely Mark, in his role as maintainer of drivers/perf/ (and a few
> >> other locations), meant to use much more technical and emotion-free
> >> subject, along the lines of "reduce a number of dmesg warnings at event
> >> init".
> >
> > 'reduce a number' is the wrong word: warnings are completely
> > eliminated. Debug-level messages occur at exactly the same
> > frequency/amount.
> >
> > But I still object to the rationale overall - it seems this is about
> > running fuzzers? I even offered an alternative for fuzzer runners: is
> > modifying the loglevel prior to fuzzing somehow unacceptable?
>
> I don't have any dog in this, but maybe if providing information to the
> users is so essential to having a pleasant user experience, then
> rethinking the whole way these messages are funneled is necessary
> because the kernel log + dmesg is by no means appropriate. Take a look
> at what the networking maintainers recently did with netlink extended
> ack. You used to just get an "unsupported" error, and now you know
> exactly what is wrong when extack is available. It seems to me like
> something like this is what you might want here since you want to have
> perf be as user friendly as possible.
Thanks, Florian.
Acme & other perf people, do you foresee a problem adding netlink
extended ack support to the perf subsystem for extended error message
communication?
If not, is struct perf_event_attr amenable to having error reporting
bit(s) added? Recall my last attempt failed because it couldn't
discriminate between the perf core and the PMU driver returning the
-Evalue:
https://patchwork.kernel.org/patch/10025555/
Thanks,
Kim
^ permalink raw reply
* [PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware
From: Brian Norris @ 2018-05-16 23:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526354560-23135-4-git-send-email-hl@rock-chips.com>
+ Kishon
Hi,
On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on firmware, if software training fail, keep firmware
> training as a fallback if sw training fails.
>
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> Changes in v4:
> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() follow Sean suggest
>
> drivers/gpu/drm/rockchip/Makefile | 3 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
> drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 ++++++++++++++++++++++++
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 31 +-
> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
> 6 files changed, 505 insertions(+), 13 deletions(-)
> create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
...
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> new file mode 100644
> index 0000000..7efd070
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> @@ -0,0 +1,420 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Chris Zhong <zyw@rock-chips.com>
> + */
> +
> +#include <linux/device.h>
> +#include <linux/delay.h>
> +#include <linux/phy/phy.h>
> +#include <soc/rockchip/rockchip_phy_typec.h>
> +
> +#include "cdn-dp-core.h"
> +#include "cdn-dp-reg.h"
> +
> +static void cdn_dp_set_signal_levels(struct cdn_dp_device *dp)
> +{
> + struct cdn_dp_port *port = dp->port[dp->active_port];
> + struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
This is still antithetical to the PHY framework; you're assuming that
this is a particular type of PHY here.
> +
> + int rate = drm_dp_bw_code_to_link_rate(dp->link.rate);
> + u8 swing = (dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) >>
> + DP_TRAIN_VOLTAGE_SWING_SHIFT;
> + u8 pre_emphasis = (dp->train_set[0] & DP_TRAIN_PRE_EMPHASIS_MASK)
> + >> DP_TRAIN_PRE_EMPHASIS_SHIFT;
> +
> + tcphy->typec_phy_config(port->phy, rate, dp->link.num_lanes,
> + swing, pre_emphasis);
Is this something generic that could be added as a new PHY API instead?
> +}
Brian
^ permalink raw reply
* [PATCH v6 1/2] dt-bindings: Documentation for qcom, llcc
From: rishabhb at codeaurora.org @ 2018-05-16 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152649413707.210890.2655572242392552759@swboyd.mtv.corp.google.com>
On 2018-05-16 11:08, Stephen Boyd wrote:
> Quoting rishabhb at codeaurora.org (2018-05-16 10:33:14)
>> On 2018-05-16 10:03, Stephen Boyd wrote:
>> > Quoting Rishabh Bhatnagar (2018-05-08 13:22:00)
>>
>> >> +
>> >> +- max-slices:
>> >> + usage: required
>> >> + Value Type: <u32>
>> >> + Definition: Number of cache slices supported by hardware
>> >> +
>> >> +Example:
>> >> +
>> >> + llcc: qcom,llcc at 1100000 {
>> >
>> > cache-controller at 1100000 ?
>> >
>> We have tried to use consistent naming convention as in llcc_*
>> everywhere.
>> Using cache-controller will mix and match the naming convention. Also
>> in
>> the documentation it is explained what llcc is and its full form.
>>
>
> DT prefers standard node names as opposed to vendor specific node
> names.
> Isn't it a cache controller? I fail to see why this can't be done.
Hi Stephen,
The driver is vendor specific and also for uniformity purposes we
preferred
to go with this name.
^ permalink raw reply
* [PATCH v3 3/3] x86/mm: add TLB purge to free pmd/pte page interfaces
From: Toshi Kani @ 2018-05-16 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516233207.1580-1-toshi.kani@hpe.com>
ioremap() calls pud_free_pmd_page() / pmd_free_pte_page() when it creates
a pud / pmd map. The following preconditions are met at their entry.
- All pte entries for a target pud/pmd address range have been cleared.
- System-wide TLB purges have been peformed for a target pud/pmd address
range.
The preconditions assure that there is no stale TLB entry for the range.
Speculation may not cache TLB entries since it requires all levels of page
entries, including ptes, to have P & A-bits set for an associated address.
However, speculation may cache pud/pmd entries (paging-structure caches)
when they have P-bit set.
Add a system-wide TLB purge (INVLPG) to a single page after clearing
pud/pmd entry's P-bit.
SDM 4.10.4.1, Operation that Invalidate TLBs and Paging-Structure Caches,
states that:
INVLPG invalidates all paging-structure caches associated with the
current PCID regardless of the liner addresses to which they correspond.
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: <stable@vger.kernel.org>
---
arch/x86/mm/pgtable.c | 34 ++++++++++++++++++++++++++++------
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index f60fdf411103..7e96594c7e97 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -721,24 +721,42 @@ int pmd_clear_huge(pmd_t *pmd)
* @pud: Pointer to a PUD.
* @addr: Virtual address associated with pud.
*
- * Context: The pud range has been unmaped and TLB purged.
+ * Context: The pud range has been unmapped and TLB purged.
* Return: 1 if clearing the entry succeeded. 0 otherwise.
*/
int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
- pmd_t *pmd;
+ pmd_t *pmd, *pmd_sv;
+ pte_t *pte;
int i;
if (pud_none(*pud))
return 1;
pmd = (pmd_t *)pud_page_vaddr(*pud);
+ pmd_sv = (pmd_t *)__get_free_page(GFP_KERNEL);
+ if (!pmd_sv)
+ return 0;
- for (i = 0; i < PTRS_PER_PMD; i++)
- if (!pmd_free_pte_page(&pmd[i], addr + (i * PMD_SIZE)))
- return 0;
+ for (i = 0; i < PTRS_PER_PMD; i++) {
+ pmd_sv[i] = pmd[i];
+ if (!pmd_none(pmd[i]))
+ pmd_clear(&pmd[i]);
+ }
pud_clear(pud);
+
+ /* INVLPG to clear all paging-structure caches */
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE-1);
+
+ for (i = 0; i < PTRS_PER_PMD; i++) {
+ if (!pmd_none(pmd_sv[i])) {
+ pte = (pte_t *)pmd_page_vaddr(pmd_sv[i]);
+ free_page((unsigned long)pte);
+ }
+ }
+
+ free_page((unsigned long)pmd_sv);
free_page((unsigned long)pmd);
return 1;
@@ -749,7 +767,7 @@ int pud_free_pmd_page(pud_t *pud, unsigned long addr)
* @pmd: Pointer to a PMD.
* @addr: Virtual address associated with pmd.
*
- * Context: The pmd range has been unmaped and TLB purged.
+ * Context: The pmd range has been unmapped and TLB purged.
* Return: 1 if clearing the entry succeeded. 0 otherwise.
*/
int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
@@ -761,6 +779,10 @@ int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
pte = (pte_t *)pmd_page_vaddr(*pmd);
pmd_clear(pmd);
+
+ /* INVLPG to clear all paging-structure caches */
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE-1);
+
free_page((unsigned long)pte);
return 1;
^ permalink raw reply related
* [PATCH v3 2/3] ioremap: Update pgtable free interfaces with addr
From: Toshi Kani @ 2018-05-16 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516233207.1580-1-toshi.kani@hpe.com>
From: Chintan Pandya <cpandya@codeaurora.org>
This patch ("mm/vmalloc: Add interfaces to free unmapped
page table") adds following 2 interfaces to free the page
table in case we implement huge mapping.
pud_free_pmd_page() and pmd_free_pte_page()
Some architectures (like arm64) needs to do proper TLB
maintanance after updating pagetable entry even in map.
Why ? Read this,
https://patchwork.kernel.org/patch/10134581/
Pass 'addr' in these interfaces so that proper TLB ops
can be performed.
[toshi at hpe.com: merge changes]
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: <stable@vger.kernel.org>
---
arch/arm64/mm/mmu.c | 4 ++--
arch/x86/mm/pgtable.c | 12 +++++++-----
include/asm-generic/pgtable.h | 8 ++++----
lib/ioremap.c | 4 ++--
4 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9f1ec1..da98828609a1 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -973,12 +973,12 @@ int pmd_clear_huge(pmd_t *pmdp)
return 1;
}
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
return pud_none(*pud);
}
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
return pmd_none(*pmd);
}
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index 3f7180bc5f52..f60fdf411103 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -719,11 +719,12 @@ int pmd_clear_huge(pmd_t *pmd)
/**
* pud_free_pmd_page - Clear pud entry and free pmd page.
* @pud: Pointer to a PUD.
+ * @addr: Virtual address associated with pud.
*
* Context: The pud range has been unmaped and TLB purged.
* Return: 1 if clearing the entry succeeded. 0 otherwise.
*/
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
pmd_t *pmd;
int i;
@@ -734,7 +735,7 @@ int pud_free_pmd_page(pud_t *pud)
pmd = (pmd_t *)pud_page_vaddr(*pud);
for (i = 0; i < PTRS_PER_PMD; i++)
- if (!pmd_free_pte_page(&pmd[i]))
+ if (!pmd_free_pte_page(&pmd[i], addr + (i * PMD_SIZE)))
return 0;
pud_clear(pud);
@@ -746,11 +747,12 @@ int pud_free_pmd_page(pud_t *pud)
/**
* pmd_free_pte_page - Clear pmd entry and free pte page.
* @pmd: Pointer to a PMD.
+ * @addr: Virtual address associated with pmd.
*
* Context: The pmd range has been unmaped and TLB purged.
* Return: 1 if clearing the entry succeeded. 0 otherwise.
*/
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
pte_t *pte;
@@ -766,7 +768,7 @@ int pmd_free_pte_page(pmd_t *pmd)
#else /* !CONFIG_X86_64 */
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
return pud_none(*pud);
}
@@ -775,7 +777,7 @@ int pud_free_pmd_page(pud_t *pud)
* Disable free page handling on x86-PAE. This assures that ioremap()
* does not update sync'd pmd entries. See vmalloc_sync_one().
*/
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
return pmd_none(*pmd);
}
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index f59639afaa39..b081794ba135 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -1019,8 +1019,8 @@ int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot);
int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot);
int pud_clear_huge(pud_t *pud);
int pmd_clear_huge(pmd_t *pmd);
-int pud_free_pmd_page(pud_t *pud);
-int pmd_free_pte_page(pmd_t *pmd);
+int pud_free_pmd_page(pud_t *pud, unsigned long addr);
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr);
#else /* !CONFIG_HAVE_ARCH_HUGE_VMAP */
static inline int p4d_set_huge(p4d_t *p4d, phys_addr_t addr, pgprot_t prot)
{
@@ -1046,11 +1046,11 @@ static inline int pmd_clear_huge(pmd_t *pmd)
{
return 0;
}
-static inline int pud_free_pmd_page(pud_t *pud)
+static inline int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
return 0;
}
-static inline int pmd_free_pte_page(pmd_t *pmd)
+static inline int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
return 0;
}
diff --git a/lib/ioremap.c b/lib/ioremap.c
index 54e5bbaa3200..517f5853ffed 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -92,7 +92,7 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned long addr,
if (ioremap_pmd_enabled() &&
((next - addr) == PMD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
- pmd_free_pte_page(pmd)) {
+ pmd_free_pte_page(pmd, addr)) {
if (pmd_set_huge(pmd, phys_addr + addr, prot))
continue;
}
@@ -119,7 +119,7 @@ static inline int ioremap_pud_range(p4d_t *p4d, unsigned long addr,
if (ioremap_pud_enabled() &&
((next - addr) == PUD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PUD_SIZE) &&
- pud_free_pmd_page(pud)) {
+ pud_free_pmd_page(pud, addr)) {
if (pud_set_huge(pud, phys_addr + addr, prot))
continue;
}
^ permalink raw reply related
* [PATCH v3 1/3] x86/mm: disable ioremap free page handling on x86-PAE
From: Toshi Kani @ 2018-05-16 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516233207.1580-1-toshi.kani@hpe.com>
ioremap() supports pmd mappings on x86-PAE. However, kernel's pmd
tables are not shared among processes on x86-PAE. Therefore, any
update to sync'd pmd entries need re-syncing. Freeing a pte page
also leads to a vmalloc fault and hits the BUG_ON in vmalloc_sync_one().
Disable free page handling on x86-PAE. pud_free_pmd_page() and
pmd_free_pte_page() simply return 0 if a given pud/pmd entry is present.
This assures that ioremap() does not update sync'd pmd entries at the
cost of falling back to pte mappings.
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Reported-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: <stable@vger.kernel.org>
---
arch/x86/mm/pgtable.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index ffc8c13c50e4..3f7180bc5f52 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -715,6 +715,7 @@ int pmd_clear_huge(pmd_t *pmd)
return 0;
}
+#ifdef CONFIG_X86_64
/**
* pud_free_pmd_page - Clear pud entry and free pmd page.
* @pud: Pointer to a PUD.
@@ -762,4 +763,22 @@ int pmd_free_pte_page(pmd_t *pmd)
return 1;
}
+
+#else /* !CONFIG_X86_64 */
+
+int pud_free_pmd_page(pud_t *pud)
+{
+ return pud_none(*pud);
+}
+
+/*
+ * Disable free page handling on x86-PAE. This assures that ioremap()
+ * does not update sync'd pmd entries. See vmalloc_sync_one().
+ */
+int pmd_free_pte_page(pmd_t *pmd)
+{
+ return pmd_none(*pmd);
+}
+
+#endif /* CONFIG_X86_64 */
#endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
^ permalink raw reply related
* [PATCH v3 0/3] fix free pmd/pte page handlings on x86
From: Toshi Kani @ 2018-05-16 23:32 UTC (permalink / raw)
To: linux-arm-kernel
This series fixes two issues in the x86 ioremap free page handlings
for pud/pmd mappings.
Patch 01 fixes BUG_ON on x86-PAE reported by Joerg. It disables
the free page handling on x86-PAE.
Patch 02-03 fixes a possible issue with speculation which can cause
stale page-directory cache.
- Patch 02 is from Chintan's v9 01/04 patch [1], which adds a new arg
'addr', with my merge change to patch 01.
- Patch 03 adds a TLB purge (INVLPG) to purge page-structure caches
that may be cached by speculation. See the patch descriptions for
more detal.
[1] https://patchwork.kernel.org/patch/10371015/
v3:
- Fixed a build error in v2.
v2:
- Reordered patch-set, so that patch 01 can be applied independently.
- Added a NULL pointer check for the page alloc in patch 03.
---
Toshi Kani (2):
1/3 x86/mm: disable ioremap free page handling on x86-PAE
3/3 x86/mm: add TLB purge to free pmd/pte page interfaces
Chintan Pandya (1):
2/3 ioremap: Update pgtable free interfaces with addr
---
arch/arm64/mm/mmu.c | 4 +--
arch/x86/mm/pgtable.c | 59 +++++++++++++++++++++++++++++++++++++------
include/asm-generic/pgtable.h | 8 +++---
lib/ioremap.c | 4 +--
4 files changed, 59 insertions(+), 16 deletions(-)
^ 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