Re: [PATCH resend v2 3/9] mfd: axp20x: Add support for AXP809 PMIC
Hi Lee,
On Mon, Apr 11, 2016 at 4:24 PM, Lee Jones wrote:
> On Tue, 29 Mar 2016, Chen-Yu Tsai wrote:
>
>> The X-Powers AXP809 is a new PMIC that is paired with Allwinner's A80
>> SoC, along with a slave AXP806 PMIC.
>>
>> This PMIC is quite similar to the earlier AXP223, though the interrupts
>> and regulator have changed a bit.
>>
>> This patch adds support for the interrupts and power button of the PMIC.
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> drivers/mfd/axp20x-rsb.c | 1 +
>> drivers/mfd/axp20x.c | 79
>> ++
>> include/linux/mfd/axp20x.h | 59 ++
>> 3 files changed, 139 insertions(+)
>
> Applied, thanks.
Could you also merge the MAINTAINERS patch ("MAINTAINERS: Add entry for
X-Powers AXP family PMIC drivers") and push an immutable tree for Mark
to merge the regulator patch?
Thanks again.
ChenYu
>
>> diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
>> index 28c20247c112..a407527bcd09 100644
>> --- a/drivers/mfd/axp20x-rsb.c
>> +++ b/drivers/mfd/axp20x-rsb.c
>> @@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
>>
>> static const struct of_device_id axp20x_rsb_of_match[] = {
>> { .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
>> + { .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
>> { },
>> };
>> MODULE_DEVICE_TABLE(of, axp20x_rsb_of_match);
>> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
>> index a57d6e940610..1ce923277cc8 100644
>> --- a/drivers/mfd/axp20x.c
>> +++ b/drivers/mfd/axp20x.c
>> @@ -37,6 +37,7 @@ static const char * const axp20x_model_names[] = {
>> "AXP221",
>> "AXP223",
>> "AXP288",
>> + "AXP809",
>> };
>>
>> static const struct regmap_range axp152_writeable_ranges[] = {
>> @@ -85,6 +86,7 @@ static const struct regmap_access_table
>> axp20x_volatile_table = {
>> .n_yes_ranges = ARRAY_SIZE(axp20x_volatile_ranges),
>> };
>>
>> +/* AXP22x ranges are shared with the AXP809, as they cover the same range */
>> static const struct regmap_range axp22x_writeable_ranges[] = {
>> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
>> regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
>> @@ -211,6 +213,20 @@ static struct resource axp288_fuel_gauge_resources[] = {
>> },
>> };
>>
>> +static struct resource axp809_pek_resources[] = {
>> + {
>> + .name = "PEK_DBR",
>> + .start = AXP809_IRQ_PEK_RIS_EDGE,
>> + .end= AXP809_IRQ_PEK_RIS_EDGE,
>> + .flags = IORESOURCE_IRQ,
>> + }, {
>> + .name = "PEK_DBF",
>> + .start = AXP809_IRQ_PEK_FAL_EDGE,
>> + .end= AXP809_IRQ_PEK_FAL_EDGE,
>> + .flags = IORESOURCE_IRQ,
>> + },
>> +};
>> +
>> static const struct regmap_config axp152_regmap_config = {
>> .reg_bits = 8,
>> .val_bits = 8,
>> @@ -378,6 +394,41 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
>> INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG,5, 1),
>> };
>>
>> +static const struct regmap_irq axp809_regmap_irqs[] = {
>> + INIT_REGMAP_IRQ(AXP809, ACIN_OVER_V,0, 7),
>> + INIT_REGMAP_IRQ(AXP809, ACIN_PLUGIN,0, 6),
>> + INIT_REGMAP_IRQ(AXP809, ACIN_REMOVAL, 0, 5),
>> + INIT_REGMAP_IRQ(AXP809, VBUS_OVER_V,0, 4),
>> + INIT_REGMAP_IRQ(AXP809, VBUS_PLUGIN,0, 3),
>> + INIT_REGMAP_IRQ(AXP809, VBUS_REMOVAL, 0, 2),
>> + INIT_REGMAP_IRQ(AXP809, VBUS_V_LOW, 0, 1),
>> + INIT_REGMAP_IRQ(AXP809, BATT_PLUGIN,1, 7),
>> + INIT_REGMAP_IRQ(AXP809, BATT_REMOVAL, 1, 6),
>> + INIT_REGMAP_IRQ(AXP809, BATT_ENT_ACT_MODE, 1, 5),
>> + INIT_REGMAP_IRQ(AXP809, BATT_EXIT_ACT_MODE, 1, 4),
>> + INIT_REGMAP_IRQ(AXP809, CHARG, 1, 3),
>> + INIT_REGMAP_IRQ(AXP809, CHARG_DONE, 1, 2),
>> + INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_HIGH, 2, 7),
>> + INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_HIGH_END, 2, 6),
>> + INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_LOW, 2, 5),
>> + INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_LOW_END, 2, 4),
>> + INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_HIGH, 2, 3),
>> + INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_HIGH_END, 2, 2),
>> + INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_LOW, 2, 1),
>> + INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_LOW_END, 2, 0),
>> + INIT_REGMAP_IRQ(AXP809, DIE_TEMP_HIGH, 3, 7),
>> + INIT_REGMAP_IRQ(AXP809, LOW_PWR_LVL1, 3, 1),
>> + INIT_REGMAP_IRQ(AXP809, LOW_PWR_LVL2, 3, 0),
>> + INIT_REGMAP_IRQ(AXP809, TIMER, 4, 7),
>> + INIT_REGMAP_IRQ(AXP809, PEK_RIS_EDGE, 4, 6),
>> + INIT_REGMAP_IRQ(AXP809, PEK_FAL_EDGE, 4, 5),
>> + INIT_REGMAP_IRQ(AXP809, PEK_SHORT, 4, 4),
>> +
Re: [PATCH] usb: core: Do not use sizeof on pointer type
Vaishali Thakkar writes: > When sizeof is applied to a pointer typed expression, it gives > the size of the pointer. So, do not use sizeof on pointer type. What if the intended result was the size of the pointer? > Problem found using Coccinelle. Yes, sure. But you cannot just blindly apply the result without reading and understanding the code. Bjørn
Re: [PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings
On Thu, Apr 21, 2016 at 9:15 PM, Rob Herring wrote:
> On Wed, Apr 20, 2016 at 03:02:31PM +0530, Vinay Simha BN wrote:
>> Add documentation for lt070me05000 panel
>>
>> Signed-off-by: Vinay Simha BN
>> ---
>> .../bindings/display/panel/jdi,lt070me05000.txt| 43
>> ++
>> 1 file changed, 43 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>> b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>> new file mode 100644
>> index 000..ffe0550
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>> @@ -0,0 +1,43 @@
>> +JDI model LT070ME05000 1200x1920 7" DSI Panel
>> +
>> +Required properties:
>> +- compatible: should be "jdi,lt070me05000"
>> +- power-supply: phandle of the regulator that provides the supply voltage
>> + IOVCC , power supply for LCM (1.8V)
>> +- vddp-supply: phandle of the regulator that provides the supply voltage
>> + Power IC supply (3-5V)
>> +- dcdc_en-supply: phandle of the regulator that provides the supply voltage
>> + Power IC supply enable, High active
>> +- reset-gpio: phandle of gpio for reset line
>> + This should be 8mA, gpio can be configured using mux and pinctrl.
>> + XRES, Reset, Low active
>> +- enable-gpio: phandle of gpio for enable line
>> + LED_EN, LED backlight enable, High active
>
> These should all be -gpios instead.
will implement in v3
>
>> +- vcc-gpio: phandle of regulator/gpio that provides the supply voltage
>> + VDD, LED power supply (3-5V)
>
> Is it a regulator or gpio?
>
VDD is LED power supply, but in nexus 7 2nd gen they are using gpio 23
instead of regulator.
if we use vcc-supply, not sure we can give the gpio device tree entry
to it in nexus 7 dts. Any inputs ?
>> +
>> +Optional properties:
>> +- pwm-gpio: phandle of gpio/pwm
>
> This should use the PWM binding. It may not be a GPIO on some hosts.
pwm-gpio will go to the backlight (pwm). right now it is not used
since pwm pm8921 upstream driver is not yet implemented. Shall i
remove this pwm-gpio now and the backlight property when pwm pm8921 is
implemented?
>
>> + pwm backlight control, this should be mapped to the backlight level
>> + display brightness (0x51)
>> +
>> +Example:
>> +
>> + dsi0: qcom,mdss_dsi@470 {
>> + panel@0 {
>> + compatible = "jdi,lt070me05000";
>> + reg = <0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&dsi_panel_pinctrl>;
>> +
>> + power-supply = <&pm8921_lvs5>;
>> + vddp-supply = <&pm8921_l17>;
>> + dcdc_en-supply = <&pm8921_lvs7>;
>> +
>> + reset-gpio = <&tlmm_pinmux 54 0>;
>> + enable-gpio = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>;
>> + vcc-gpio = <&pm8921_gpio 23 GPIO_ACTIVE_HIGH>;
>> +
>> + pwm-gpio = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
>> + };
>> + };
>> --
>> 2.1.2
>>
--
Regards,
Vinay Simha.B.N.
Re: [PATCH net v2 0/3] drivers: net: cpsw: phy-handle fixes
On Thursday 21 April 2016 11:20 PM, David Rivshin (Allworx) wrote: > From: David Rivshin > > The first patch fixes a bug that makes dual_emac mode break if > either slave uses the phy-handle property in the devicetree. > > The second patch fixes some cosmetic problems with error messages, > and also makes the binding documentation more explicit. > > The third patch cleans up the fixed-link case to work like > the now-fixed phy-handle case. > > I have tested on the following hardware configurations: > - (EVMSK) dual emac, phy_id property in both slaves > - (EVMSK) dual emac, phy-handle property in both slaves > - (BeagleBoneBlack) single emac, phy_id property > - (custom) single emac, fixed-link subnode > > Nicolas Chauvet reported testing on an HP t410 (dm8148). > > Markus Brunner reported testing v1 on the following [1]: > - emac0 with phy_id and emac1 with fixed phy > - emac0 with phy-handle and emac1 with fixed phy > - emac0 with fixed phy and emac1 with fixed phy > > Reviewed-by: Mugunthan V N Regards Mugunthan V N
[v8, 4/7] dt: move guts devicetree doc out of powerpc directory
Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
since it's used by not only PowerPC but also ARM. And add a specification
for 'little-endian' property.
Signed-off-by: Yangbo Lu
Acked-by: Scott Wood
Acked-by: Rob Herring
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified the description for little-endian property
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Rob Herring'
---
Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
1 file changed, 3 insertions(+)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
b/Documentation/devicetree/bindings/soc/fsl/guts.txt
similarity index 91%
rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
index b71b203..07adca9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
@@ -25,6 +25,9 @@ Recommended properties:
- fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
+ - little-endian : Indicates that the global utilities block is little
+ endian. The default is big endian.
+
Examples:
global-utilities@e {/* global utilities block */
compatible = "fsl,mpc8548-guts";
--
2.1.0.27.g96db324
Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
* Peter Zijlstra wrote: > On Wed, Apr 13, 2016 at 02:49:43PM +0200, Michal Hocko wrote: > > On Wed 13-04-16 12:27:31, Ingo Molnar wrote: > > > > > > * Ingo Molnar wrote: > > > > > > > I'm testing your patches today, if they are otherwise OK [...] > > > > > > got this build failure: > > > > > > ./arch/x86/include/asm/rwsem.h:106:2: error: ‘asm’ operand has > > > impossible constraints > > > > Hmm, I have no idea why 64b didn't have problem with the asm but 32b > > complains. Anyway, the following makes both happy. I have checked the > > generated code for 64b and it hasn't changed after the patch. 32b also > > seems to be generating a proper code. My gcc asm()-foo is rather weak so > > I would feel better if somebody double checked after me. > > I completely blow at this gcc-asm constraints thing too :/ > > In any case, Ingo will you look after the rest of these patches, or do > you want me to pick up the remaining bits? Yeah, it's on my list! Thanks, Ingo
Re: [PATCH] usb: core: Do not use sizeof on pointer type
Vaishali Thakkar wrote: > When sizeof is applied to a pointer typed expression, it gives > the size of the pointer. And why would that be wrong in this case? > +++ b/drivers/usb/core/hcd.c > @@ -1386,7 +1386,7 @@ static int hcd_alloc_coherent(struct usb_bus *bus, > return -EFAULT; > } > > - vaddr = hcd_buffer_alloc(bus, size + sizeof(vaddr), > + vaddr = hcd_buffer_alloc(bus, size + sizeof(*vaddr), >mem_flags, dma_handle); > if (!vaddr) > return -ENOMEM; > Please note the following comment: /* * Store the virtual address of the buffer at the end * of the allocated dma buffer. [...] Regards, Clemens
Re: [PATCH v7 6/8] [media] vcodec: mediatek: Add Mediatek VP8 Video Encoder Driver
Hi,
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.6-rc4 next-20160421]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Tiffany-Lin/Add-MT8173-Video-Encoder-Driver-and-VPU-Driver/20160422-123111
base: git://linuxtv.org/media_tree.git master
config: xtensa-allmodconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:13:0,
from include/linux/interrupt.h:5,
from
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:17:
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c: In function
'vp8_enc_alloc_work_buf':
>> drivers/media/platform/mtk-vcodec/venc/../mtk_vcodec_util.h:56:14: warning:
>> format '%lx' expects argument of type 'long unsigned int', but argument 7
>> has type 'size_t' [-Wformat=]
((struct mtk_vcodec_ctx *)h->ctx)->idx, \
^
include/linux/printk.h:259:34: note: in definition of macro 'pr_info'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:214:3: note: in
expansion of macro 'mtk_vcodec_debug'
mtk_vcodec_debug(inst,
^
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c: In function
'vp8_enc_compose_one_frame':
>> drivers/media/platform/mtk-vcodec/venc/../mtk_vcodec_util.h:62:18: warning:
>> format '%ld' expects argument of type 'long int', but argument 4 has type
>> 'size_t' [-Wformat=]
((struct mtk_vcodec_ctx *)h->ctx)->idx, __func__, ##args)
^
include/linux/printk.h:252:33: note: in definition of macro 'pr_err'
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:279:3: note: in
expansion of macro 'mtk_vcodec_err'
mtk_vcodec_err(inst, "bitstream buf size is too small(%ld)",
^
vim +56 drivers/media/platform/mtk-vcodec/venc/../mtk_vcodec_util.h
67e5508b Tiffany Lin 2016-04-22 50 #define mtk_v4l2_debug_leave()
mtk_v4l2_debug(3, "-")
67e5508b Tiffany Lin 2016-04-22 51
67e5508b Tiffany Lin 2016-04-22 52 #define mtk_vcodec_debug(h, fmt, args...)
\
67e5508b Tiffany Lin 2016-04-22 53 do {
\
67e5508b Tiffany Lin 2016-04-22 54 if (mtk_vcodec_dbg)
\
67e5508b Tiffany Lin 2016-04-22 55
pr_info("[MTK_VCODEC][%d]: %s() " fmt "\n", \
67e5508b Tiffany Lin 2016-04-22 @56 ((struct
mtk_vcodec_ctx *)h->ctx)->idx, \
67e5508b Tiffany Lin 2016-04-22 57 __func__,
##args); \
67e5508b Tiffany Lin 2016-04-22 58 } while (0)
67e5508b Tiffany Lin 2016-04-22 59
67e5508b Tiffany Lin 2016-04-22 60 #define mtk_vcodec_err(h, fmt, args...)
\
67e5508b Tiffany Lin 2016-04-22 61 pr_err("[MTK_VCODEC][ERROR][%d]: %s() "
fmt "\n", \
67e5508b Tiffany Lin 2016-04-22 @62((struct mtk_vcodec_ctx
*)h->ctx)->idx, __func__, ##args)
67e5508b Tiffany Lin 2016-04-22 63
67e5508b Tiffany Lin 2016-04-22 64 #define mtk_vcodec_debug_enter(h)
mtk_vcodec_debug(h, "+")
67e5508b Tiffany Lin 2016-04-22 65 #define mtk_vcodec_debug_leave(h)
mtk_vcodec_debug(h, "-")
:: The code at line 56 was first introduced by commit
:: 67e5508b437349a82c1a884f6abf3aaa434959e5 vcodec: mediatek: Add Mediatek
V4L2 Video Encoder Driver
:: TO: Tiffany Lin
:: CC: 0day robot
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
[v8, 0/7] Fix eSDHC host version register bug
This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To get the SoC version and revision, it's needed to add the
GUTS driver to access the global utilities registers.
So, the first four patches are to add the GUTS driver.
The following patches except the updating MAINTAINERS patch are to enable
GUTS driver support to get SVR in eSDHC driver and fix host version for T4240.
Yangbo Lu (7):
Documentation: DT: update Freescale DCFG compatible
ARM64: dts: ls2080a: add device configuration node
soc: fsl: add GUTS driver for QorIQ platforms
dt: move guts devicetree doc out of powerpc directory
powerpc/fsl: move mpc85xx.h to include/linux/fsl
MAINTAINERS: add entry for Freescale SoC specific driver
mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
Documentation/devicetree/bindings/arm/fsl.txt | 2 +-
.../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
MAINTAINERS| 16 ++-
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c| 3 +-
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +-
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 23
drivers/net/ethernet/freescale/gianfar.c | 2 +-
drivers/soc/Kconfig| 2 +-
drivers/soc/fsl/Kconfig| 8 ++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119 +++
include/linux/fsl/guts.h | 126 +
.../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
17 files changed, 263 insertions(+), 60 deletions(-)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
--
2.1.0.27.g96db324
[PATCH v2 7/9] mtd: fsl-quadspi: Solve Micron Spansion flash command conflict
From: Yunhui Cui
Add some lut_tables to support quad mode for flash n25q128
on the board ls1021a-twr and solve flash Spansion and Micron
command conflict.
In switch {}, The value of command SPINOR_OP_RD_EVCR and
SPINOR_OP_SPANSION_RDAR is the same. They have to share
the same seq_id: SEQID_RDAR_OR_RD_EVCR.
Signed-off-by: Yunhui Cui
---
drivers/mtd/spi-nor/fsl-quadspi.c | 47 ++-
1 file changed, 36 insertions(+), 11 deletions(-)
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 5d9d192..fea18b6 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -207,9 +207,9 @@
#define SEQID_RDCR 9
#define SEQID_EN4B 10
#define SEQID_BRWR 11
-#define SEQID_RDAR 12
+#define SEQID_RDAR_OR_RD_EVCR 12
#define SEQID_WRAR 13
-
+#define SEQID_WD_EVCR 14
#define QUADSPI_MIN_IOMAP SZ_4M
@@ -393,6 +393,7 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
int rxfifo = q->devtype_data->rxfifo;
u32 lut_base;
int i;
+ const struct fsl_qspi_devtype_data *devtype_data = q->devtype_data;
struct spi_nor *nor = &q->nor[0];
u8 addrlen = (nor->addr_width == 3) ? ADDR24BIT : ADDR32BIT;
@@ -489,16 +490,26 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_BRWR),
base + QUADSPI_LUT(lut_base));
+
/*
-* Read any device register.
-* Used for Spansion S25FS-S family flash only.
+* Flash Micron and Spansion command confilict
+* use the same value 0x65. But it indicates different meaning.
*/
- lut_base = SEQID_RDAR * 4;
- qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_SPANSION_RDAR) |
- LUT1(ADDR, PAD1, ADDR24BIT),
- base + QUADSPI_LUT(lut_base));
- qspi_writel(q, LUT0(DUMMY, PAD1, 8) | LUT1(FSL_READ, PAD1, 1),
- base + QUADSPI_LUT(lut_base + 1));
+ lut_base = SEQID_RDAR_OR_RD_EVCR * 4;
+ if (devtype_data->devtype == FSL_QUADSPI_LS2080A) {
+ /*
+ * Read any device register.
+ * Used for Spansion S25FS-S family flash only.
+ */
+ qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_SPANSION_RDAR) |
+ LUT1(ADDR, PAD1, ADDR24BIT),
+ base + QUADSPI_LUT(lut_base));
+ qspi_writel(q, LUT0(DUMMY, PAD1, 8) | LUT1(FSL_READ, PAD1, 1),
+ base + QUADSPI_LUT(lut_base + 1));
+ } else {
+ qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_RD_EVCR),
+ base + QUADSPI_LUT(lut_base));
+ }
/*
* Write any device register.
@@ -511,6 +522,11 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
qspi_writel(q, LUT0(FSL_WRITE, PAD1, 1),
base + QUADSPI_LUT(lut_base + 1));
+ /* Write EVCR register */
+ lut_base = SEQID_WD_EVCR * 4;
+ qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_WD_EVCR),
+ base + QUADSPI_LUT(lut_base));
+
fsl_qspi_lock_lut(q);
}
@@ -523,8 +539,15 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
case SPINOR_OP_READ_FAST:
case SPINOR_OP_READ4_FAST:
return SEQID_READ;
+ /*
+* Spansion & Micron use the same command value 0x65
+* Spansion: SPINOR_OP_SPANSION_RDAR, read any register.
+* Micron: SPINOR_OP_RD_EVCR,
+* read enhanced volatile configuration register.
+* case SPINOR_OP_RD_EVCR:
+*/
case SPINOR_OP_SPANSION_RDAR:
- return SEQID_RDAR;
+ return SEQID_RDAR_OR_RD_EVCR;
case SPINOR_OP_SPANSION_WRAR:
return SEQID_WRAR;
case SPINOR_OP_WREN:
@@ -550,6 +573,8 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
return SEQID_EN4B;
case SPINOR_OP_BRWR:
return SEQID_BRWR;
+ case SPINOR_OP_WD_EVCR:
+ return SEQID_WD_EVCR;
default:
if (cmd == q->nor[0].erase_opcode)
return SEQID_SE;
--
2.1.0.27.g96db324
[PATCH v2 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash
From: Yunhui Cui
With the physical sectors combination, S25FS-S family flash
requires some special operations for read/write functions.
Signed-off-by: Yunhui Cui
---
drivers/mtd/spi-nor/spi-nor.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 157841d..91ee920 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -39,6 +39,10 @@
#define SPI_NOR_MAX_ID_LEN 6
#define SPI_NOR_MAX_ADDR_WIDTH 4
+/* Added for S25FS-S family flash */
+#define SPINOR_CONFIG_REG3_OFFSET 0x84
+#define CR3V_4KB_ERASE_UNABLE 0x8
+#define SPINOR_S25FS_FAMILY_ID 0x81
struct flash_info {
char*name;
@@ -78,6 +82,7 @@ struct flash_info {
};
#define JEDEC_MFR(info)((info)->id[0])
+#define EXT_ID(info) ((info)->id[5])
static const struct flash_info *spi_nor_match_id(const char *name);
@@ -881,6 +886,7 @@ static const struct flash_info spi_nor_ids[] = {
*/
{ "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024, 64,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024, 128,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024, 512, 0)},
{ "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
{ "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
@@ -1018,6 +1024,53 @@ static const struct flash_info *spi_nor_read_id(struct
spi_nor *nor)
return ERR_PTR(-ENODEV);
}
+/*
+ * The S25FS-S family physical sectors may be configured as a
+ * hybrid combination of eight 4-kB parameter sectors
+ * at the top or bottom of the address space with all
+ * but one of the remaining sectors being uniform size.
+ * The Parameter Sector Erase commands (20h or 21h) must
+ * be used to erase the 4-kB parameter sectors individually.
+ * The Sector (uniform sector) Erase commands (D8h or DCh)
+ * must be used to erase any of the remaining
+ * sectors, including the portion of highest or lowest address
+ * sector that is not overlaid by the parameter sectors.
+ * The uniform sector erase command has no effect on parameter sectors.
+ */
+static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor)
+{
+ struct fsl_qspi *q;
+ u32 cr3v_addr = SPINOR_CONFIG_REG3_OFFSET;
+ u8 cr3v = 0x0;
+ int ret = 0x0;
+
+ q = nor->priv;
+
+ nor->cmd_buf[2] = cr3v_addr >> 16;
+ nor->cmd_buf[1] = cr3v_addr >> 8;
+ nor->cmd_buf[0] = cr3v_addr >> 0;
+
+ ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, &cr3v, 1);
+ if (ret)
+ return ret;
+ if (cr3v & CR3V_4KB_ERASE_UNABLE)
+ return 0;
+ ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
+ if (ret)
+ return ret;
+ cr3v = CR3V_4KB_ERASE_UNABLE;
+ nor->program_opcode = SPINOR_OP_SPANSION_WRAR;
+ nor->write(nor, cr3v_addr, 1, NULL, &cr3v);
+
+ ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, &cr3v, 1);
+ if (ret)
+ return ret;
+ if (!(cr3v & CR3V_4KB_ERASE_UNABLE))
+ return -EPERM;
+
+ return 0;
+}
+
static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, u_char *buf)
{
@@ -1311,6 +1364,12 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
enum read_mode mode)
spi_nor_wait_till_ready(nor);
}
+ if (EXT_ID(info) == SPINOR_S25FS_FAMILY_ID) {
+ ret = spansion_s25fs_disable_4kb_erase(nor);
+ if (ret)
+ return ret;
+ }
+
if (!mtd->name)
mtd->name = dev_name(dev);
mtd->priv = nor;
--
2.1.0.27.g96db324
[PATCH v2 1/9] mtd:fsl-quadspi:use the property fields of SPI-NOR
We can get the read/write/erase opcode from the spi nor framework
directly. This patch uses the information stored in the SPI-NOR to
remove the hardcode in the fsl_qspi_init_lut().
Signed-off-by: Yunhui Cui
Signed-off-by: Yunhui Cui
---
drivers/mtd/spi-nor/fsl-quadspi.c | 40 ---
1 file changed, 12 insertions(+), 28 deletions(-)
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 9ab2b51..517ffe2 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -373,9 +373,13 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
void __iomem *base = q->iobase;
int rxfifo = q->devtype_data->rxfifo;
u32 lut_base;
- u8 cmd, addrlen, dummy;
int i;
+ struct spi_nor *nor = &q->nor[0];
+ u8 addrlen = (nor->addr_width == 3) ? ADDR24BIT : ADDR32BIT;
+ u8 read_op = nor->read_opcode;
+ u8 read_dm = nor->read_dummy;
+
fsl_qspi_unlock_lut(q);
/* Clear all the LUT table */
@@ -385,20 +389,10 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
/* Quad Read */
lut_base = SEQID_QUAD_READ * 4;
- if (q->nor_size <= SZ_16M) {
- cmd = SPINOR_OP_READ_1_1_4;
- addrlen = ADDR24BIT;
- dummy = 8;
- } else {
- /* use the 4-byte address */
- cmd = SPINOR_OP_READ_1_1_4;
- addrlen = ADDR32BIT;
- dummy = 8;
- }
-
- qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
+ qspi_writel(q, LUT0(CMD, PAD1, read_op) | LUT1(ADDR, PAD1, addrlen),
base + QUADSPI_LUT(lut_base));
- qspi_writel(q, LUT0(DUMMY, PAD1, dummy) | LUT1(FSL_READ, PAD4, rxfifo),
+ qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
+ LUT1(FSL_READ, PAD4, rxfifo),
base + QUADSPI_LUT(lut_base + 1));
/* Write enable */
@@ -409,16 +403,8 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
/* Page Program */
lut_base = SEQID_PP * 4;
- if (q->nor_size <= SZ_16M) {
- cmd = SPINOR_OP_PP;
- addrlen = ADDR24BIT;
- } else {
- /* use the 4-byte address */
- cmd = SPINOR_OP_PP;
- addrlen = ADDR32BIT;
- }
-
- qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
+ qspi_writel(q, LUT0(CMD, PAD1, nor->program_opcode) |
+ LUT1(ADDR, PAD1, addrlen),
base + QUADSPI_LUT(lut_base));
qspi_writel(q, LUT0(FSL_WRITE, PAD1, 0),
base + QUADSPI_LUT(lut_base + 1));
@@ -432,10 +418,8 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
/* Erase a sector */
lut_base = SEQID_SE * 4;
- cmd = q->nor[0].erase_opcode;
- addrlen = q->nor_size <= SZ_16M ? ADDR24BIT : ADDR32BIT;
-
- qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
+ qspi_writel(q, LUT0(CMD, PAD1, nor->erase_opcode) |
+ LUT1(ADDR, PAD1, addrlen),
base + QUADSPI_LUT(lut_base));
/* Erase the whole chip */
--
2.1.0.27.g96db324
[PATCH v2 2/9] mtd: fsl-quadspi: Rename SEQID_QUAD_READ to SEQID_READ
There are some read modes for flash, such as NORMAL, FAST,
QUAD, DDR QUAD. These modes will use the identical lut table base
So rename SEQID_QUAD_READ to SEQID_READ.
Signed-off-by: Yunhui Cui
Signed-off-by: Yunhui Cui
---
drivers/mtd/spi-nor/fsl-quadspi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 517ffe2..9861290 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -193,7 +193,7 @@
#define QUADSPI_LUT_NUM64
/* SEQID -- we can have 16 seqids at most. */
-#define SEQID_QUAD_READ0
+#define SEQID_READ 0
#define SEQID_WREN 1
#define SEQID_WRDI 2
#define SEQID_RDSR 3
@@ -386,8 +386,8 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
for (i = 0; i < QUADSPI_LUT_NUM; i++)
qspi_writel(q, 0, base + QUADSPI_LUT_BASE + i * 4);
- /* Quad Read */
- lut_base = SEQID_QUAD_READ * 4;
+ /* Read */
+ lut_base = SEQID_READ * 4;
qspi_writel(q, LUT0(CMD, PAD1, read_op) | LUT1(ADDR, PAD1, addrlen),
base + QUADSPI_LUT(lut_base));
@@ -468,7 +468,7 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
{
switch (cmd) {
case SPINOR_OP_READ_1_1_4:
- return SEQID_QUAD_READ;
+ return SEQID_READ;
case SPINOR_OP_WREN:
return SEQID_WREN;
case SPINOR_OP_WRDI:
--
2.1.0.27.g96db324
[PATCH v2 3/9] mtd: spi-nor: fsl-quadspi: add fast-read mode support
From: Yunhui Cui
The qspi driver add generic fast-read mode for different
flash venders. There are some different board flash work on
different mode, such fast-read, quad-mode.
Signed-off-by: Yunhui Cui
---
drivers/mtd/spi-nor/fsl-quadspi.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 9861290..09adaa4 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -389,11 +389,21 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
/* Read */
lut_base = SEQID_READ * 4;
- qspi_writel(q, LUT0(CMD, PAD1, read_op) | LUT1(ADDR, PAD1, addrlen),
- base + QUADSPI_LUT(lut_base));
- qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
- LUT1(FSL_READ, PAD4, rxfifo),
- base + QUADSPI_LUT(lut_base + 1));
+ if (nor->flash_read == SPI_NOR_FAST) {
+ qspi_writel(q, LUT0(CMD, PAD1, read_op) |
+ LUT1(ADDR, PAD1, addrlen),
+ base + QUADSPI_LUT(lut_base));
+ qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
+ LUT1(FSL_READ, PAD1, rxfifo),
+ base + QUADSPI_LUT(lut_base + 1));
+ } else if (nor->flash_read == SPI_NOR_QUAD) {
+ qspi_writel(q, LUT0(CMD, PAD1, read_op) |
+ LUT1(ADDR, PAD1, addrlen),
+ base + QUADSPI_LUT(lut_base));
+ qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
+ LUT1(FSL_READ, PAD4, rxfifo),
+ base + QUADSPI_LUT(lut_base + 1));
+ }
/* Write enable */
lut_base = SEQID_WREN * 4;
@@ -468,6 +478,7 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
{
switch (cmd) {
case SPINOR_OP_READ_1_1_4:
+ case SPINOR_OP_READ_FAST:
return SEQID_READ;
case SPINOR_OP_WREN:
return SEQID_WREN;
--
2.1.0.27.g96db324
Re: [PATCH 5/8] cpufreq: shmobile: Use generic platdev driver
On 22-04-16, 08:41, Geert Uytterhoeven wrote: > I was mainly thinking about kernel size. Ahh, I see.. > If this is done once per boot, the array should be __initconst, > (looking at the code > in next) which is fine as cpufreq_dt_platdev_init() is already __init. Sure, makes sense.. I will do that as a separate patch. Though just to correct what I earlier said, if cpufreq-dt is developed as a module, its done once per module insertion :) -- viresh
Re: [regression] linux318, linux41 - kernel stack is corrupted
On Fri, Apr 22, 2016 at 08:17:58AM +0200, Philip Müller wrote: > Hi Greg, hi Sasha, > > seems I found another regression within the latest point-releases of > 3.18 and 4.1 kernel series. We tested it on AMD and Intel CPUs so far. > They hit the same regression. Other kernels released on that day are not > affected. Do you guys have a clue what might been have missed here? > > 3.18.30 and 4.1.21 didn't had that issue on the same hardware. You are going to have to be a bit more specific here... What is the oops message? How do you reproduce this? Does it also happen on 4.6-rc4? Can you run 'git bisect' to find the offending patch? thanks, greg k-h
Re: [PATCH V2] cpuidle: Change ktime_get() with local_clock()
On Thu, Apr 21, 2016 at 09:41:14PM +0200, Rafael J. Wysocki wrote: > On Thu, Apr 21, 2016 at 10:56 AM, Daniel Lezcano > wrote: > > The ktime_get() can have a non negligeable overhead, use local_clock() > > instead. > > > > In order to test the difference between ktime_get() and local_clock(), > > a quick hack has been added to trigger, via debugfs, 1 times a > > call to ktime_get() and local_clock() and measure the elapsed time. > > > > Then the average value, the min and max is computed for each call. > > > > From userspace, the test above was called 100 times every 2 seconds. > > > > So, ktime_get() and local_clock() have been called 100 times in > > total. > > > > The results are: > > > > ktime_get(): > > > > * average: 101 ns (stddev: 27.4) > > * maximum: 38313 ns > > * minimum: 65 ns > > > > local_clock(): > > == > > * average: 60 ns (stddev: 9.8) > > * maximum: 13487 ns > > * minimum: 46 ns > > > > The local_clock() is faster and more stable. > > > > Even if it is a drop in the ocean, changing the ktime_get() by the > > local_clock() allows to save 80ns at idle time (entry + exit). And > > in some circumstances, especially when there are several CPUs racing > > for the clock access, we save tens of microseconds. > > > > The idle duration resulting from a diff is converted from nanosec to > > microsec. This could be done with integer division (div 1000) - which is > > an expensive operation or by 10 bits shifting (div 1024) - which is fast > > but unprecise. > > > > The following table gives some results at the limits. > > > > -- > > | nsec | div(1000) | div(1024) | > > -- > > | 1e3|1 usec | 976 nsec | > > -- > > | 1e6| 1000 usec | 976 usec | > > -- > > | 1e9| 100 usec | 976562 usec | > > -- > > > > There is a linear deviation of 2.34%. This loss of precision is acceptable > > in the context of the resulting diff which is used for statistics. These > > ones are processed to guess estimate an approximation of the duration of the > > next idle period which ends up into an idle state selection. The selection > > criteria takes into account the next duration based on large intervals, > > represented by the idle state's target residency. > > > > The 2^10 division is enough because the approximation regarding the 1e3 > > division is lost in all the approximations done for the next idle duration > > computation. > > > > Signed-off-by: Daniel Lezcano > > Looks good to me. > > Peter, are you happy with the changelog now? Yep, works for me: Acked-by: Peter Zijlstra (Intel)
[v8, 2/7] ARM64: dts: ls2080a: add device configuration node
Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.
Signed-off-by: Yangbo Lu
Acked-by: Scott Wood
---
Changes for v5:
- Added this patch
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
---
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 9d746c6..8724cf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -191,6 +191,12 @@
clocks = <&sysclk>;
};
+ dcfg: dcfg@1e0 {
+ compatible = "fsl,ls2080a-dcfg", "syscon";
+ reg = <0x0 0x1e0 0x0 0x1>;
+ little-endian;
+ };
+
serial0: serial@21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
--
2.1.0.27.g96db324
[regression] linux318, linux41 - kernel stack is corrupted
Hi Greg, hi Sasha, seems I found another regression within the latest point-releases of 3.18 and 4.1 kernel series. We tested it on AMD and Intel CPUs so far. They hit the same regression. Other kernels released on that day are not affected. Do you guys have a clue what might been have missed here? 3.18.30 and 4.1.21 didn't had that issue on the same hardware. kind regards Philip Müller --- Manjaro Project Lead
Re: [regression] linux318, linux41 - kernel stack is corrupted
Hi Greg, hi Sasha, seems I found another regression within the latest point-releases of 3.18 and 4.1 kernel series. We tested it on AMD and Intel CPUs so far. They hit the same regression. Other kernels released on that day are not affected. Do you guys have a clue what might been have missed here? 3.18.30 and 4.1.21 didn't had that issue on the same hardware. kind regards Philip Müller -- Manjaro Project Lead https://github.com/manjaro/packages-core/issues/36
Re: [PATCH 5/8] cpufreq: shmobile: Use generic platdev driver
Hi Viresh,
On Fri, Apr 22, 2016 at 5:21 AM, Viresh Kumar wrote:
> On 21-04-16, 15:04, Geert Uytterhoeven wrote:
>> On Thu, Apr 21, 2016 at 10:43 AM, Viresh Kumar
>> wrote:
>> > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
>> > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
>> > @@ -29,6 +29,18 @@ static const struct of_device_id machines[] = {
>> > { .compatible = "samsung,exynos5800", },
>> > #endif
>> >
>>
>> I think an #ifdef CONFIG_ARCH_RENESAS block wouldn't hurt, likewise
>> for the other SoCs.
>> Soon you'll have this file filled with lots of compatible values for random\
>> SoCs...
>
> This is going to be done once per boot and this shouldn't hurt. And for new
> platforms we may do things differently as they are going to use opp-v2
> bindings.
I was mainly thinking about kernel size.
If this is done once per boot, the array should be __initconst,
(looking at the code
in next) which is fine as cpufreq_dt_platdev_init() is already __init.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[v8, 5/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
a common header file. It has been used for mpc85xx and it will
be used for ARM-based SoC as well.
Signed-off-by: Yangbo Lu
Acked-by: Wolfram Sang
Acked-by: Stephen Boyd
Acked-by: Scott Wood
Acked-by: Joerg Roedel
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Changed to Move mpc85xx.h to include/linux/fsl/
- Adjusted '#include ' position in file
Changes for v6:
- None
Changes for v7:
- Added 'Acked-by: Wolfram Sang' for I2C part
- Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
Changes for v8:
- Added 'Acked-by: Stephen Boyd' for clk part
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Joerg Roedel' for iommu part
---
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c | 3 +--
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +--
drivers/net/ethernet/freescale/gianfar.c | 2 +-
arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
6 files changed, 7 insertions(+), 9 deletions(-)
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 462aed9..2b0284e 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,13 +13,13 @@
*
*/
+#include
#include
#include
#include
#include
#include
#include
-#include
_GLOBAL(__e500_icache_setup)
mfspr r0, SPRN_L1CSR1
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 7bc1c45..fc7f722 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1148,8 +1149,6 @@ bad_args:
}
#ifdef CONFIG_PPC
-#include
-
static const u32 a4510_svrs[] __initconst = {
(SVR_P2040 << 8) | 0x10,/* P2040 1.0 */
(SVR_P2040 << 8) | 0x11,/* P2040 1.1 */
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 48ecffe..600704c 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -27,9 +27,9 @@
#include
#include
#include
+#include
#include
-#include
#include
#define DRV_NAME "mpc-i2c"
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355f..af8fb27 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -21,11 +21,10 @@
#include "fsl_pamu.h"
#include
+#include
#include
#include
-#include
-
/* define indexes for each operation mapping scenario */
#define OMI_QMAN0x00
#define OMI_FMAN0x01
diff --git a/drivers/net/ethernet/freescale/gianfar.c
b/drivers/net/ethernet/freescale/gianfar.c
index d2f917a..2224b10 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -86,11 +86,11 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_PPC
#include
-#include
#endif
#include
#include
diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
similarity index 97%
rename from arch/powerpc/include/asm/mpc85xx.h
rename to include/linux/fsl/svr.h
index 213f3a8..8d13836 100644
--- a/arch/powerpc/include/asm/mpc85xx.h
+++ b/include/linux/fsl/svr.h
@@ -9,8 +9,8 @@
* (at your option) any later version.
*/
-#ifndef __ASM_PPC_MPC85XX_H
-#define __ASM_PPC_MPC85XX_H
+#ifndef FSL_SVR_H
+#define FSL_SVR_H
#define SVR_REV(svr) ((svr) & 0xFF) /* SOC design resision */
#define SVR_MAJ(svr) (((svr) >> 4) & 0xF) /* Major revision field*/
--
2.1.0.27.g96db324
[v8, 6/7] MAINTAINERS: add entry for Freescale SoC specific driver
Add maintainer entry for Freescale SoC specific driver including the QE library and the GUTS driver. Also add entry for GUTS driver and add maintainer for QE library. Signed-off-by: Yangbo Lu --- Changes for v8: - Added this patch --- MAINTAINERS | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1d5b4be..d20aeb6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4622,13 +4622,27 @@ F: drivers/net/ethernet/freescale/fec_ptp.c F: drivers/net/ethernet/freescale/fec.h F: Documentation/devicetree/bindings/net/fsl-fec.txt +FREESCALE SOC SPECIFIC DRIVER +M: Scott Wood +L: linuxppc-...@lists.ozlabs.org +S: Maintained +F: drivers/soc/fsl/ +F: include/linux/fsl/ + FREESCALE QUICC ENGINE LIBRARY +M: Qiang Zhao L: linuxppc-...@lists.ozlabs.org -S: Orphan +S: Maintained F: drivers/soc/fsl/qe/ F: include/soc/fsl/*qe*.h F: include/soc/fsl/*ucc*.h +FREESCALE GUTS DRIVER +M: Yangbo Lu +L: linuxppc-...@lists.ozlabs.org +S: Maintained +F: drivers/soc/fsl/guts.c + FREESCALE USB PERIPHERAL DRIVERS M: Li Yang L: linux-...@vger.kernel.org -- 2.1.0.27.g96db324
[v8, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
The eSDHC of T4240-R1.0-R2.0 has incorrect vender version and spec version.
Acturally the right version numbers should be VVN=0x13 and SVN = 0x1.
This patch adds the GUTS driver support for eSDHC driver to get SVR(System
version register). And fix host version to avoid that incorrect version
numbers break down the ADMA data transfer.
Signed-off-by: Yangbo Lu
Acked-by: Ulf Hansson
Acked-by: Scott Wood
---
Changes for v2:
- Got SVR through iomap instead of dts
Changes for v3:
- Managed GUTS through syscon instead of iomap in eSDHC driver
Changes for v4:
- Got SVR by GUTS driver instead of SYSCON
Changes for v5:
- Changed to get SVR through API fsl_guts_get_svr()
- Combined patch 4, patch 5 and patch 6 into one
Changes for v6:
- Added 'Acked-by: Ulf Hansson'
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
---
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index e657af0..d480742 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -143,6 +143,7 @@ config MMC_SDHCI_OF_ESDHC
depends on MMC_SDHCI_PLTFM
depends on PPC || ARCH_MXC || ARCH_LAYERSCAPE
select MMC_SDHCI_IO_ACCESSORS
+ select FSL_GUTS
help
This selects the Freescale eSDHC controller support.
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d35..68cc020 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -28,6 +30,8 @@
struct sdhci_esdhc {
u8 vendor_ver;
u8 spec_ver;
+ u32 soc_ver;
+ u8 soc_rev;
};
/**
@@ -73,6 +77,8 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
static u16 esdhc_readw_fixup(struct sdhci_host *host,
int spec_reg, u32 value)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
@@ -80,6 +86,13 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
ret = value & 0x;
else
ret = (value >> shift) & 0x;
+
+ /* Workaround for T4240-R1.0-R2.0 eSDHC which has incorrect
+* vendor version and spec version information.
+*/
+ if ((spec_reg == SDHCI_HOST_VERSION) &&
+ (esdhc->soc_ver == SVR_T4240) && (esdhc->soc_rev <= 0x20))
+ ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
return ret;
}
@@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device *pdev,
struct sdhci_host *host)
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
u16 host_ver;
+ u32 svr;
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
+ fsl_guts_init();
+ svr = fsl_guts_get_svr();
+ if (svr) {
+ esdhc->soc_ver = SVR_SOC_VER(svr);
+ esdhc->soc_rev = SVR_REV(svr);
+ } else {
+ dev_err(&pdev->dev, "Failed to get SVR value!\n");
+ }
+
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
--
2.1.0.27.g96db324
[v8, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds GUTS driver to manage and access global utilities
block.
Signed-off-by: Yangbo Lu
Acked-by: Scott Wood
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified copyright info
- Changed MODULE_LICENSE to GPL
- Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
- Made FSL_GUTS user-invisible
- Added a complete compatible list for GUTS
- Stored guts info in file-scope variable
- Added mfspr() getting SVR
- Redefined GUTS APIs
- Called fsl_guts_init rather than using platform driver
- Removed useless parentheses
- Removed useless 'extern' key words
Changes for v6:
- Made guts thread safe in fsl_guts_init
Changes for v7:
- Removed 'ifdef' for function declaration in guts.h
Changes for v8:
- Fixes lines longer than 80 characters checkpatch issue
- Added 'Acked-by: Scott Wood'
---
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 +++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119
include/linux/fsl/guts.h | 126 +--
5 files changed, 207 insertions(+), 49 deletions(-)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0..7106463 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/bcm/Kconfig"
source "drivers/soc/brcmstb/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 000..b313759
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,8 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+ bool
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307f..02afb7f 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 000..fa155e6
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,119 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct guts {
+ struct ccsr_guts __iomem *regs;
+ bool little_endian;
+};
+
+static struct guts *guts;
+static DEFINE_MUTEX(guts_lock);
+
+u32 fsl_guts_get_svr(void)
+{
+ u32 svr = 0;
+
+ if (!guts || !guts->regs) {
+#ifdef CONFIG_PPC
+ svr = mfspr(SPRN_SVR);
+#endif
+ return svr;
+ }
+
+ if (guts->little_endian)
+ svr = ioread32(&guts->regs->svr);
+ else
+ svr = ioread32be(&guts->regs->svr);
+
+ return svr;
+}
+EXPORT_SYMBOL(fsl_guts_get_svr);
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id guts_of_match[] = {
+ /* For T4 & B4 Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-1.0", },
+ /* For P Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-2.0", },
+ { .compatible = "fsl,p1010-guts", },
+ { .compatible = "fsl,p1020-guts", },
+ { .compatible = "fsl,p1021-guts", },
+ { .compatible = "fsl,p1022-guts", },
+ { .compatible = "fsl,p1023-guts", },
+ { .compatible = "fsl,p2020-guts", },
+ /* For BSC Series SOCs */
+ { .compatible = "fsl,bsc9131-guts", },
+ { .compatible = "fsl,bsc9132-guts", },
+ /* For MPC85xx Series SOCs */
+ { .compatible = "fsl,mpc8536-guts", },
+ { .compatible = "fsl,mpc8544-guts", },
+ { .compatible = "fsl,mpc8548-guts", },
+ { .compatible = "fsl,mpc8568-guts", },
+ { .compatible = "fsl,mpc8569-guts", },
+ { .compatible = "fsl,mpc8572-guts", },
+ /* For Layerscape Series SOCs */
+ { .compatible = "fsl,ls1021a-dcfg", },
+ { .compatible = "fsl,ls1043a-dcfg", },
+ { .compatible = "fsl,ls2080a-dcfg", },
+
[v8, 1/7] Documentation: DT: update Freescale DCFG compatible
Update Freescale DCFG compatible with 'fsl,-dcfg' instead of 'fsl,ls1021a-dcfg' to include more chips. Signed-off-by: Yangbo Lu --- Changes for v8: - Added this patch --- Documentation/devicetree/bindings/arm/fsl.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt index 752a685..1d5f512 100644 --- a/Documentation/devicetree/bindings/arm/fsl.txt +++ b/Documentation/devicetree/bindings/arm/fsl.txt @@ -119,7 +119,7 @@ Freescale DCFG configuration and status for the device. Such as setting the secondary core start address and release the secondary core from holdoff and startup. Required properties: - - compatible: should be "fsl,ls1021a-dcfg" + - compatible: should be "fsl,-dcfg" - reg : should contain base address and length of DCFG memory-mapped registers Example: -- 2.1.0.27.g96db324
[PATCH v4 3/3] dmaengine: vdma: Add clock support
Added basic clock support for axi dma's.
The clocks are requested at probe and released at remove.
Reviewed-by: Shubhrajyoti Datta
Signed-off-by: Kedareswara rao Appana
---
Changes for v4:
---> Documented struct members as suggested by Soren.
---> Fixed required clock according to binding but a failure is ignored
in the cdma case as suggested by Soren.
---> Removed unnecessary IS_ERR checks during disabling the clocks.
Changes for v3:
---> Added clock support for all the AXI DMA's.
---> Fixed clk_unprepare leak during probe fail as suggested by Moritz.
---> Fixed comment driver specifically asks for the clocks it needs and return
an error if a mandatory clock is missing as suggested by soren.
Changes for v2:
---> None.
drivers/dma/xilinx/xilinx_vdma.c | 226 ++-
1 file changed, 224 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 255cdca..51c633f 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include "../dmaengine.h"
@@ -344,6 +345,9 @@ struct xilinx_dma_chan {
struct dma_config {
enum xdma_ip_type dmatype;
+ int (*clk_init)(struct platform_device *pdev, struct clk **axi_clk,
+ struct clk **tx_clk, struct clk **txs_clk,
+ struct clk **rx_clk, struct clk **rxs_clk);
};
/**
@@ -355,7 +359,13 @@ struct dma_config {
* @has_sg: Specifies whether Scatter-Gather is present or not
* @flush_on_fsync: Flush on frame sync
* @ext_addr: Indicates 64 bit addressing is supported by dma device
+ * @pdev: Platform device structure pointer
* @dma_config: DMA config structure
+ * @axi_clk: DMA Axi4-lite interace clock
+ * @tx_clk: DMA mm2s clock
+ * @txs_clk: DMA mm2s stream clock
+ * @rx_clk: DMA s2mm clock
+ * @rxs_clk: DMA s2mm stream clock
*/
struct xilinx_dma_device {
void __iomem *regs;
@@ -365,7 +375,13 @@ struct xilinx_dma_device {
bool has_sg;
u32 flush_on_fsync;
bool ext_addr;
+ struct platform_device *pdev;
const struct dma_config *dma_config;
+ struct clk *axi_clk;
+ struct clk *tx_clk;
+ struct clk *txs_clk;
+ struct clk *rx_clk;
+ struct clk *rxs_clk;
};
/* Macros */
@@ -1757,6 +1773,195 @@ static void xilinx_dma_chan_remove(struct
xilinx_dma_chan *chan)
list_del(&chan->common.device_node);
}
+static int axidma_clk_init(struct platform_device *pdev, struct clk **axi_clk,
+ struct clk **tx_clk, struct clk **rx_clk,
+ struct clk **sg_clk, struct clk **tmp_clk)
+{
+ int err;
+
+ *tmp_clk = NULL;
+
+ *axi_clk = devm_clk_get(&pdev->dev, "s_axi_lite_aclk");
+ if (IS_ERR(*axi_clk)) {
+ err = PTR_ERR(*axi_clk);
+ dev_err(&pdev->dev, "failed to get axi_aclk (%u)\n", err);
+ return err;
+ }
+
+ *tx_clk = devm_clk_get(&pdev->dev, "m_axi_mm2s_aclk");
+ if (IS_ERR(*tx_clk))
+ *tx_clk = NULL;
+
+ *rx_clk = devm_clk_get(&pdev->dev, "m_axi_s2mm_aclk");
+ if (IS_ERR(*rx_clk))
+ *rx_clk = NULL;
+
+ *sg_clk = devm_clk_get(&pdev->dev, "m_axi_sg_aclk");
+ if (IS_ERR(*sg_clk))
+ *sg_clk = NULL;
+
+ err = clk_prepare_enable(*axi_clk);
+ if (err) {
+ dev_err(&pdev->dev, "failed to enable axi_clk (%u)\n", err);
+ return err;
+ }
+
+ err = clk_prepare_enable(*tx_clk);
+ if (err) {
+ dev_err(&pdev->dev, "failed to enable tx_clk (%u)\n", err);
+ goto err_disable_axiclk;
+ }
+
+ err = clk_prepare_enable(*rx_clk);
+ if (err) {
+ dev_err(&pdev->dev, "failed to enable rx_clk (%u)\n", err);
+ goto err_disable_txclk;
+ }
+
+ err = clk_prepare_enable(*sg_clk);
+ if (err) {
+ dev_err(&pdev->dev, "failed to enable sg_clk (%u)\n", err);
+ goto err_disable_rxclk;
+ }
+
+ return 0;
+
+err_disable_rxclk:
+ clk_disable_unprepare(*rx_clk);
+err_disable_txclk:
+ clk_disable_unprepare(*tx_clk);
+err_disable_axiclk:
+ clk_disable_unprepare(*axi_clk);
+
+ return err;
+}
+
+static int axicdma_clk_init(struct platform_device *pdev, struct clk **axi_clk,
+ struct clk **dev_clk, struct clk **tmp_clk,
+ struct clk **tmp1_clk, struct clk **tmp2_clk)
+{
+ int err;
+
+ *tmp_clk = NULL;
+ *tmp1_clk = NULL;
+ *tmp2_clk = NULL;
+
+ *axi_clk = devm_clk_get(&pdev->dev, "s_axi_lite_aclk");
+ if (IS_ERR(*axi_clk)) {
+ err = PTR_ERR(*axi_clk);
+ dev_err(&pdev->dev, "failed to get axi_clk (%u)\n", err);
+ return err;
+ }
+
+ *dev_clk = devm_clk_get(
[PATCH v4 2/3] Documentation: DT: vdma: Add clock support for dmas
This patch updates the binding doc with clock description
for AXI DMA's.
Acked-by: Sören Brinkmann
Signed-off-by: Kedareswara rao Appana
---
Changes for v4:
---> None.
Changes for v3:
---> Added clock support for all the AXI DMA's.
Changes for v2:
--> Listed down all the clocks supported by the h/w
as suggested by the Datta.
--> Used IP clock names instead of shortcut clock name
.../devicetree/bindings/dma/xilinx/xilinx_vdma.txt| 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index fcc2b65..a1f2683 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -21,6 +21,18 @@ Required properties:
- dma-channel child node: Should have at least one channel and can have up to
two channels per device. This node specifies the properties of each
DMA channel (see child node properties below).
+- clocks: Input clock specifier. Refer to common clock bindings.
+- clock-names: List of input clocks
+ For VDMA:
+ Required elements: "s_axi_lite_aclk"
+ Optional elements: "m_axi_mm2s_aclk" "m_axi_s2mm_aclk",
+ "m_axis_mm2s_aclk", "s_axis_s2mm_aclk"
+ For CDMA:
+ Required elements: "s_axi_lite_aclk", "m_axi_aclk"
+ FOR AXIDMA:
+ Required elements: "s_axi_lite_aclk"
+ Optional elements: "m_axi_mm2s_aclk", "m_axi_s2mm_aclk",
+ "m_axi_sg_aclk"
Required properties for VDMA:
- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
@@ -60,6 +72,9 @@ axi_vdma_0: axivdma@4003 {
xlnx,num-fstores = <0x8>;
xlnx,flush-fsync = <0x1>;
xlnx,addrwidth = <0x20>;
+ clocks = <&clk 0>, <&clk 1>, <&clk 2>, <&clk 3>, <&clk 4>;
+ clock-names = "s_axi_lite_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk",
+ "m_axis_mm2s_aclk", "s_axis_s2mm_aclk";
dma-channel@4003 {
compatible = "xlnx,axi-vdma-mm2s-channel";
interrupts = < 0 54 4 >;
--
2.1.2
[PATCH v4 0/3] dmaengine: Add clock support for AXI DMAS
This patch series adds basic clock support for AXI DMAS This patch series is created on top of the "dmaengine: vdma: AXI DMA's enhancments" patch series. Kedareswara rao Appana (3): dmaengine: vdma: Add config structure to differentiate dmas Documentation: DT: vdma: Add clock support for dmas dmaengine: vdma: Add clock support .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt | 15 + drivers/dma/xilinx/xilinx_vdma.c | 307 ++--- 2 files changed, 289 insertions(+), 33 deletions(-) -- 2.1.2
[PATCH v4 1/3] dmaengine: vdma: Add config structure to differentiate dmas
This patch adds config structure in the driver to differentiate
AXI DMA's and to add more features(clock support etc..) to these DMA's.
Signed-off-by: Kedareswara rao Appana
---
Changes for v4:
---> None.
Changes for v3:
---> New patch.
drivers/dma/xilinx/xilinx_vdma.c | 83
1 file changed, 51 insertions(+), 32 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 70caea6..255cdca 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -342,6 +342,10 @@ struct xilinx_dma_chan {
void (*start_transfer)(struct xilinx_dma_chan *chan);
};
+struct dma_config {
+ enum xdma_ip_type dmatype;
+};
+
/**
* struct xilinx_dma_device - DMA device structure
* @regs: I/O mapped base address
@@ -351,7 +355,7 @@ struct xilinx_dma_chan {
* @has_sg: Specifies whether Scatter-Gather is present or not
* @flush_on_fsync: Flush on frame sync
* @ext_addr: Indicates 64 bit addressing is supported by dma device
- * @dmatype: DMA ip type
+ * @dma_config: DMA config structure
*/
struct xilinx_dma_device {
void __iomem *regs;
@@ -361,7 +365,7 @@ struct xilinx_dma_device {
bool has_sg;
u32 flush_on_fsync;
bool ext_addr;
- enum xdma_ip_type dmatype;
+ const struct dma_config *dma_config;
};
/* Macros */
@@ -573,12 +577,12 @@ xilinx_dma_free_tx_descriptor(struct xilinx_dma_chan
*chan,
if (!desc)
return;
- if (chan->xdev->dmatype == XDMA_TYPE_VDMA) {
+ if (chan->xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
list_for_each_entry_safe(segment, next, &desc->segments, node) {
list_del(&segment->node);
xilinx_vdma_free_tx_segment(chan, segment);
}
- } else if (chan->xdev->dmatype == XDMA_TYPE_CDMA) {
+ } else if (chan->xdev->dma_config->dmatype == XDMA_TYPE_CDMA) {
list_for_each_entry_safe(cdma_segment, cdma_next,
&desc->segments, node) {
list_del(&cdma_segment->node);
@@ -641,7 +645,7 @@ static void xilinx_dma_free_chan_resources(struct dma_chan
*dchan)
dev_dbg(chan->dev, "Free all channel resources.\n");
xilinx_dma_free_descriptors(chan);
- if (chan->xdev->dmatype == XDMA_TYPE_AXIDMA)
+ if (chan->xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA)
xilinx_dma_free_tx_segment(chan, chan->seg_v);
dma_pool_destroy(chan->desc_pool);
chan->desc_pool = NULL;
@@ -711,13 +715,13 @@ static int xilinx_dma_alloc_chan_resources(struct
dma_chan *dchan)
* We need the descriptor to be aligned to 64bytes
* for meeting Xilinx VDMA specification requirement.
*/
- if (chan->xdev->dmatype == XDMA_TYPE_AXIDMA) {
+ if (chan->xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
chan->desc_pool = dma_pool_create("xilinx_dma_desc_pool",
chan->dev,
sizeof(struct xilinx_axidma_tx_segment),
__alignof__(struct xilinx_axidma_tx_segment),
0);
- } else if (chan->xdev->dmatype == XDMA_TYPE_CDMA) {
+ } else if (chan->xdev->dma_config->dmatype == XDMA_TYPE_CDMA) {
chan->desc_pool = dma_pool_create("xilinx_cdma_desc_pool",
chan->dev,
sizeof(struct xilinx_cdma_tx_segment),
@@ -738,7 +742,7 @@ static int xilinx_dma_alloc_chan_resources(struct dma_chan
*dchan)
return -ENOMEM;
}
- if (chan->xdev->dmatype == XDMA_TYPE_AXIDMA)
+ if (chan->xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA)
/*
* For AXI DMA case after submitting a pending_list, keep
* an extra segment allocated so that the "next descriptor"
@@ -751,7 +755,7 @@ static int xilinx_dma_alloc_chan_resources(struct dma_chan
*dchan)
dma_cookie_init(dchan);
- if (chan->xdev->dmatype == XDMA_TYPE_AXIDMA) {
+ if (chan->xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
/* For AXI DMA resetting once channel will reset the
* other channel as well so enable the interrupts here.
*/
@@ -759,7 +763,7 @@ static int xilinx_dma_alloc_chan_resources(struct dma_chan
*dchan)
XILINX_DMA_DMAXR_ALL_IRQ_MASK);
}
- if ((chan->xdev->dmatype == XDMA_TYPE_CDMA) && chan->has_sg)
+ if ((chan->xdev->dma_config->dmatype == XDMA_TYPE_CDMA) && chan->has_sg)
dma_ctrl_set(chan, XILINX_DMA_REG_DMACR,
XILINX_CDMA_CR_SGMODE);
@@ -790,7 +794,7 @@ static enum dma_status xilinx_dma_tx_status(struct dma_chan
*dchan,
if (ret == DMA_COMPLETE || !txstate)
Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
On Wed, Apr 20, 2016 at 10:03:34AM +0300, Roger Quadros wrote:
> On 20/04/16 08:08, Yoshihiro Shimoda wrote:
> > Hi,
> >
> >> From: Peter Chen
> >> Sent: Tuesday, April 19, 2016 6:18 PM
> >>
> >> On Fri, Apr 15, 2016 at 10:03:16AM +, Yoshihiro Shimoda wrote:
> >>> Hi,
> >>>
> From: Yoshihiro Shimoda
> Sent: Friday, April 15, 2016 6:59 PM
>
> Hi,
>
> > From: Roger Quadros
> > Sent: Thursday, April 14, 2016 8:32 PM
> >
> > On 14/04/16 14:15, Yoshihiro Shimoda wrote:
> >> Hi,
> >>
> < snip >
> @@ -865,7 +867,8 @@ int usb_otg_register_hcd(struct usb_hcd *hcd,
> unsigned int irqnum,
> * we're ready only if we have shared HCD
> * or we don't need shared HCD.
> */
> -if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
> +if (otg->shared_hcd.hcd || (!otg->caps->needs_companion &&
> +!otg->primary_hcd.hcd->shared_hcd))
> {
> otg->host = hcd_to_bus(hcd);
> /* FIXME: set bus->otg_port if this is true OTG port
> with HNP */
>
> >>>
> >>> These changes look good to me. Thanks.
> >>
> >> Thank you for the comment.
> >> If we change the "needs_companion" place to the otg_config,
> >> do we need to add a flag into the otg, instead of otg->caps?
> >
> > Yes we can add a flag in struct usb_otg.
>
> Thank you for the comment.
>
> I made a fixed patch.
> So, should I send this patch to ML after you sent v7 patches?
> Or, would you apply this patch before you send v7 patches?
> >>>
> >>> Oops, I sent this email without my patch...
> >>>
> >>> ---
> >>> Subject: [PATCH] usb: otg: add hcd companion support
> >>>
> >>> Since some host controller (e.g. EHCI) needs a companion host controller
> >>> (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> >>> core.
> >>>
> >>> Signed-off-by: Yoshihiro Shimoda
> >>> ---
> >>> Documentation/devicetree/bindings/usb/generic.txt | 3 +++
> >>> drivers/usb/common/usb-otg.c | 17 +
> >>> include/linux/usb/otg.h | 7 ++-
> >>> 3 files changed, 22 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/usb/generic.txt
> >>> b/Documentation/devicetree/bindings/usb/generic.txt
> >>> index f6866c1..1db1c33 100644
> >>> --- a/Documentation/devicetree/bindings/usb/generic.txt
> >>> +++ b/Documentation/devicetree/bindings/usb/generic.txt
> >>> @@ -27,6 +27,9 @@ Optional properties:
> >>> - otg-controller: phandle to otg controller. Host or gadget controllers
> >>> can
> >>> contain this property to link it to a particular OTG
> >>> controller.
> >>> + - hcd-needs-companion: must be present if otg controller is dealing with
> >>> + EHCI host controller that needs a companion OHCI host
> >>> + controller.
> >>>
> >>> This is an attribute to a USB controller such as:
> >>>
> >>> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> >>> index 41e762a..83c8c96 100644
> >>> --- a/drivers/usb/common/usb-otg.c
> >>> +++ b/drivers/usb/common/usb-otg.c
> >>> @@ -20,6 +20,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>> +#include
> >>> #include
> >>> #include
> >>> #include
> >>> @@ -600,6 +601,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
> >>> else
> >>> INIT_WORK(&otg->work, usb_otg_work);
> >>>
> >>> + if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
> >>> + config->hcd_needs_companion)/* needs comanion ? */
> >>
> >> %s/comanion/companion
> >
> > Thank you for pointing it out!
> >
> > Roger, would you fix this in your v7 patch set?
>
> Yes, I'll fix it locally. You don't need to post it again.
>
Roger, I am ok with this patch.
Acked-by: Peter Chen
Peter
> --
> cheers,
> -roger
>
> >
> >> I have a little puzzled with companion controller and shared hcd, let me
> >> post a topic for it.
> >
> > I looked at the email thread.
> > It is very useful information to me! :)
> >
> > Best regards,
> > Yoshihiro Shimoda
> >
> >> Peter
> >>
> >>> + otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
> >>> +
> >>> otg->wq = create_singlethread_workqueue("usb_otg");
> >>> if (!otg->wq) {
> >>> dev_err(dev, "otg: %s: can't create workqueue\n",
> >>> @@ -823,13 +828,15 @@ int usb_otg_register_hcd(struct usb_hcd *hcd,
> >>> unsigned int irqnum,
> >>> /* HCD will be started by OTG fsm when needed */
> >>> mutex_lock(&otg->fsm.lock);
> >>> if (otg->primary_hcd.hcd) {
> >>> - /* probably a shared HCD ? */
> >>> - if (usb_otg_hcd_is_primary_hcd(hcd)) {
> >>> + /* probably a shared HCD or a companion OHCI HCD ? */
> >>> + if (!(otg->flags & OTG_FL
RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
Hi,
> From: Peter Chen
> Sent: Friday, April 22, 2016 12:34 PM
>
> On Fri, Apr 22, 2016 at 09:26:46AM +0800, Peter Chen wrote:
> > On Fri, Apr 15, 2016 at 10:03:16AM +, Yoshihiro Shimoda wrote:
> > > Hi,
> > >
> > > > From: Yoshihiro Shimoda
> > > > Sent: Friday, April 15, 2016 6:59 PM
> > > >
> > > > Hi,
> > > >
> > > > > From: Roger Quadros
> > > > > Sent: Thursday, April 14, 2016 8:32 PM
> > > > >
> > > > > On 14/04/16 14:15, Yoshihiro Shimoda wrote:
> > > > > > Hi,
> > > > > >
> > > > < snip >
> > > > > >>> @@ -865,7 +867,8 @@ int usb_otg_register_hcd(struct usb_hcd *hcd,
> > > > > >>> unsigned int irqnum,
> > > > > >>>* we're ready only if we have shared HCD
> > > > > >>>* or we don't need shared HCD.
> > > > > >>>*/
> > > > > >>> - if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
> > > > > >>> + if (otg->shared_hcd.hcd || (!otg->caps->needs_companion &&
> > > > > >>> + !otg->primary_hcd.hcd->shared_hcd))
> > > > > >>> {
> > > > > >>> otg->host = hcd_to_bus(hcd);
> > > > > >>> /* FIXME: set bus->otg_port if this is true OTG port
> > > > > >>> with HNP */
> > > > > >>>
> > > > > >>
> > > > > >> These changes look good to me. Thanks.
> > > > > >
> > > > > > Thank you for the comment.
> > > > > > If we change the "needs_companion" place to the otg_config,
> > > > > > do we need to add a flag into the otg, instead of otg->caps?
> > > > >
> > > > > Yes we can add a flag in struct usb_otg.
> > > >
> > > > Thank you for the comment.
> > > >
> > > > I made a fixed patch.
> > > > So, should I send this patch to ML after you sent v7 patches?
> > > > Or, would you apply this patch before you send v7 patches?
> > >
> > > Oops, I sent this email without my patch...
> > >
> > > ---
> > > Subject: [PATCH] usb: otg: add hcd companion support
> > >
> > > Since some host controller (e.g. EHCI) needs a companion host controller
> > > (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> > > core.
> > >
> > > Signed-off-by: Yoshihiro Shimoda
> > > ---
> > > Documentation/devicetree/bindings/usb/generic.txt | 3 +++
> > > drivers/usb/common/usb-otg.c | 17 +
> > > include/linux/usb/otg.h | 7 ++-
> > > 3 files changed, 22 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/generic.txt
> > > b/Documentation/devicetree/bindings/usb/generic.txt
> > > index f6866c1..1db1c33 100644
> > > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > @@ -27,6 +27,9 @@ Optional properties:
> > > - otg-controller: phandle to otg controller. Host or gadget controllers
> > > can
> > > contain this property to link it to a particular OTG
> > > controller.
> > > + - hcd-needs-companion: must be present if otg controller is dealing with
> > > + EHCI host controller that needs a companion OHCI host
> > > + controller.
> > >
> > > This is an attribute to a USB controller such as:
> > >
> > > diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> > > index 41e762a..83c8c96 100644
> > > --- a/drivers/usb/common/usb-otg.c
> > > +++ b/drivers/usb/common/usb-otg.c
> > > @@ -20,6 +20,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -600,6 +601,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
> > > else
> > > INIT_WORK(&otg->work, usb_otg_work);
> > >
> > > + if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
> > > + config->hcd_needs_companion)/* needs comanion ? */
> > > + otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
> > > +
> > > otg->wq = create_singlethread_workqueue("usb_otg");
> > > if (!otg->wq) {
> > > dev_err(dev, "otg: %s: can't create workqueue\n",
> > > @@ -823,13 +828,15 @@ int usb_otg_register_hcd(struct usb_hcd *hcd,
> > > unsigned int irqnum,
> > > /* HCD will be started by OTG fsm when needed */
> > > mutex_lock(&otg->fsm.lock);
> > > if (otg->primary_hcd.hcd) {
> > > - /* probably a shared HCD ? */
> > > - if (usb_otg_hcd_is_primary_hcd(hcd)) {
> > > + /* probably a shared HCD or a companion OHCI HCD ? */
> > > + if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
> > > + usb_otg_hcd_is_primary_hcd(hcd)) {
> > > dev_err(otg_dev, "otg: primary host already
> > > registered\n");
> > > goto err;
> > > }
> > >
> > > - if (hcd->shared_hcd == otg->primary_hcd.hcd) {
> > > + if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
> > > + (hcd->shared_hcd == otg->primary_hcd.hcd)) {
> > > if (otg->shared_hcd.hcd) {
> > > dev_err(otg_dev, "otg: shared host alr
[PATCH RESEND v2 3/4] ARM64: dts: rockchip: add RK3399 evaluation board
The RK3399 evaluation board is designed with pmic rk808 on top board. Signed-off-by: Jianqun Xu --- changes in v2: - new add patch Documentation/devicetree/bindings/arm/rockchip.txt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt index 2549519..6491b56 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.txt +++ b/Documentation/devicetree/bindings/arm/rockchip.txt @@ -101,4 +101,8 @@ Rockchip platforms device tree bindings - Rockchip RK3228 Evaluation board: Required root node properties: - - compatible = "rockchip,rk3228-evb", "rockchip,rk3228"; + - compatible = "rockchip,rk3228-evb", "rockchip,rk3228"; + +- Rockchip RK3399 evb: +Required root node properties: + - compatible = "rockchip,rk3399-evb", "rockchip,rk3399"; -- 1.9.1
[PATCH RESEND v2 4/4] ARM64: dts: rockchip: add dts file for RK3399 evaluation board
This patch add rk3399-evb.dts for RK3399 evaluation board.
Tested on RK3399 evb.
Signed-off-by: Jianqun Xu
---
changes in v2:
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently
- fix codingstyle issues
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 122
2 files changed, 123 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index df37865..7037a16 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,6 +1,7 @@
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
new file mode 100644
index 000..309f870
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -0,0 +1,122 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include
+#include "rk3399.dtsi"
+
+/ {
+ compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
+
+ vdd_center: vdd-center {
+ compatible = "pwm-regulator";
+ pwms = <&pwm3 0 25000 0>;
+ regulator-name = "vdd_center";
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <140>;
+ regulator-always-on;
+ regulator-boot-on;
+ status = "okay";
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ vcc_phy: vcc-phy-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_phy";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+};
+
+&pwm0 {
+ status = "okay";
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&pwm3 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&pinctrl {
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins =
+ <1 21 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ pmic_dvs2: pmic-dvs2 {
+ rockchip,pins =
+ <1 18
[PATCH RESEND v2 2/4] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs
This patch adds core dtsi file for Rockchip RK3399 SoCs.
The RK3399 has big/little architecture, which needs a separate
node for the PMU of each microarchitecture, for now it missing
the pmu node since the old one could not work well.
Marc is working on it with:
https://lkml.org/lkml/2016/4/11/182
and on the following branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
irq/percpu-partition
That will to be tested on RK3399 evb.
Signed-off-by: Jianqun Xu
---
changes in v2:
- remove arm-pmu at first. (Marc, Heiko, Mark)
- remove rga, emmc, usb3, mipi, edp, pd, i2c, gpu, thermal, tsadc, saradc,
which will upstream independently
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1022 ++
1 file changed, 1022 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 000..5a8a915
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,1022 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/ {
+ compatible = "rockchip,rk3399";
+
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ serial4 = &uart4;
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu_l0>;
+ };
+ core1 {
+ cpu = <&cpu_l1>;
+ };
+ core2 {
+ cpu = <&cpu_l2>;
+ };
+ core3 {
+ cpu = <&cpu_l3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu_b0>;
+ };
+ core1 {
+ cpu = <&cpu_b1>;
+ };
+ };
+ };
+
+ cpu_l0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ #cooling-cells = <2>; /* min followed by max */
+ cl
[PATCH RESEND v2 1/4] Documentation: rockchip-dw-mshc: add description for rk3399
From: Shawn Lin Add "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc" for dwmmc on rk3399 platform. Change-Id: Ieefafab5f0e9650271e823659e2bec1556c4a9bc Signed-off-by: Shawn Lin --- changes in v2: - new add patch Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt index ea5614b..07184e8 100644 --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt @@ -15,6 +15,7 @@ Required Properties: - "rockchip,rk3288-dw-mshc": for Rockchip RK3288 - "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3036 - "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3368 + - "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3399 Optional Properties: * clocks: from common clock binding: if ciu_drive and ciu_sample are -- 1.9.1
[PATCH RESEND v2 0/4] ARM64: dts: rockchip: add support for RK3399
Add dtsi file for RK3399 SoCs, and evb dts file for RK3399 evb. To make patch more easily to be reviewed, some nodes have been removed temporarily, after this base file been applied, more patches will be upstreamed independently. Jianqun Xu (3): ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs ARM64: dts: rockchip: add RK3399 evaluation board ARM64: dts: rockchip: add dts file for RK3399 evaluation board Shawn Lin (1): Documentation: rockchip-dw-mshc: add description for rk3399 Documentation/devicetree/bindings/arm/rockchip.txt |6 +- .../devicetree/bindings/mmc/rockchip-dw-mshc.txt |1 + arch/arm64/boot/dts/rockchip/Makefile |1 + arch/arm64/boot/dts/rockchip/rk3399-evb.dts| 122 +++ arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1022 5 files changed, 1151 insertions(+), 1 deletion(-) create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi -- changes in v2: - split into more patches. (Heiko) - remove arm-pmu at first. (Marc, Heiko, Mark) - remove rga, emmc, usb3, mipi, edp, pd, i2c, gpu, thermal, tsadc, saradc, which will upstream independently - remove rk808 since without i2c, which will upstream independently - remove es8316 since without i2c, which will upstream independently - add rockchip-dw-mshc binding patch - add rockchip,rk3399-evb binding patch - fix codingstyle issues 1.9.1
[PATCH] usb: core: Do not use sizeof on pointer type
When sizeof is applied to a pointer typed expression, it gives the size of the pointer. So, do not use sizeof on pointer type. Problem found using Coccinelle. Signed-off-by: Vaishali Thakkar --- drivers/usb/core/hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index 2ca2cef..2aa352d 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -1386,7 +1386,7 @@ static int hcd_alloc_coherent(struct usb_bus *bus, return -EFAULT; } - vaddr = hcd_buffer_alloc(bus, size + sizeof(vaddr), + vaddr = hcd_buffer_alloc(bus, size + sizeof(*vaddr), mem_flags, dma_handle); if (!vaddr) return -ENOMEM; -- 2.1.4
Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver
On Thursday 21 April 2016 05:48 PM, Alexey Brodkin wrote:
> Hi Jose,
>
> On Thu, 2016-04-21 at 10:51 +0100, Jose Abreu wrote:
>> Hi Alexey,
>
>
> Otherwise, I still prefer two DTS files for the two different FPGA
> versions. At the least, please use ioremap for any pointers that
> you readl/writel here.
>
> Beyond that, we should have a fixed rate source clk somewhere in
> the software view of the clk tree, because that reflects reality.
> Hardcoding the parent rate in the structure works, but doesn't
> properly express the clk tree.
>
Can I use a property in the DT to pass this reference clock? something
like this:
snps,parent-freq = <0xFBED9 2700>, <0x0 28224000>; /* Tuple
, fpga-version = 0 is default */
Or use a parent clock? like:
clk {
compatible = "fixed-clock";
clock-frequency = <2700>;
#clock-cells = <0>;
snps,fpga-version = <0xFBED9>;
}
It is important to distinguish between the different versions
automatically, is
any of these solutions ok?
>>> I do like that solution with a master clock but with some fine-tuning
>>> for simplification.
>>>
>>> We'll add master clock node for I2S as a fixed clock like that:
>>> --->8--
>>> i2s_master_clock: clk {
>>> #clock-cells = <0>;
>>> compatible = "fixed-clock";
>>> clock-frequency = <2700>;
>>> };
>>> --->8--
>>>
>>> Note there's no mention of MB version, just a value of the frequency.
>>> And in the driver itself value of that master clock will be used for
>>> population of "pll_clk->ref_clk" directly.
>>>
>>> These are benefits we'll get with that approach:
>>> [1] We escape any IOs not related to our clock device (I mean
>>> "snps,i2s-pll-clock") itself.
>>> [2] We'll use whatever reference clock value is given.
>>> I.e. we'll be able to do a fix-up of that reference clock
>>> value early in platform code depending on HW we're running on.
>>> That's what people do here and there.
>>> [3] Remember another clock driver for AXS10x board is right around
>>> the corner. I mean the one for ARC PGU which uses exactly the same
>>> master clock. So one fixup as mentioned above will work
>>> at once for 2 clock drivers.
>>>
>>> Let me know if above makes sense.
>> That approach can't be used because the reference clock value will change in
>> the
>> next firmware release. The new release will have a reference clock of
>> 28224000
>> Hz instead of the usual 2700 Hz, so we need to have a way to distinguish
>> between them. Because of that we can't have only one master clock unless you
>> state to users that they have to change the reference clock value when using
>> the
>> new firmware release. Stephen suggested to use two DT files (one for each
>> firmware release), but as Vineet said this would be annoying to the user so
>> I am
>> trying to use another solution so that only one DT file is required.
>
> Ok reference clock will change.
> But I may guess we'll still be able to determine at least that new
> firmware version in run-time, right? If so we'll update a fix-up in
> early axs10x platform code so that reference clock will be set as 28224000 Hz.
Please no - lets not bolt-in more hacks and instead try do this cleanly if
possible. And from other discusions it seems there might be a way. The readl
approach seems fine to me (with ioremap) if that is what it takes.
> And indeed 2 DT files is a no go - we want to run the same one binary
> (with built-in .dtb) on all flavors of AXS boards.
Right - 2 DT is not acceptable unless we are feeling bored and want more emails
for AXS board support :-)
And fix-up I'm talking about
> will actually do transformation of .dtb early on kernel boot process so that
> will
> be a complete equivalent of different DT files.
>
> -Alexey--
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: [PATCH 7/9] thermal: of: Add support for hardware-tracked trip points
On Fri, Apr 22, 2016 at 09:54:19AM +0800, Caesar Wang wrote:
> Hi Brian, Eduardo, Sascha
>
> 在 2016年04月21日 09:12, Brian Norris 写道:
> >+ Sascha
> >
> >On Wed, Apr 20, 2016 at 04:48:18PM -0700, Eduardo Valentin wrote:
> >>On Mon, Apr 18, 2016 at 11:35:59AM +0800, Caesar Wang wrote:
> >>>From: Mikko Perttunen
> >>>
> >>>This adds support for hardware-tracked trip points to the device tree
> >>
> >>
> >>>diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> >>>index 97b86c5..6ef932a 100644
> >>>--- a/include/linux/thermal.h
> >>>+++ b/include/linux/thermal.h
> >>>@@ -335,12 +335,14 @@ struct thermal_genl_event {
> >>> * @get_trend: a pointer to a function that reads the sensor temperature
> >>> trend.
> >>> * @set_emul_temp: a pointer to a function that sets sensor emulated
> >>> * temperature.
> >>>+ * @set_trips: a pointer to a function that set low/high trip temperature.
> >>> */
> >>> struct thermal_zone_of_device_ops {
> >>> int (*get_temp)(void *, int *);
> >>> int (*get_trend)(void *, long *);
> >>> int (*set_emul_temp)(void *, int);
> >>> int (*set_trip_temp)(void *, int, int);
> >>>+ int (*set_trips)(void *, int, int);
> >>This is unfortunately a diverges from API available on thermal core. Can
> >>you please add first on thermal core then, use it in of thermal?
> >>
> >>I don't want to have callbacks available only via of thermal. If we
> >>allow it, OF thermal becomes a separate API.
> >What ever happened to this effort?
> >
> >http://thread.gmane.org/gmane.linux.power-management.general/59451
> >
> >Patch 12 and 13 look to accomplish something similar, yet they do what
> >Eduardo suggested. I was testing that series at my previous job, but
> >unfortunately (for the fate of this series) I left that employer before
> >I could finish reviewing and testing it. Perhaps Caesar can resurrect
> >and test it?
>
> @Brian
> Yes, I can
>
> Sure, I can.
>
> I see the Sascha's newest thermal patches in patchwork.
> The following patches are still needed, right?
>
> 6446191 New [06/16] thermal: inline only once used function
> 6446111 New [07/16] thermal: streamline get_trend callbacks
> 6445871 New [08/16] thermal: Allow sensor ops to fail with -ENOSYS
> 6445861 New [09/16] thermal: of: always set sensor related
> callbacks
> 6446221 New [10/16] thermal: Make struct thermal_zone_device_ops
> const
> 6446201 New [11/16] thermal: bang-bang governor: act on lower trip
> boundary
> 6445891 New [12/16] thermal: thermal: Add support for
> hardware-tracked trip points
> 6445911 New [13/16] thermal: of: implement .set_trips for device
> tree thermal zones
>
> @Sascha, Eduardo
> Can you share your discussion content for the above patches as remembered?
These are still the newest patches. I won't have any resources in the
near future for continuing the work on them, so feel free to pick them
up. There hasn't been much discussion around these patches which was the
reason I abandoned them.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH v2 4/4] ARM64: dts: rockchip: add dts file for RK3399 evaluation board
This patch add rk3399-evb.dts for RK3399 evaluation board.
Tested on RK3399 evb.
Signed-off-by: Jianqun Xu
---
changes in v2:
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently
- fix codingstyle issues
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 122
2 files changed, 123 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index df37865..7037a16 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,6 +1,7 @@
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
new file mode 100644
index 000..309f870
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -0,0 +1,122 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include
+#include "rk3399.dtsi"
+
+/ {
+ compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
+
+ vdd_center: vdd-center {
+ compatible = "pwm-regulator";
+ pwms = <&pwm3 0 25000 0>;
+ regulator-name = "vdd_center";
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <140>;
+ regulator-always-on;
+ regulator-boot-on;
+ status = "okay";
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ vcc_phy: vcc-phy-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_phy";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+};
+
+&pwm0 {
+ status = "okay";
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&pwm3 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&pinctrl {
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins =
+ <1 21 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ pmic_dvs2: pmic-dvs2 {
+ rockchip,pins =
+ <1 18
RE: [PATCH v6 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation
Hi Rob,
Thanks for the review...
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Thursday, April 21, 2016 7:12 PM
> To: Appana Durga Kedareswara Rao
> Cc: pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek
> ; Soren Brinkmann ;
> vinod.k...@intel.com; dan.j.willi...@intel.com; Appana Durga Kedareswara
> Rao ; moritz.fisc...@ettus.com;
> laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Anirudha
> Sarangi ; Punnaiah Choudary Kalluri
> ; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> dmaeng...@vger.kernel.org
> Subject: Re: [PATCH v6 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma
> device tree binding documentation
>
> On Fri, Apr 15, 2016 at 02:22:53PM +0530, Kedareswara rao Appana wrote:
> > Device-tree binding documentation for Xilinx zynqmp dma engine used in
> > Zynq UltraScale+ MPSoC.
> >
> > Signed-off-by: Punnaiah Choudary Kalluri
> > Signed-off-by: Kedareswara rao Appana
> > ---
> > Changes in v6:
> > - Removed desc-axi-cache/dst-axi-cache/src-axi-cache properties
> > from the binding doc as it allow broken combinations when dma-coherent
> > is set as suggested by Rob.
> > - Fixed minor comments given by Rob related coding(lower case DT node
> name).
> > Changes in v5:
> > - Use dma-coherent flag for coherent transfers as suggested by rob.
> > - Removed unnecessary properties from binding doc as suggested by Rob.
> > Changes in v4:
> > - None
> > Changes in v3:
> > - None
> > Changes in v2:
> > - None.
> >
> > .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt | 44
> ++
> > 1 file changed, 44 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> >
> > diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> > new file mode 100644
> > index 000..f0f0b54
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> > @@ -0,0 +1,44 @@
> > +Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
> > +memory to device and device to memory transfers. It also has flow
> > +control and rate control support for slave/peripheral dma access.
> > +
> > +Required properties:
> > +- compatible : Should be "xlnx,zynqmp-dma-1.0"
> > +- reg : Memory map for gdma/adma module access.
> > +- interrupt-parent : Interrupt controller the interrupt is routed through
> > +- interrupts : Should contain DMA channel interrupt.
> > +- xlnx,bus-width : Axi buswidth in bits. Should contain 128 or 64
>
> I think how this is getting used by the driver is wrong.
> {src,dst}_addr_widths are supposed to be a bitmask of supported slave
> device register widths. You aren't doing a bitmask and you are also
> saying you only support slaves with 8 or 16 byte data registers which is
> somewhat rare. It may happen to work because 128/8 == BIT(4). However,
> the documentation for the field is contradictory in that it says 1,2,4
> or 8 byte widths are supported, but the enum has more sizes.
The DMA supports an AXI bus width of 128/64 bits only.
Please refer IP data sheet.
http://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
Page No: 359(DMA Over fetch section).
That's why during probe we are making the dma_device supported source and
destination address widths accordingly based on the DT property.
Snap shot of driver code from the probe:
struct dma_device *p;
p->dst_addr_widths = zdev->chan->bus_width / 8;
p->src_addr_widths = zdev->chan->bus_width / 8;
Where bus_width property is read from the probe.
err = of_property_read_u32(node, "xlnx,bus-width", &chan->bus_width)
Cheers!,
Kedar...
>
> Rob
linux-next: Tree for Apr 22
Hi all, There will be no linux-next release on Monday (ANZAC Day). Changes since 20160421: New trees: rdma-leon, rdma-leon-test The pci tree gained a build failure so I used the version from next-20160421. The sound-asoc tree gained a build failure so I used the version from next-20160421. The akpm-current tree still had its build failure and gained another (due to interactions with other trees) for which I applied a patch. Non-merge commits (relative to Linus' tree): 4966 4535 files changed, 196470 insertions(+), 99293 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 234 trees (counting Linus' and 35 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (5f44abd041c5 Merge tag 'rtc-4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux) Merging fixes/master (9735a22799b9 Linux 4.6-rc2) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (421e31e58c2a ARCv2: Enable LOCKDEP) Merging arm-current/fixes (ac36a881b72a ARM: 8564/1: fix cpu feature extracting helper) Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs for v4.6-rc2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging powerpc-fixes/fixes (4705e02498d6 powerpc: Update TM user feature bits in scan_features()) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.) Merging net/master (b4f70527f052 openvswitch: use flow protocol when recalculating ipv6 checksums) Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.) Merging ipvs/master (bcf493428840 netfilter: ebtables: Fix extension lookup with identical name) Merging wireless-drivers/master (e2841ea91611 Merge tag 'iwlwifi-for-kalle-2016-04-12_2' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging mac80211/master (8f815cdde3e5 nl80211: check netlink protocol in socket release notification) Merging sound-current/for-linus (3194ed497939 ALSA: hda - Fix possible race on regmap bypass flip) Merging pci-current/for-linus (67e658794ca1 cxgb4: Set VPD size so we can read both VPD structures) Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4) Merging tty.current/tty-linus (f077b7368291 Revert "serial: 8250: Add hardware dependency to RT288X option") Merging usb.current/usb-linus (c3b46c73264b Linux 4.6-rc4) Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix use-after-free) Merging usb-serial-fixes/usb-linus (bf1620068911 Linux 4.6-rc3) Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: change workqueue ci_otg as freezable) Merging staging.current/staging-linus (bf1620068911 Linux 4.6-rc3) Merging char-misc.current/char-misc-linus (c3b46c73264b Linux 4.6-rc4) Merging input-current/for-linus (dcc7597116c6 Input: twl4030-vibra - do not reparent to grandparent) Merging crypto-current/master (340ff60ae93a crypto: talitos - fix AEAD tcrypt tests) Merging ide/master (1993b176a822 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging
Re: [PATCH 2/2 v5] irqchip/Layerscape: Add SCFG MSI controller support
On Mon, Mar 7, 2016 at 3:50 AM, Marc Zyngier wrote: > On Mon, 7 Mar 2016 11:36:22 +0800 > Minghuan Lian wrote: > >> Some kind of NXP Layerscape SoC provides a MSI >> implementation which uses two SCFG registers MSIIR and >> MSIR to support 32 MSI interrupts for each PCIe controller. >> The patch is to support it. >> >> Signed-off-by: Minghuan Lian > > Acked-by: Marc Zyngier > > The DT binding still needs an Ack from the DT maintainers though (cc'd). Marc, Who will be responsible to pick this driver? I see you are also one of the maintainers for irqchip. Can you pick up the driver? The binding has already gotten ACKed by the device tree maintainer. Regards, Leo
[PATCH 3/4] ARM64: dts: rockchip: add RK3399 evaluation board
The RK3399 evaluation board is designed with pmic rk808 on top board. Signed-off-by: Jianqun Xu --- changes in v2: - remove rk808 since without i2c, which will upstream independently - remove es8316 since without i2c, which will upstream independently Documentation/devicetree/bindings/arm/rockchip.txt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt index 2549519..6491b56 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.txt +++ b/Documentation/devicetree/bindings/arm/rockchip.txt @@ -101,4 +101,8 @@ Rockchip platforms device tree bindings - Rockchip RK3228 Evaluation board: Required root node properties: - - compatible = "rockchip,rk3228-evb", "rockchip,rk3228"; + - compatible = "rockchip,rk3228-evb", "rockchip,rk3228"; + +- Rockchip RK3399 evb: +Required root node properties: + - compatible = "rockchip,rk3399-evb", "rockchip,rk3399"; -- 1.9.1
[PATCH v2 2/4] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs
This patch adds core dtsi file for Rockchip RK3399 SoCs.
The RK3399 has big/little architecture, which needs a separate
node for the PMU of each microarchitecture, for now it missing
the pmu node since the old one could not work well.
Marc is working on it with:
https://lkml.org/lkml/2016/4/11/182
and on the following branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
irq/percpu-partition
That will to be tested on RK3399 evb.
Signed-off-by: Jianqun Xu
---
changes in v2:
- remove arm-pmu at first. (Marc, Heiko, Mark)
- remove rga, emmc, usb3, mipi, edp, pd, i2c, gpu, thermal, tsadc, saradc,
which will upstream independently
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1022 ++
1 file changed, 1022 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 000..5a8a915
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,1022 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/ {
+ compatible = "rockchip,rk3399";
+
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ serial4 = &uart4;
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu_l0>;
+ };
+ core1 {
+ cpu = <&cpu_l1>;
+ };
+ core2 {
+ cpu = <&cpu_l2>;
+ };
+ core3 {
+ cpu = <&cpu_l3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu_b0>;
+ };
+ core1 {
+ cpu = <&cpu_b1>;
+ };
+ };
+ };
+
+ cpu_l0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ #cooling-cells = <2>; /* min followed by max */
+ cl
Re: [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting
On 19-04-16, 16:12, Ashwin Chaugule wrote: > + Ryan > > Hi Al, > > On 18 April 2016 at 20:11, Al Stone wrote: > > When CPPC is being used by ACPI on arm64, user space tools such as > > cpupower report CPU frequency values from sysfs that are incorrect. > > > > What the driver was doing was reporting the values given by ACPI tables > > in whatever scale was used to provide them. However, the ACPI spec > > defines the CPPC values as unitless abstract numbers. Internal kernel > > structures such as struct perf_cap, in contrast, expect these values > > to be in KHz. When these struct values get reported via sysfs, the > > user space tools also assume they are in KHz, causing them to report > > incorrect values (for example, reporting a CPU frequency of 1MHz when > > it should be 1.8GHz). > > > > While the investigation for a long term fix proceeds (several options > > are being explored, some of which may require spec changes or other > > much more invasive fixes), this patch forces the values read by CPPC > > to be read in KHz, regardless of what they actually represent. > > > > The downside is that this approach has some assumptions: > > > >(1) It relies on SMBIOS3 being used, *and* that the Max Frequency > >value for a processor is set to a non-zero value. > > > >(2) It assumes that all processors run at the same speed. This > >patch retrieves the first CPU Max Frequency from a type 4 DMI > >record that it can find. This may not be an issue, however, as a > >sampling of DMI data on x86 and arm64 indicates there is often only > >one such record regardless. Don't we have any big LITTLE ARM servers yet ? Or we will not have them at all ? > > For arm64 servers, this may be sufficient, but it does rely on > > firmware values being set correctly. Hence, other approaches are > > also being considered. > > > > This has been tested on three arm64 servers, with and without DMI, with > > and without CPPC support. > > > > Changes for v2: > > -- Corrected thinko: needed to have DEPENDS on DMI in Kconfig.arm, > >not SELECT DMI (found by build daemon) > > > > Signed-off-by: Al Stone > > This looks like a good short term solution. Does it make more sense to > move this to the cppc_cpufreq driver though? Since that ties more > closely into the cpufreq framework which requires the kHz values in > sysfs. That way we can keep the cppc_acpi.c shim compliant with the > ACPI spec. (i.e. values read in cppc structures remain abstract and > unitless). > > Rafael, Viresh, others, > > Any other ideas how to handle this better in the long term? > > - Decouple the cpufreq sysfs from the cppc driver and introduce its > own entries. Is it possibly to do this cleanly while still allowing > usage of cpufreq registration with existing governors? > > - Come up with a scaling factor using the PMU cycle counter at boot > before the CPPC drivers are initialized. This would use the current > freq set by some UEFI var. This would possibly require some messy > perfevents plumbing and added bootup time though. I may be missing the obvious, but can't we just create the cpufreq-table from this table in khz? We wouldn't require any further change then. -- viresh
Re: [PATCH] drm/exynos/hdmi: Don't print error on deferral due to regulators
On 04/21/2016 08:51 PM, Javier Martinez Canillas wrote: > The regulators may not be available just because their driver's probe > function was just not executed and so the regulators not registered. > > So, in this case the Exynos HDMI driver should not print logs since > a -EPROBE_DEFER is not really an error and that will just pollute > the kernel log and confuse users. > > This patch prevents the following misleading messages to be printed: > > [1.443638] [drm:hdmi_probe] *ERROR* failed to get regulators > [1.449326] [drm:hdmi_probe] *ERROR* hdmi_resources_init failed > > Reported-by: Krzysztof Kozlowski > Signed-off-by: Javier Martinez Canillas > > --- > > The real fix for these kind of issues is to change the device model > core to support device dependencies so the number of probe deferral > should be minimal or non-existent, instead of fixing on each driver. > > But there have been different attempts [0,1] to implement this and > there doesn't seem that this will be solved in the short term. > > [0]: https://lkml.org/lkml/2014/5/12/452 > [1]: https://lkml.org/lkml/2015/5/25/251 > > drivers/gpu/drm/exynos/exynos_hdmi.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Since I like to look at 'dmesg -l err' then I find this useful: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
[PATCH v2 1/4] Documentation: rockchip-dw-mshc: add description for rk3399
From: Shawn Lin Add "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc" for dwmmc on rk3399 platform. Change-Id: Ieefafab5f0e9650271e823659e2bec1556c4a9bc Signed-off-by: Shawn Lin --- Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt index ea5614b..07184e8 100644 --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt @@ -15,6 +15,7 @@ Required Properties: - "rockchip,rk3288-dw-mshc": for Rockchip RK3288 - "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3036 - "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3368 + - "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3399 Optional Properties: * clocks: from common clock binding: if ciu_drive and ciu_sample are -- 1.9.1
[PATCH v2 0/4] ARM64: dts: rockchip: add support for RK3399
Add dtsi file for RK3399 SoCs, and evb dts file for RK3399 evb. To make patch more easily to be reviewed, some nodes have been removed temporarily, after this base file been applied, more patches will be upstreamed independently. Jianqun Xu (3): ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs ARM64: dts: rockchip: add RK3399 evaluation board ARM64: dts: rockchip: add dts file for RK3399 evaluation board Shawn Lin (1): Documentation: rockchip-dw-mshc: add description for rk3399 Documentation/devicetree/bindings/arm/rockchip.txt |6 +- .../devicetree/bindings/mmc/rockchip-dw-mshc.txt |1 + arch/arm64/boot/dts/rockchip/Makefile |1 + arch/arm64/boot/dts/rockchip/rk3399-evb.dts| 122 +++ arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1022 5 files changed, 1151 insertions(+), 1 deletion(-) create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi -- changes in v2: - split into more patches. (Heiko) - remove arm-pmu at first. (Marc, Heiko, Mark) - remove rga, emmc, usb3, mipi, edp, pd, i2c, gpu, thermal, tsadc, saradc, which will upstream independently - remove rk808 since without i2c, which will upstream independently - remove es8316 since without i2c, which will upstream independently - add rockchip-dw-mshc binding patch - add rockchip,rk3399-evb binding patch - fix codingstyle issues 1.9.1
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/net/ethernet/qlogic/qede/qede_main.c: In function 'qede_fill_frag_skb':
drivers/net/ethernet/qlogic/qede/qede_main.c:961:31: error: 'struct page' has
no member named '_count'
atomic_inc(¤t_bd->data->_count);
^
drivers/net/ethernet/qlogic/qede/qede_main.c: In function 'qede_rx_int':
drivers/net/ethernet/qlogic/qede/qede_main.c:1412:33: error: 'struct page' has
no member named '_count'
atomic_inc(&sw_rx_data->data->_count);
^
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function
'mlx5e_alloc_rx_fragmented_mpwqe':
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:297:32: error: 'struct page'
has no member named '_count'
&wi->umr.dma_info[i].page->_count);
^
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:316:32: error: 'struct page'
has no member named '_count'
&wi->umr.dma_info[i].page->_count);
^
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function
'mlx5e_free_rx_fragmented_mpwqe':
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:341:32: error: 'struct page'
has no member named '_count'
&wi->umr.dma_info[i].page->_count);
^
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function
'mlx5e_alloc_rx_linear_mpwqe':
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:391:28: error: 'struct page'
has no member named '_count'
&wi->dma_info.page[i]._count);
^
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function
'mlx5e_free_rx_linear_mpwqe':
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:415:28: error: 'struct page'
has no member named '_count'
&wi->dma_info.page[i]._count);
^
Caused by commit
2dde4bc2820e ("mm: rename _count, field of the struct page, to _refcount")
interacting with commits
f86af2dfded6 ("qede: Fix various memory allocation error flows for fastpath")
from Linus' tree and
bc77b240b3c5 ("net/mlx5e: Add fragmented memory support for RX multi packet
WQE")
from the net-next tree.
I applied the following patch:
From: Stephen Rothwell
Date: Fri, 22 Apr 2016 15:13:21 +1000
Subject: [PATCH] mm-rename-_count-field-of-the-struct-page-to-_refcount-fix6
Signed-off-by: Stephen Rothwell
---
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 20 ++--
drivers/net/ethernet/qlogic/qede/qede_main.c| 4 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 918b7c7fd74f..0543fbc130b6 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -293,8 +293,8 @@ static int mlx5e_alloc_rx_fragmented_mpwqe(struct mlx5e_rq
*rq,
for (i = 0; i < MLX5_MPWRQ_PAGES_PER_WQE; i++) {
if (unlikely(mlx5e_alloc_and_map_page(rq, wi, i)))
goto err_unmap;
- atomic_add(MLX5_MPWRQ_STRIDES_PER_PAGE,
- &wi->umr.dma_info[i].page->_count);
+ page_ref_add(wi->umr.dma_info[i].page,
+MLX5_MPWRQ_STRIDES_PER_PAGE);
wi->skbs_frags[i] = 0;
}
@@ -312,8 +312,8 @@ err_unmap:
while (--i >= 0) {
dma_unmap_page(rq->pdev, wi->umr.dma_info[i].addr, PAGE_SIZE,
PCI_DMA_FROMDEVICE);
- atomic_sub(MLX5_MPWRQ_STRIDES_PER_PAGE,
- &wi->umr.dma_info[i].page->_count);
+ page_ref_sub(wi->umr.dma_info[i].page,
+MLX5_MPWRQ_STRIDES_PER_PAGE);
put_page(wi->umr.dma_info[i].page);
}
dma_unmap_single(rq->pdev, wi->umr.mtt_addr, mtt_sz, PCI_DMA_TODEVICE);
@@ -337,8 +337,8 @@ void mlx5e_free_rx_fragmented_mpwqe(struct mlx5e_rq *rq,
for (i = 0; i < MLX5_MPWRQ_PAGES_PER_WQE; i++) {
dma_unmap_page(rq->pdev, wi->umr.dma_info[i].addr, PAGE_SIZE,
PCI_DMA_FROMDEVICE);
- atomic_sub(MLX5_MPWRQ_STRIDES_PER_PAGE - wi->skbs_frags[i],
- &wi->umr.dma_info[i].page->_count);
+ page_ref_sub(wi->umr.dma_info[i].page,
+MLX5_MPWRQ_STRIDES_PER_PAGE - wi->skbs_frags[i]);
put_page(wi->umr.dma_info[i].page);
}
dma_unmap_single(rq->pdev, wi->umr.mtt_addr, mtt_sz, PCI_DMA_TODEVICE);
@@ -387,8 +387,8 @@ static int mlx5e_alloc_rx_linear_mpwqe(struct mlx5e_rq *rq,
*/
split_page(wi->dma_info.page, MLX5_MPWRQ_WQE_PAGE_ORDER);
for (i = 0; i < MLX5_MPWRQ_PAGES_PER_WQE; i++) {
- atomic_add(MLX5_MPWRQ_STRIDES_PER_PAGE,
- &wi->dma_info.
Re: [RFC][PATCH 0/6] /dev/random - a new approach
Am Donnerstag, 21. April 2016, 22:51:55 schrieb Theodore Ts'o: Hi Theodore, > I still have a massive problem with the claims that the "Jitter" RNG > provides any amount of entropy. Just because you and I might not be > able to analyze it doesn't mean that somebody else couldn't. After > all, DUAL-EC DRNG was very complicated and hard to analyze. So would > be something like > >AES(NSA_KEY, COUNTER++) > > Very hard to analyze indeed. Shall we run statistical tests? They'll > pass with flying colors. > > Secure? Not so much. If you are concerned with that RNG, we can easily drop it from the LRNG. The testing documented in the writeup disable the Jitter RNG to ensure that only the LRNG IRQ collection is tested. The conclusions regarding timeliness of the seeding, the prevention of draining the entropy pool are performed without the Jitter RNG which implies that the Jitter RNG can be dropped without harm. Ciao Stephan
Re: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
From: Yunhui Cui
Sent: Thursday, April 21, 2016 9:52 PM
To: Han Xu; Yunhui Cui; dw...@infradead.org; computersforpe...@gmail.com;
han...@freescale.com
Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org;
linux-arm-ker...@lists.infradead.org; Yao Yuan
Subject: RE: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
> -Original Message-
> From: Han Xu
> Sent: Thursday, April 21, 2016 11:48 PM
> To: Yunhui Cui; Yunhui Cui; dw...@infradead.org;
> computersforpe...@gmail.com; han...@freescale.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; linux-
> arm-ker...@lists.infradead.org; Yao Yuan
> Subject: Re: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
>
>
>
>
> From: Yunhui Cui
> Sent: Thursday, April 21, 2016 3:41 AM
> To: Han Xu; Yunhui Cui; dw...@infradead.org; computersforpe...@gmail.com;
> han...@freescale.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; linux-
> arm-ker...@lists.infradead.org; Yao Yuan
> Subject: RE: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
>
> On Thu, Apr 24, 2016 at 06:37:01 AM +0800, Han Xu wrote:
> >
> > From: Yunhui Cui
> > Sent: Wednesday, April 13, 2016 9:50 PM
> > To: dw...@infradead.org; computersforpe...@gmail.com;
> > han...@freescale.com
> > Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org;
> > linux- arm-ker...@lists.infradead.org; Yao Yuan; Yunhui Cui
> > Subject: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
> >
> > From: Yunhui Cui
> >
> > A-009282: QuadSPI: QuadSPI data pre-fetch can result in incorrect data
> > Affects: QuadSPI
> > Description: With AHB buffer prefetch enabled, the QuadSPI may return
> > incorrect data on the AHB interface. The buffer pre-fetch is enabled
> > if the fetch size as configured either in the LUT or in the BUFxCR
> > register is greater than 8 bytes.
> > Impact: Only 64 bit read allowed.
> > Workaround: Keep the read data size to 64 bits (8 Bytes), which
> > disables the prefetch on the AHB buffer, and prevents this issue from
> occurring.
> >
> > Signed-off-by: Yunhui Cui
> > ---
> > drivers/mtd/spi-nor/fsl-quadspi.c | 29 +++--
> > 1 file changed, 23 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
> > b/drivers/mtd/spi-nor/fsl- quadspi.c index fea18b6..d9f3e50 100644
> > --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> > +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> > @@ -752,19 +752,36 @@ static void fsl_qspi_init_abh_read(struct
> > fsl_qspi
> > *q) {
> > void __iomem *base = q->iobase;
> > int seqid;
> > + const struct fsl_qspi_devtype_data *devtype_data =
> > + q->devtype_data;
> >
> > /* AHB configuration for access buffer 0/1/2 .*/
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF0CR);
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF1CR);
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF2CR);
> > +
> > /*
> > -* Set ADATSZ with the maximum AHB buffer size to improve the
> > -* read performance.
> > +* Errata: A-009282: QuadSPI data prefetch may result in
> > incorrect data
> > +* Workaround: Keep the read data size to 64 bits (8 bytes).
> > +* This disables the prefetch on the AHB buffer and
> > +* prevents this issue from occurring.
> > */
> > - qspi_writel(q, QUADSPI_BUF3CR_ALLMST_MASK |
> > - ((q->devtype_data->ahb_buf_size / 8)
> > - << QUADSPI_BUF3CR_ADATSZ_SHIFT),
> > - base + QUADSPI_BUF3CR);
> > + if (devtype_data->devtype == FSL_QUADSPI_LS2080A ||
> > + devtype_data->devtype == FSL_QUADSPI_LS1021A) {
> >
> > Use QUIRK, not SoC name.
> [Yunhui] This is a SoC errata, we need distinguish according to the
> devtype_data->devtype
>
> It's the same thing and we have already done that before.
> [Yunhui] your mean that I should add such as the following code:
#define QUADSPI_QUIRK_ERRATA_9282 (1 << 4)
static inline int has_errata_num_a009282(struct fsl_qspi *q)
{
return q->devtype_data->driver_data &
QUADSPI_QUIRK_ERRATA_9282;
}
I mean QUIRK can be used even for HW limitation, but it's not necessary to
use ERRATA number as QUIRK name, you can name it with natural language,
such as QUADSPI_QUIRK_ADASZ_8BYTE_LIMIT, and describe the reason in
comments.
> /*
> * TKT253890, Controller needs driver to fill txfifo till 16 byte to
> * trigger data transfer even though extra data will not transferred.
> */
> #define QUADSPI_QUIRK_TKT253890 (1 << 2)
> /* Controller cannot wake up from wait mode, TKT245618 */
> #define QUADSPI_QUIRK_TKT245618 (1 << 3)
>
>
> > +
> > + qspi_writel(
Re: [PATCH V3 29/29] ethernet: use parity8 in broadcom/tg3.c
On Thu, Apr 14, 2016 at 8:42 AM, wrote:
>
> From: Zhaoxiu Zeng
>
> Signed-off-by: Zhaoxiu Zeng
Looks good to me.
Acked-by: Siva Reddy Kallam
> ---
> drivers/net/ethernet/broadcom/tg3.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c
> b/drivers/net/ethernet/broadcom/tg3.c
> index 3010080..802a429 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -12939,11 +12939,7 @@ static int tg3_test_nvram(struct tg3 *tp)
>
> err = -EIO;
> for (i = 0; i < NVRAM_SELFBOOT_DATA_SIZE; i++) {
> - u8 hw8 = hweight8(data[i]);
> -
> - if ((hw8 & 0x1) && parity[i])
> - goto out;
> - else if (!(hw8 & 0x1) && !parity[i])
> + if (parity8(data[i]) == !!parity[i])
> goto out;
> }
> err = 0;
> --
> 2.5.0
>
>
Re: [PATCH] ARM: dts: omap3: Fix ISP syscon register offset
On 16.04.2016 09:20, Ivaylo Dimitrov wrote:
According to the TRM, SCM CONTROL_CSIRXFE register is on offset 0x6c
Signed-off-by: Ivaylo Dimitrov
---
arch/arm/boot/dts/omap34xx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 5cdba1f..e446562 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -46,7 +46,7 @@
0x480bd800 0x017c>;
interrupts = <24>;
iommus = <&mmu_isp>;
- syscon = <&scm_conf 0xdc>;
+ syscon = <&scm_conf 0x6c>;
ti,phy-type = ;
#clock-cells = <1>;
ports {
Anyone going to review that?
[PATCH v7 8/8] arm64: dts: mediatek: Add Video Encoder for MT8173
Add video encoder node for MT8173
Signed-off-by: Tiffany Lin
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 39 ++
1 file changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index ae147bb..348ce0e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -717,6 +717,45 @@
clock-names = "apb", "smi";
};
+ vcodec_enc: vcodec@18002000 {
+ compatible = "mediatek,mt8173-vcodec-enc";
+ reg = <0 0x18002000 0 0x1000>, /* VENC_SYS */
+ <0 0x19002000 0 0x1000>; /* VENC_LT_SYS */
+ interrupts = ,
+;
+ mediatek,larb = <&larb3>,
+ <&larb5>;
+ iommus = <&iommu M4U_PORT_VENC_RCPU>,
+<&iommu M4U_PORT_VENC_REC>,
+<&iommu M4U_PORT_VENC_BSDMA>,
+<&iommu M4U_PORT_VENC_SV_COMV>,
+<&iommu M4U_PORT_VENC_RD_COMV>,
+<&iommu M4U_PORT_VENC_CUR_LUMA>,
+<&iommu M4U_PORT_VENC_CUR_CHROMA>,
+<&iommu M4U_PORT_VENC_REF_LUMA>,
+<&iommu M4U_PORT_VENC_REF_CHROMA>,
+<&iommu M4U_PORT_VENC_NBM_RDMA>,
+<&iommu M4U_PORT_VENC_NBM_WDMA>,
+<&iommu M4U_PORT_VENC_RCPU_SET2>,
+<&iommu M4U_PORT_VENC_REC_FRM_SET2>,
+<&iommu M4U_PORT_VENC_BSDMA_SET2>,
+<&iommu M4U_PORT_VENC_SV_COMA_SET2>,
+<&iommu M4U_PORT_VENC_RD_COMA_SET2>,
+<&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
+<&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
+<&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
+<&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
+ mediatek,vpu = <&vpu>;
+ clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
+<&topckgen CLK_TOP_VENC_SEL>,
+<&topckgen CLK_TOP_UNIVPLL1_D2>,
+<&topckgen CLK_TOP_VENC_LT_SEL>;
+ clock-names = "venc_sel_src",
+ "venc_sel",
+ "venc_lt_sel_src",
+ "venc_lt_sel";
+ };
+
vencltsys: clock-controller@1900 {
compatible = "mediatek,mt8173-vencltsys", "syscon";
reg = <0 0x1900 0 0x1000>;
--
1.7.9.5
[PATCH v7 1/8] dt-bindings: Add a binding for Mediatek Video Processor
From: Andrew-CT Chen
Add a DT binding documentation of Video Processor Unit for the
MT8173 SoC from Mediatek.
Signed-off-by: Andrew-CT Chen
Signed-off-by: Tiffany Lin
Acked-by: Rob Herring
---
.../devicetree/bindings/media/mediatek-vpu.txt | 31
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt
diff --git a/Documentation/devicetree/bindings/media/mediatek-vpu.txt
b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
new file mode 100644
index 000..2a5bac3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
@@ -0,0 +1,31 @@
+* Mediatek Video Processor Unit
+
+Video Processor Unit is a HW video controller. It controls HW Codec including
+H.264/VP8/VP9 Decode, H.264/VP8 Encode and Image Processor (scale/rotate/color
convert).
+
+Required properties:
+ - compatible: "mediatek,mt8173-vpu"
+ - reg: Must contain an entry for each entry in reg-names.
+ - reg-names: Must include the following entries:
+"tcm": tcm base
+"cfg_reg": Main configuration registers base
+ - interrupts: interrupt number to the cpu.
+ - clocks : clock name from clock manager
+ - clock-names: must be main. It is the main clock of VPU
+
+Optional properties:
+ - memory-region: phandle to a node describing memory (see
+Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
+to be used for VPU extended memory; if not present, VPU may be located
+anywhere in the memory
+
+Example:
+ vpu: vpu@1002 {
+ compatible = "mediatek,mt8173-vpu";
+ reg = <0 0x1002 0 0x3>,
+ <0 0x1005 0 0x100>;
+ reg-names = "tcm", "cfg_reg";
+ interrupts = ;
+ clocks = <&topckgen TOP_SCP_SEL>;
+ clock-names = "main";
+ };
--
1.7.9.5
[PATCH v7 4/8] dt-bindings: Add a binding for Mediatek Video Encoder
Add a DT binding documentation of Video Encoder for the
MT8173 SoC from Mediatek.
Signed-off-by: Tiffany Lin
Acked-by: Rob Herring
---
.../devicetree/bindings/media/mediatek-vcodec.txt | 59
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt
diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
new file mode 100644
index 000..59a47a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -0,0 +1,59 @@
+Mediatek Video Codec
+
+Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
+supports high resolution encoding functionalities.
+
+Required properties:
+- compatible : "mediatek,mt8173-vcodec-enc" for encoder
+- reg : Physical base address of the video codec registers and length of
+ memory mapped region.
+- interrupts : interrupt number to the cpu.
+- mediatek,larb : must contain the local arbiters in the current Socs.
+- clocks : list of clock specifiers, corresponding to entries in
+ the clock-names property.
+- clock-names: encoder must contain "venc_sel_src", "venc_sel",
+- "venc_lt_sel_src", "venc_lt_sel".
+- iommus : should point to the respective IOMMU block with master port as
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ for details.
+- mediatek,vpu : the node of video processor unit
+
+Example:
+vcodec_enc: vcodec@0x18002000 {
+compatible = "mediatek,mt8173-vcodec-enc";
+reg = <0 0x18002000 0 0x1000>,/*VENC_SYS*/
+ <0 0x19002000 0 0x1000>;/*VENC_LT_SYS*/
+interrupts = ,
+;
+mediatek,larb = <&larb3>,
+ <&larb5>;
+iommus = <&iommu M4U_PORT_VENC_RCPU>,
+ <&iommu M4U_PORT_VENC_REC>,
+ <&iommu M4U_PORT_VENC_BSDMA>,
+ <&iommu M4U_PORT_VENC_SV_COMV>,
+ <&iommu M4U_PORT_VENC_RD_COMV>,
+ <&iommu M4U_PORT_VENC_CUR_LUMA>,
+ <&iommu M4U_PORT_VENC_CUR_CHROMA>,
+ <&iommu M4U_PORT_VENC_REF_LUMA>,
+ <&iommu M4U_PORT_VENC_REF_CHROMA>,
+ <&iommu M4U_PORT_VENC_NBM_RDMA>,
+ <&iommu M4U_PORT_VENC_NBM_WDMA>,
+ <&iommu M4U_PORT_VENC_RCPU_SET2>,
+ <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
+ <&iommu M4U_PORT_VENC_BSDMA_SET2>,
+ <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
+ <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
+ <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
+ <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
+ <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
+ <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
+mediatek,vpu = <&vpu>;
+clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
+ <&topckgen CLK_TOP_VENC_SEL>,
+ <&topckgen CLK_TOP_UNIVPLL1_D2>,
+ <&topckgen CLK_TOP_VENC_LT_SEL>;
+clock-names = "venc_sel_src",
+ "venc_sel",
+ "venc_lt_sel_src",
+ "venc_lt_sel";
+ };
--
1.7.9.5
[PATCH v7 5/8] [media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver
Add v4l2 layer encoder driver for MT8173 Signed-off-by: Tiffany Lin --- drivers/media/platform/Kconfig | 16 + drivers/media/platform/Makefile|2 + drivers/media/platform/mtk-vcodec/Makefile | 14 + drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 339 + drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1301 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h | 59 + .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 467 +++ .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 137 +++ .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.h | 26 + .../media/platform/mtk-vcodec/mtk_vcodec_intr.c| 56 + .../media/platform/mtk-vcodec/mtk_vcodec_intr.h| 27 + .../media/platform/mtk-vcodec/mtk_vcodec_util.c| 96 ++ .../media/platform/mtk-vcodec/mtk_vcodec_util.h| 87 ++ drivers/media/platform/mtk-vcodec/venc_drv_base.h | 62 + drivers/media/platform/mtk-vcodec/venc_drv_if.c| 107 ++ drivers/media/platform/mtk-vcodec/venc_drv_if.h| 165 +++ drivers/media/platform/mtk-vcodec/venc_ipi_msg.h | 210 17 files changed, 3171 insertions(+) create mode 100644 drivers/media/platform/mtk-vcodec/Makefile create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.h create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 74c3575..13b765a 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -165,6 +165,22 @@ config VIDEO_MEDIATEK_VPU To compile this driver as a module, choose M here: the module will be called mtk-vpu. +config VIDEO_MEDIATEK_VCODEC + tristate "Mediatek Video Codec driver" + depends on VIDEO_DEV && VIDEO_V4L2 + depends on ARCH_MEDIATEK || COMPILE_TEST + select VIDEOBUF2_DMA_CONTIG + select V4L2_MEM2MEM_DEV + select VIDEO_MEDIATEK_VPU + default n + ---help--- + Mediatek video codec driver provides HW capability to + encode and decode in a range of video formats + This driver rely on VPU driver to communicate with VPU. + + To compile this driver as a module, choose M here: the + module will be called mtk-vcodec + config VIDEO_MEM2MEM_DEINTERLACE tristate "Deinterlace support" depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 2efb7b1..6e735fe 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -58,3 +58,5 @@ obj-$(CONFIG_VIDEO_XILINX)+= xilinx/ ccflags-y += -I$(srctree)/drivers/media/i2c obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu/ + +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/ diff --git a/drivers/media/platform/mtk-vcodec/Makefile b/drivers/media/platform/mtk-vcodec/Makefile new file mode 100644 index 000..d04433be --- /dev/null +++ b/drivers/media/platform/mtk-vcodec/Makefile @@ -0,0 +1,14 @@ + +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-enc.o mtk-vcodec-common.o + + + +mtk-vcodec-enc-y := mtk_vcodec_enc.o \ + mtk_vcodec_enc_drv.o \ + mtk_vcodec_enc_pm.o \ + venc_drv_if.o \ + +mtk-vcodec-common-y := mtk_vcodec_intr.o \ + mtk_vcodec_util.o\ + +ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h new file mode 100644 index 000..bf41ff3 --- /dev/null +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h @@ -0,0 +1,339 @@ +/* +* Copyright (c) 2016 MediaTek Inc. +* Author: PC Chen +* Tiffany Lin +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License version 2 as +* published by the Free Software Foundation. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied wa
[PATCH v7 0/8] Add MT8173 Video Encoder Driver and VPU Driver
== Introduction == The purpose of this series is to add the driver for video codec hw embedded in the Mediatek's MT8173 SoCs. Mediatek Video Codec is able to handle video encoding of in a range of formats. This patch series also include VPU driver. Mediatek Video Codec driver rely on VPU driver to load, communicate with VPU. Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI both have been merged in v4.6-rc1. == Device interface == In principle the driver bases on v4l2 memory-to-memory framework: it provides a single video node and each opened file handle gets its own private context with separate buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source buffers, i.e. raw video frames) and CAPTURE (for destination buffers, i.e. encoded video frames). == VPU (Video Processor Unit) == The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs. It is able to handle video decoding/encoding in a range of formats. The driver provides with VPU firmware download, memory management and the communication interface between CPU and VPU. For VPU initialization, it will create virtual memory for CPU access and physical address for VPU hw device access. When a decode/encode instance opens a device node, vpu driver will download vpu firmware to the device. A decode/encode instant will decode/encode a frame using VPU interface to interrupt vpu to handle decoding/encoding jobs. Please have a look at the code and comments will be very much appreciated. Change in v7: 1. Rebase against the master branch of git://linuxtv.org/media_tree.git 2. Add ycbcr_enc, quantization and xfer_func in try_fmt, g_fmt, s_fmt 3. Merge h264_enc and vp8_enc to one venc directory Change in v6: 1. Add synchronization access protect between irq handler and work thread 2. Add DMA_ATTR_ALLOC_SINGLE_PAGES support 3. S_FMT will return coded_width, coded_height, so user space could allocate correct size memory that HW required 4. merge h264/vp8 enc ap and md32 ipi msg 5. separate h264/vp8 enc gop_size and intra_period handle 6. remove sizeimage relative code in work buffer function 7. Refine makefile to build as an module 8. Code clean up VPU Part 1. export symbols for building VPU as an module 2. change function from "wait_event_interruptible_timeout" to "wait_event_timeout" since CPU needs to wait for ACK from VPU even if it was interrupted by a signal v4l2-compliance test output: localhost Encode # ./v4l2-compliance -d /dev/video1 Driver Info: Driver name : mtk-vcodec-enc Card type : platform:mt8173 Bus info : platform:mt8173 Driver version: 4.4.0 Capabilities : 0x84204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Compliance test for device /dev/video1 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls: test VIDIOC_QUERYCTRL/MENU: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 12 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK test VIDIOC_G_FBUF: OK (Not Supported)
[PATCH v7 7/8] [media] vcodec: mediatek: Add Mediatek H264 Video Encoder Driver
Add h264 encoder driver for MT8173
Signed-off-by: PoChun Lin
Signed-off-by: Tiffany Lin
---
drivers/media/platform/mtk-vcodec/Makefile |1 +
.../media/platform/mtk-vcodec/venc/venc_h264_if.c | 687
drivers/media/platform/mtk-vcodec/venc_drv_if.c|4 +-
3 files changed, 691 insertions(+), 1 deletion(-)
create mode 100644 drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
diff --git a/drivers/media/platform/mtk-vcodec/Makefile
b/drivers/media/platform/mtk-vcodec/Makefile
index bf73a45..dc5cb00 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -12,6 +12,7 @@ mtk-vcodec-enc-y := venc/venc_vp8_if.o \
venc_drv_if.o \
venc_vpu_if.o \
+
mtk-vcodec-common-y := mtk_vcodec_intr.o \
mtk_vcodec_util.o\
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
new file mode 100644
index 000..6e90b3f
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
@@ -0,0 +1,687 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Jungchang Tsao
+ * Daniel Hsiao
+ * PoChun Lin
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+
+#include "../mtk_vcodec_drv.h"
+#include "../mtk_vcodec_util.h"
+#include "../mtk_vcodec_intr.h"
+#include "../mtk_vcodec_enc.h"
+#include "../mtk_vcodec_enc_pm.h"
+#include "../venc_drv_base.h"
+#include "../venc_ipi_msg.h"
+#include "../venc_vpu_if.h"
+#include "mtk_vpu.h"
+
+static const char h264_filler_marker[] = {0x0, 0x0, 0x0, 0x1, 0xc};
+
+#define H264_FILLER_MARKER_SIZE ARRAY_SIZE(h264_filler_marker)
+#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
+
+/**
+ * enum venc_h264_vpu_work_buf - h264 encoder buffer index
+ */
+enum venc_h264_vpu_work_buf {
+ VENC_H264_VPU_WORK_BUF_RC_INFO,
+ VENC_H264_VPU_WORK_BUF_RC_CODE,
+ VENC_H264_VPU_WORK_BUF_REC_LUMA,
+ VENC_H264_VPU_WORK_BUF_REC_CHROMA,
+ VENC_H264_VPU_WORK_BUF_REF_LUMA,
+ VENC_H264_VPU_WORK_BUF_REF_CHROMA,
+ VENC_H264_VPU_WORK_BUF_MV_INFO_1,
+ VENC_H264_VPU_WORK_BUF_MV_INFO_2,
+ VENC_H264_VPU_WORK_BUF_SKIP_FRAME,
+ VENC_H264_VPU_WORK_BUF_MAX,
+};
+
+/**
+ * enum venc_h264_bs_mode - for bs_mode argument in h264_enc_vpu_encode
+ */
+enum venc_h264_bs_mode {
+ H264_BS_MODE_SPS,
+ H264_BS_MODE_PPS,
+ H264_BS_MODE_FRAME,
+};
+
+/*
+ * struct venc_h264_vpu_config - Structure for h264 encoder configuration
+ * @input_fourcc: input fourcc
+ * @bitrate: target bitrate (in bps)
+ * @pic_w: picture width. Picture size is visible stream resolution, in pixels,
+ * to be used for display purposes; must be smaller or equal to buffer
+ * size.
+ * @pic_h: picture height
+ * @buf_w: buffer width. Buffer size is stream resolution in pixels aligned to
+ * hardware requirements.
+ * @buf_h: buffer height
+ * @gop_size: group of picture size (idr frame)
+ * @intra_period: intra frame period
+ * @framerate: frame rate in fps
+ * @profile: as specified in standard
+ * @level: as specified in standard
+ * @wfd: WFD mode 1:on, 0:off
+ */
+struct venc_h264_vpu_config {
+ u32 input_fourcc;
+ u32 bitrate;
+ u32 pic_w;
+ u32 pic_h;
+ u32 buf_w;
+ u32 buf_h;
+ u32 gop_size;
+ u32 intra_period;
+ u32 framerate;
+ u32 profile;
+ u32 level;
+ u32 wfd;
+};
+
+/*
+ * struct venc_h264_vpu_buf - Structure for buffer information
+ * @align: buffer alignment (in bytes)
+ * @iova: IO virtual address
+ * @vpua: VPU side memory addr which is used by RC_CODE
+ * @size: buffer size (in bytes)
+ */
+struct venc_h264_vpu_buf {
+ u32 align;
+ u32 iova;
+ u32 vpua;
+ u32 size;
+};
+
+/*
+ * struct venc_h264_vsi - Structure for VPU driver control and info share
+ * This structure is allocated in VPU side and shared to AP side.
+ * @config: h264 encoder configuration
+ * @work_bufs: working buffer information in VPU side
+ * The work_bufs here is for storing the 'size' info shared to AP side.
+ * The similar item in struct venc_h264_inst is for memory allocation
+ * in AP side. The AP driver will copy the 'size' from here to the one in
+ * struct mtk_vcodec_mem, then invoke mtk_vcodec_mem_alloc to allocate
+ * the buffer. After that, bypass the 'dma_addr' to the 'iova' field here for
+ * register setting in VPU side.
+ * @sizeimage: image size for each plane
+ */
+struct venc_h264_vsi {
+ struct v
[PATCH v7 2/8] [media] VPU: mediatek: support Mediatek VPU
From: Andrew-CT Chen The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs. It is able to handle video decoding/encoding of in a range of formats. The driver provides with VPU firmware download, memory management and the communication interface between CPU and VPU. For VPU initialization, it will create virtual memory for CPU access and IOMMU address for vcodec hw device access. When a decode/encode instance opens a device node, vpu driver will download vpu firmware to the device. A decode/encode instant will decode/encode a frame using VPU interface to interrupt vpu to handle decoding/encoding jobs. Signed-off-by: Andrew-CT Chen Signed-off-by: Tiffany Lin --- drivers/media/platform/Kconfig | 13 + drivers/media/platform/Makefile |2 + drivers/media/platform/mtk-vpu/Makefile |3 + drivers/media/platform/mtk-vpu/mtk_vpu.c | 950 ++ drivers/media/platform/mtk-vpu/mtk_vpu.h | 162 + 5 files changed, 1130 insertions(+) create mode 100644 drivers/media/platform/mtk-vpu/Makefile create mode 100755 drivers/media/platform/mtk-vpu/mtk_vpu.c create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 84e041c..74c3575 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -152,6 +152,19 @@ config VIDEO_CODA Coda is a range of video codec IPs that supports H.264, MPEG-4, and other video formats. +config VIDEO_MEDIATEK_VPU + tristate "Mediatek Video Processor Unit" + depends on VIDEO_DEV && VIDEO_V4L2 + depends on ARCH_MEDIATEK || COMPILE_TEST + ---help--- + This driver provides downloading VPU firmware and + communicating with VPU. This driver for hw video + codec embedded in Mediatek's MT8173 SOCs. It is able + to handle video decoding/encoding in a range of formats. + + To compile this driver as a module, choose M here: the + module will be called mtk-vpu. + config VIDEO_MEM2MEM_DEINTERLACE tristate "Deinterlace support" depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index bbb7bd1..2efb7b1 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -56,3 +56,5 @@ obj-$(CONFIG_VIDEO_AM437X_VPFE) += am437x/ obj-$(CONFIG_VIDEO_XILINX) += xilinx/ ccflags-y += -I$(srctree)/drivers/media/i2c + +obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu/ diff --git a/drivers/media/platform/mtk-vpu/Makefile b/drivers/media/platform/mtk-vpu/Makefile new file mode 100644 index 000..58cc1b4 --- /dev/null +++ b/drivers/media/platform/mtk-vpu/Makefile @@ -0,0 +1,3 @@ +mtk-vpu-y += mtk_vpu.o + +obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu.o diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c new file mode 100755 index 000..55c081e --- /dev/null +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c @@ -0,0 +1,950 @@ +/* +* Copyright (c) 2016 MediaTek Inc. +* Author: Andrew-CT Chen +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License version 2 as +* published by the Free Software Foundation. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +*/ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "mtk_vpu.h" + +/** + * VPU (video processor unit) is a tiny processor controlling video hardware + * related to video codec, scaling and color format converting. + * VPU interfaces with other blocks by share memory and interrupt. + **/ + +#define INIT_TIMEOUT_MS2000U +#define IPI_TIMEOUT_MS 2000U +#define VPU_FW_VER_LEN 16 + +/* maximum program/data TCM (Tightly-Coupled Memory) size */ +#define VPU_PTCM_SIZE (96 * SZ_1K) +#define VPU_DTCM_SIZE (32 * SZ_1K) +/* the offset to get data tcm address */ +#define VPU_DTCM_OFFSET0x18000UL +/* daynamic allocated maximum extended memory size */ +#define VPU_EXT_P_SIZE SZ_1M +#define VPU_EXT_D_SIZE SZ_4M +/* maximum binary firmware size */ +#define VPU_P_FW_SIZE (VPU_PTCM_SIZE + VPU_EXT_P_SIZE) +#define VPU_D_FW_SIZE (VPU_DTCM_SIZE + VPU_EXT_D_SIZE) +/* the size of share buffer between Host and VPU */ +#define SHARE_BUF_SIZE 48 + +/* binary firmware name */ +#define VPU_P_FW "vpu_p.bin" +#define VPU_D_FW "vpu_d.bin" + +#define VPU_RESET 0x0 +#define VPU_TCM_CFG0x0008 +#define
[PATCH v7 6/8] [media] vcodec: mediatek: Add Mediatek VP8 Video Encoder Driver
Add vp8 encoder driver for MT8173
Signed-off-by: PoChun Lin
Signed-off-by: Tiffany Lin
---
drivers/media/platform/mtk-vcodec/Makefile |6 +-
.../media/platform/mtk-vcodec/venc/venc_vp8_if.c | 488
drivers/media/platform/mtk-vcodec/venc_drv_if.c|7 +-
drivers/media/platform/mtk-vcodec/venc_vpu_if.c| 240 ++
drivers/media/platform/mtk-vcodec/venc_vpu_if.h| 61 +++
5 files changed, 800 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
create mode 100644 drivers/media/platform/mtk-vcodec/venc_vpu_if.c
create mode 100644 drivers/media/platform/mtk-vcodec/venc_vpu_if.h
diff --git a/drivers/media/platform/mtk-vcodec/Makefile
b/drivers/media/platform/mtk-vcodec/Makefile
index d04433be..bf73a45 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -1,12 +1,16 @@
+
obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-enc.o mtk-vcodec-common.o
-mtk-vcodec-enc-y := mtk_vcodec_enc.o \
+mtk-vcodec-enc-y := venc/venc_vp8_if.o \
+ venc/venc_h264_if.o \
+ mtk_vcodec_enc.o \
mtk_vcodec_enc_drv.o \
mtk_vcodec_enc_pm.o \
venc_drv_if.o \
+ venc_vpu_if.o \
mtk-vcodec-common-y := mtk_vcodec_intr.o \
mtk_vcodec_util.o\
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
new file mode 100644
index 000..5389841
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
@@ -0,0 +1,488 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Daniel Hsiao
+ * PoChun Lin
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+
+#include "../mtk_vcodec_drv.h"
+#include "../mtk_vcodec_util.h"
+#include "../mtk_vcodec_intr.h"
+#include "../mtk_vcodec_enc.h"
+#include "../mtk_vcodec_enc_pm.h"
+#include "../venc_drv_base.h"
+#include "../venc_ipi_msg.h"
+#include "../venc_vpu_if.h"
+#include "mtk_vpu.h"
+
+#define VENC_BITSTREAM_FRAME_SIZE 0x0098
+#define VENC_BITSTREAM_HEADER_LEN 0x00e8
+
+/* This ac_tag is vp8 frame tag. */
+#define MAX_AC_TAG_SIZE 10
+
+/**
+ * enum venc_vp8_vpu_work_buf - vp8 encoder buffer index
+ */
+enum venc_vp8_vpu_work_buf {
+ VENC_VP8_VPU_WORK_BUF_LUMA,
+ VENC_VP8_VPU_WORK_BUF_LUMA2,
+ VENC_VP8_VPU_WORK_BUF_LUMA3,
+ VENC_VP8_VPU_WORK_BUF_CHROMA,
+ VENC_VP8_VPU_WORK_BUF_CHROMA2,
+ VENC_VP8_VPU_WORK_BUF_CHROMA3,
+ VENC_VP8_VPU_WORK_BUF_MV_INFO,
+ VENC_VP8_VPU_WORK_BUF_BS_HEADER,
+ VENC_VP8_VPU_WORK_BUF_PROB_BUF,
+ VENC_VP8_VPU_WORK_BUF_RC_INFO,
+ VENC_VP8_VPU_WORK_BUF_RC_CODE,
+ VENC_VP8_VPU_WORK_BUF_RC_CODE2,
+ VENC_VP8_VPU_WORK_BUF_RC_CODE3,
+ VENC_VP8_VPU_WORK_BUF_MAX,
+};
+
+/*
+ * struct venc_vp8_vpu_config - Structure for vp8 encoder configuration
+ * @input_fourcc: input fourcc
+ * @bitrate: target bitrate (in bps)
+ * @pic_w: picture width. Picture size is visible stream resolution, in pixels,
+ * to be used for display purposes; must be smaller or equal to buffer
+ * size.
+ * @pic_h: picture height
+ * @buf_w: buffer width (with 16 alignment). Buffer size is stream resolution
+ * in pixels aligned to hardware requirements.
+ * @buf_h: buffer height (with 16 alignment)
+ * @gop_size: group of picture size (key frame)
+ * @framerate: frame rate in fps
+ * @ts_mode: temporal scalability mode (0: disable, 1: enable)
+ * support three temporal layers - 0: 7.5fps 1: 7.5fps 2: 15fps.
+ */
+struct venc_vp8_vpu_config {
+ u32 input_fourcc;
+ u32 bitrate;
+ u32 pic_w;
+ u32 pic_h;
+ u32 buf_w;
+ u32 buf_h;
+ u32 gop_size;
+ u32 framerate;
+ u32 ts_mode;
+};
+
+/*
+ * struct venc_vp8_vpu_buf -Structure for buffer information
+ * @align: buffer alignment (in bytes)
+ * @iova: IO virtual address
+ * @vpua: VPU side memory addr which is used by RC_CODE
+ * @size: buffer size (in bytes)
+ */
+struct venc_vp8_vpu_buf {
+ u32 align;
+ u32 iova;
+ u32 vpua;
+ u32 size;
+};
+
+/*
+ * struct venc_vp8_vsi - Structure for VPU driver control and info share
+ * This structure is allocated in VPU side and shared to AP side.
+ * @config: vp8 encoder configuration
+ * @work_bufs: working buffer information in VPU side
+ * The work_bufs here is for storing the 'size' info shared to AP side.
+ * The similar item in struct venc_vp8
[PATCH v7 3/8] arm64: dts: mediatek: Add node for Mediatek Video Processor Unit
From: Andrew-CT Chen
Add VPU drivers for MT8173
Signed-off-by: Andrew-CT Chen
Signed-off-by: Tiffany Lin
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index eab7efc..ae147bb 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -125,6 +125,18 @@
clock-output-names = "cpum_ck";
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ vpu_dma_reserved: vpu_dma_mem_region {
+ compatible = "shared-dma-pool";
+ reg = <0 0xb700 0 0x50>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <&gic>;
@@ -269,6 +281,17 @@
clock-names = "spi", "wrap";
};
+ vpu: vpu@1002 {
+ compatible = "mediatek,mt8173-vpu";
+ reg = <0 0x1002 0 0x3>,
+ <0 0x1005 0 0x100>;
+ reg-names = "tcm", "cfg_reg";
+ interrupts = ;
+ clocks = <&topckgen CLK_TOP_SCP_SEL>;
+ clock-names = "main";
+ memory-region = <&vpu_dma_reserved>;
+ };
+
sysirq: intpol-controller@10200620 {
compatible = "mediatek,mt8173-sysirq",
"mediatek,mt6577-sysirq";
--
1.7.9.5
Re: [PATCH] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs
Hi, Doug:
On 2016年04月22日 06:38, Doug Anderson wrote:
>
>>> + i2c1: i2c@ff11 {
>>> + compatible = "rockchip,rk3399-i2c";
>> David respun the rk3399 i2c-support on tuesday, so this and the others below
>> are waiting on Wolfram to take a look.
> I think it can work with the rk3288-i2c as a fallback, at least for
> low speed stuff, right? Should this be:
>
> compatible = "rockchip,rk3399-i2c", "rockchip,rk3288-i2c"
>
> Looks like that was done for rk3368.
No. For RK3399 I2C controller:
The I2C controller uses the APB clock/clk_i2c as the working clock. The
APB clock will determine the I2C bus clock, clk_i2c is the function clk,
up to 200MHz.
Chips such as RK3288/3368 only uses APB clock. So old driver do not work
on RK3399.
Thanks,
Huang, Tao
RE: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
> -Original Message-
> From: Han Xu
> Sent: Thursday, April 21, 2016 11:48 PM
> To: Yunhui Cui; Yunhui Cui; dw...@infradead.org;
> computersforpe...@gmail.com; han...@freescale.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; linux-
> arm-ker...@lists.infradead.org; Yao Yuan
> Subject: Re: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
>
>
>
>
> From: Yunhui Cui
> Sent: Thursday, April 21, 2016 3:41 AM
> To: Han Xu; Yunhui Cui; dw...@infradead.org; computersforpe...@gmail.com;
> han...@freescale.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; linux-
> arm-ker...@lists.infradead.org; Yao Yuan
> Subject: RE: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
>
> On Thu, Apr 24, 2016 at 06:37:01 AM +0800, Han Xu wrote:
> >
> > From: Yunhui Cui
> > Sent: Wednesday, April 13, 2016 9:50 PM
> > To: dw...@infradead.org; computersforpe...@gmail.com;
> > han...@freescale.com
> > Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org;
> > linux- arm-ker...@lists.infradead.org; Yao Yuan; Yunhui Cui
> > Subject: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
> >
> > From: Yunhui Cui
> >
> > A-009282: QuadSPI: QuadSPI data pre-fetch can result in incorrect data
> > Affects: QuadSPI
> > Description: With AHB buffer prefetch enabled, the QuadSPI may return
> > incorrect data on the AHB interface. The buffer pre-fetch is enabled
> > if the fetch size as configured either in the LUT or in the BUFxCR
> > register is greater than 8 bytes.
> > Impact: Only 64 bit read allowed.
> > Workaround: Keep the read data size to 64 bits (8 Bytes), which
> > disables the prefetch on the AHB buffer, and prevents this issue from
> occurring.
> >
> > Signed-off-by: Yunhui Cui
> > ---
> > drivers/mtd/spi-nor/fsl-quadspi.c | 29 +++--
> > 1 file changed, 23 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
> > b/drivers/mtd/spi-nor/fsl- quadspi.c index fea18b6..d9f3e50 100644
> > --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> > +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> > @@ -752,19 +752,36 @@ static void fsl_qspi_init_abh_read(struct
> > fsl_qspi
> > *q) {
> > void __iomem *base = q->iobase;
> > int seqid;
> > + const struct fsl_qspi_devtype_data *devtype_data =
> > + q->devtype_data;
> >
> > /* AHB configuration for access buffer 0/1/2 .*/
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF0CR);
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF1CR);
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF2CR);
> > +
> > /*
> > -* Set ADATSZ with the maximum AHB buffer size to improve the
> > -* read performance.
> > +* Errata: A-009282: QuadSPI data prefetch may result in
> > incorrect data
> > +* Workaround: Keep the read data size to 64 bits (8 bytes).
> > +* This disables the prefetch on the AHB buffer and
> > +* prevents this issue from occurring.
> > */
> > - qspi_writel(q, QUADSPI_BUF3CR_ALLMST_MASK |
> > - ((q->devtype_data->ahb_buf_size / 8)
> > - << QUADSPI_BUF3CR_ADATSZ_SHIFT),
> > - base + QUADSPI_BUF3CR);
> > + if (devtype_data->devtype == FSL_QUADSPI_LS2080A ||
> > + devtype_data->devtype == FSL_QUADSPI_LS1021A) {
> >
> > Use QUIRK, not SoC name.
> [Yunhui] This is a SoC errata, we need distinguish according to the
> devtype_data->devtype
>
> It's the same thing and we have already done that before.
> [Yunhui] your mean that I should add such as the following code:
#define QUADSPI_QUIRK_ERRATA_9282 (1 << 4)
static inline int has_errata_num_a009282(struct fsl_qspi *q)
{
return q->devtype_data->driver_data &
QUADSPI_QUIRK_ERRATA_9282;
}
> /*
> * TKT253890, Controller needs driver to fill txfifo till 16 byte to
> * trigger data transfer even though extra data will not transferred.
> */
> #define QUADSPI_QUIRK_TKT253890 (1 << 2)
> /* Controller cannot wake up from wait mode, TKT245618 */
> #define QUADSPI_QUIRK_TKT245618 (1 << 3)
>
>
> > +
> > + qspi_writel(q, QUADSPI_BUF3CR_ALLMST_MASK |
> > + (1 << QUADSPI_BUF3CR_ADATSZ_SHIFT),
> > + base + QUADSPI_BUF3CR);
> > +
> > + } else {
> > + /*
> > +* Set ADATSZ with the maximum AHB buffer size to
> > + improve
> > the
> > +* read performance.
> > + */
> > + qspi_writel(q, QUADSPI_BUF3CR_ALLMST_MASK |
> > + ((q->devtype_data->ahb_buf_size / 8)
> > + << QUADSPI_BUF3CR_ADATSZ_SHIFT),
> > +
Re: [PATCH V4] audit: add tty field to LOGIN event
On 16/04/21, Paul Moore wrote:
> On Thu, Apr 21, 2016 at 2:14 PM, Richard Guy Briggs wrote:
> > The tty field was missing from AUDIT_LOGIN events.
> >
> > Refactor code to create a new function audit_get_tty(), using it to
> > replace the call in audit_log_task_info() and to add it to
> > audit_log_set_loginuid(). Lock and bump the kref to protect it, adding
> > audit_put_tty() alias to decrement it.
> >
> > Signed-off-by: Richard Guy Briggs
> > ---
> >
> > V4: Add missing prototype for audit_put_tty() when audit syscall is not
> > enabled (MIPS).
> >
> > V3: Introduce audit_put_tty() alias to decrement kref.
> >
> > V2: Use kref to protect tty signal struct while in use.
> >
> > ---
> >
> > include/linux/audit.h | 24
> > kernel/audit.c| 18 +-
> > kernel/auditsc.c |8 ++--
> > 3 files changed, 35 insertions(+), 15 deletions(-)
> >
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index b40ed5d..32cdafb 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -26,6 +26,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #define AUDIT_INO_UNSET ((unsigned long)-1)
> > #define AUDIT_DEV_UNSET ((dev_t)-1)
> > @@ -343,6 +344,23 @@ static inline unsigned int audit_get_sessionid(struct
> > task_struct *tsk)
> > return tsk->sessionid;
> > }
> >
> > +static inline struct tty_struct *audit_get_tty(struct task_struct *tsk)
> > +{
> > + struct tty_struct *tty = NULL;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&tsk->sighand->siglock, flags);
> > + if (tsk->signal)
> > + tty = tty_kref_get(tsk->signal->tty);
> > + spin_unlock_irqrestore(&tsk->sighand->siglock, flags);
> > + return tty;
> > +}
> > +
> > +static inline void audit_put_tty(struct tty_struct *tty)
> > +{
> > + tty_kref_put(tty);
> > +}
>
> I'm generally not a big fan of defining functions as inlines in header
> files, with the general exception of dummy functions that will get
> compiled out. Although I guess there might be some performance
> argument to be made wrt audit_log_task_info().
I did reflect on that initially and decided this was the least
disruptive way to implement it. There are others similar around it and
when I started it wasn't as involved, but now it is starting to push the
limits with the kref bits...
> I guess I'm fine with this, but what was the idea behind the static
> inlines in audit.h? Performance, or something else?
Can't say I remember... I was tempted to put it in as a define, but
decided to stick with the existing style, right? :-)
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index 195ffae..71e14d8 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -1980,6 +1980,7 @@ static void audit_log_set_loginuid(kuid_t
> > koldloginuid, kuid_t kloginuid,
> > {
> > struct audit_buffer *ab;
> > uid_t uid, oldloginuid, loginuid;
> > + struct tty_struct *tty;
> >
> > if (!audit_enabled)
> > return;
> > @@ -1987,14 +1988,17 @@ static void audit_log_set_loginuid(kuid_t
> > koldloginuid, kuid_t kloginuid,
> > uid = from_kuid(&init_user_ns, task_uid(current));
> > oldloginuid = from_kuid(&init_user_ns, koldloginuid);
> > loginuid = from_kuid(&init_user_ns, kloginuid),
> > + tty = audit_get_tty(current);
> >
> > ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_LOGIN);
> > if (!ab)
> > return;
> > audit_log_format(ab, "pid=%d uid=%u", task_pid_nr(current), uid);
> > audit_log_task_context(ab);
> > - audit_log_format(ab, " old-auid=%u auid=%u old-ses=%u ses=%u
> > res=%d",
> > -oldloginuid, loginuid, oldsessionid, sessionid,
> > !rc);
> > + audit_log_format(ab, " old-auid=%u auid=%u tty=%s old-ses=%u ses=%u
> > res=%d",
> > +oldloginuid, loginuid, tty ? tty_name(tty) :
> > "(none)",
> > +oldsessionid, sessionid, !rc);
> > + audit_put_tty(tty);
> > audit_log_end(ab);
> > }
>
> Because we are still using the crappy fixed string format for
> kernel<->userspace communication, this patch will likely "break the
> world" ... let's check with Steve but I believe the way to handle this
> is to add the tty information to the end of the record.
Well, I did try to put that keyword consistently with where it was
inserted in other messages. My understanding was that adding an extra
in the middle wouldn't cause a problem because the keyword scanner
looked ahead until it found the keyword it sought. This way, older
scanners will just hop over this keyword it wasn't seeking.
> paul moore
- RGB
--
Richard Guy Briggs
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
[PATCH] iio: tmp006: Set correct iio name
When load the driver using the below command: echo tmp006 0x40 > /sys/bus/i2c/devices/i2c-0/new_device In sysfs, the i2c name is tmp006, however the iio name is 0-0040, they are inconsistent. With this patch, the iio name will be the same as the i2c device name Signed-off-by: Yong Li --- drivers/iio/temperature/tmp006.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/temperature/tmp006.c b/drivers/iio/temperature/tmp006.c index 18c9b43..17c8413 100644 --- a/drivers/iio/temperature/tmp006.c +++ b/drivers/iio/temperature/tmp006.c @@ -221,7 +221,7 @@ static int tmp006_probe(struct i2c_client *client, data->client = client; indio_dev->dev.parent = &client->dev; - indio_dev->name = dev_name(&client->dev); + indio_dev->name = id->name; indio_dev->modes = INDIO_DIRECT_MODE; indio_dev->info = &tmp006_info; -- 2.5.0
Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
On Fri, Apr 22, 2016 at 09:26:46AM +0800, Peter Chen wrote:
> On Fri, Apr 15, 2016 at 10:03:16AM +, Yoshihiro Shimoda wrote:
> > Hi,
> >
> > > From: Yoshihiro Shimoda
> > > Sent: Friday, April 15, 2016 6:59 PM
> > >
> > > Hi,
> > >
> > > > From: Roger Quadros
> > > > Sent: Thursday, April 14, 2016 8:32 PM
> > > >
> > > > On 14/04/16 14:15, Yoshihiro Shimoda wrote:
> > > > > Hi,
> > > > >
> > > < snip >
> > > > >>> @@ -865,7 +867,8 @@ int usb_otg_register_hcd(struct usb_hcd *hcd,
> > > > >>> unsigned int irqnum,
> > > > >>> * we're ready only if we have shared HCD
> > > > >>> * or we don't need shared HCD.
> > > > >>> */
> > > > >>> - if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
> > > > >>> + if (otg->shared_hcd.hcd || (!otg->caps->needs_companion &&
> > > > >>> + !otg->primary_hcd.hcd->shared_hcd))
> > > > >>> {
> > > > >>> otg->host = hcd_to_bus(hcd);
> > > > >>> /* FIXME: set bus->otg_port if this is true OTG port
> > > > >>> with HNP */
> > > > >>>
> > > > >>
> > > > >> These changes look good to me. Thanks.
> > > > >
> > > > > Thank you for the comment.
> > > > > If we change the "needs_companion" place to the otg_config,
> > > > > do we need to add a flag into the otg, instead of otg->caps?
> > > >
> > > > Yes we can add a flag in struct usb_otg.
> > >
> > > Thank you for the comment.
> > >
> > > I made a fixed patch.
> > > So, should I send this patch to ML after you sent v7 patches?
> > > Or, would you apply this patch before you send v7 patches?
> >
> > Oops, I sent this email without my patch...
> >
> > ---
> > Subject: [PATCH] usb: otg: add hcd companion support
> >
> > Since some host controller (e.g. EHCI) needs a companion host controller
> > (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> > core.
> >
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > Documentation/devicetree/bindings/usb/generic.txt | 3 +++
> > drivers/usb/common/usb-otg.c | 17 +
> > include/linux/usb/otg.h | 7 ++-
> > 3 files changed, 22 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt
> > b/Documentation/devicetree/bindings/usb/generic.txt
> > index f6866c1..1db1c33 100644
> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > @@ -27,6 +27,9 @@ Optional properties:
> > - otg-controller: phandle to otg controller. Host or gadget controllers
> > can
> > contain this property to link it to a particular OTG
> > controller.
> > + - hcd-needs-companion: must be present if otg controller is dealing with
> > + EHCI host controller that needs a companion OHCI host
> > + controller.
> >
> > This is an attribute to a USB controller such as:
> >
> > diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> > index 41e762a..83c8c96 100644
> > --- a/drivers/usb/common/usb-otg.c
> > +++ b/drivers/usb/common/usb-otg.c
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -600,6 +601,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
> > else
> > INIT_WORK(&otg->work, usb_otg_work);
> >
> > + if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
> > + config->hcd_needs_companion)/* needs comanion ? */
> > + otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
> > +
> > otg->wq = create_singlethread_workqueue("usb_otg");
> > if (!otg->wq) {
> > dev_err(dev, "otg: %s: can't create workqueue\n",
> > @@ -823,13 +828,15 @@ int usb_otg_register_hcd(struct usb_hcd *hcd,
> > unsigned int irqnum,
> > /* HCD will be started by OTG fsm when needed */
> > mutex_lock(&otg->fsm.lock);
> > if (otg->primary_hcd.hcd) {
> > - /* probably a shared HCD ? */
> > - if (usb_otg_hcd_is_primary_hcd(hcd)) {
> > + /* probably a shared HCD or a companion OHCI HCD ? */
> > + if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
> > + usb_otg_hcd_is_primary_hcd(hcd)) {
> > dev_err(otg_dev, "otg: primary host already
> > registered\n");
> > goto err;
> > }
> >
> > - if (hcd->shared_hcd == otg->primary_hcd.hcd) {
> > + if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
> > + (hcd->shared_hcd == otg->primary_hcd.hcd)) {
> > if (otg->shared_hcd.hcd) {
> > dev_err(otg_dev, "otg: shared host already
> > registered\n");
> > goto err;
> > @@ -865,7 +872,9 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned
> > int irqnum,
> > * we're ready only if we have shared HCD
>
Re: [PATCH] Revert "cpufreq: governor: Fix negative idle_time when configured with CONFIG_HZ_PERIODIC"
On 21-04-16, 20:57, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Revert commit 0df35026c6a5 (cpufreq: governor: Fix negative idle_time
> when configured with CONFIG_HZ_PERIODIC) that introduced a regression
> by causing the ondemand cpufreq governor to misbehave for
> CONFIG_TICK_CPU_ACCOUNTING unset (the frequency goes up to the max at
> one point and stays there indefinitely).
>
> The revert takes subsequent modifications of the code in question into
> account.
>
> Fixes: 0df35026c6a5 (cpufreq: governor: Fix negative idle_time when
> configured with CONFIG_HZ_PERIODIC)
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=115261
> Reported-and-tested-by: Timo Valtoaho
> Cc: 4.5+ # 4.5+
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/cpufreq/cpufreq_governor.c |8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
> +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
> @@ -146,12 +146,8 @@ unsigned int dbs_update(struct cpufreq_p
> wall_time = cur_wall_time - j_cdbs->prev_cpu_wall;
> j_cdbs->prev_cpu_wall = cur_wall_time;
>
> - if (cur_idle_time <= j_cdbs->prev_cpu_idle) {
> - idle_time = 0;
> - } else {
> - idle_time = cur_idle_time - j_cdbs->prev_cpu_idle;
> - j_cdbs->prev_cpu_idle = cur_idle_time;
> - }
> + idle_time = cur_idle_time - j_cdbs->prev_cpu_idle;
> + j_cdbs->prev_cpu_idle = cur_idle_time;
>
> if (ignore_nice) {
> u64 cur_nice = kcpustat_cpu(j).cpustat[CPUTIME_NICE];
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH v3 2/6] sched/rtmutex/deadline: Fix a PI crash for deadline tasks
Hi Peter,
On 2016/04/20 at 21:49, Xunlei Pang wrote:
> On 2016/04/20 at 21:19, Peter Zijlstra wrote:
>> On Thu, Apr 14, 2016 at 07:37:03PM +0800, Xunlei Pang wrote:
>>> + /* Updated under pi_lock and rtmutex lock */
>>> struct rb_node *pi_waiters_leftmost;
>>> + struct rb_node *pi_waiters_leftmost_copy;
>>> struct task_struct *rt_mutex_get_top_task(struct task_struct *task)
>>> {
>>> + if (!task->pi_waiters_leftmost_copy)
>>> return NULL;
>>>
>>> + return rb_entry(task->pi_waiters_leftmost_copy,
>>> + struct rt_mutex_waiter, pi_tree_entry)->task;
>>> }
>> why ?! Why not keep a regular task_struct pointer and avoid this stuff?
> I meant to make it semantically consistent, but I can change it since you
> think task_struct is better.
What do you think this version of PATCH1 and PATCH2?
If you are fine with it, I can sent it out as v4 separately, then we can focus
on the issue in PATCH5.
Thanks!
>
> Regards,
> Xunlei
Re: [PATCH 5/8] cpufreq: shmobile: Use generic platdev driver
On 21-04-16, 15:04, Geert Uytterhoeven wrote:
> Hi Viresh,
>
> On Thu, Apr 21, 2016 at 10:43 AM, Viresh Kumar
> wrote:
> > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> > @@ -29,6 +29,18 @@ static const struct of_device_id machines[] = {
> > { .compatible = "samsung,exynos5800", },
> > #endif
> >
>
> I think an #ifdef CONFIG_ARCH_RENESAS block wouldn't hurt, likewise
> for the other SoCs.
> Soon you'll have this file filled with lots of compatible values for random\
> SoCs...
This is going to be done once per boot and this shouldn't hurt. And for new
platforms we may do things differently as they are going to use opp-v2 bindings.
And, so I am not really in favor of ifdef hackery :)
--
viresh
[PATCH] PM / OPP: -ENOSYS is applicable only to syscalls
Some of the routines have use -ENOSYS, which is supposed to be used only
for syscalls. Replace that with -EINVAL.
Signed-off-by: Viresh Kumar
---
I am including this patch into the series and this one will be the first
patch of the series. Also, later patches will be updated to *not* use
-ENOSYS.
I will send out the series again once some sort of reviews are done.
include/linux/pm_opp.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index cccaf4a29e9f..2605ed66f1bd 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -199,7 +199,7 @@ static inline void dev_pm_opp_of_remove_table(struct device
*dev)
static inline int dev_pm_opp_of_cpumask_add_table(cpumask_var_t cpumask)
{
- return -ENOSYS;
+ return -EINVAL;
}
static inline void dev_pm_opp_of_cpumask_remove_table(cpumask_var_t cpumask)
@@ -208,12 +208,12 @@ static inline void
dev_pm_opp_of_cpumask_remove_table(cpumask_var_t cpumask)
static inline int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev,
cpumask_var_t cpumask)
{
- return -ENOSYS;
+ return -EINVAL;
}
static inline int dev_pm_opp_set_sharing_cpus(struct device *cpu_dev,
cpumask_var_t cpumask)
{
- return -ENOSYS;
+ return -EINVAL;
}
#endif
--
2.7.1.410.g6faf27b
Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16
On Fri, Apr 22, 2016 at 09:59:22AM +0800, Pan Xinhui wrote:
> On 2016年04月21日 23:52, Boqun Feng wrote:
> > On Thu, Apr 21, 2016 at 11:35:07PM +0800, Pan Xinhui wrote:
> >> On 2016年04月20日 22:24, Peter Zijlstra wrote:
> >>> On Wed, Apr 20, 2016 at 09:24:00PM +0800, Pan Xinhui wrote:
> >>>
> +#define __XCHG_GEN(cmp, type, sfx, skip, v)
> \
> +static __always_inline unsigned long
> \
> +__cmpxchg_u32##sfx(v unsigned int *p, unsigned long old,
> \
> + unsigned long new);
> \
> +static __always_inline u32
> \
> +__##cmp##xchg_##type##sfx(v void *ptr, u32 old, u32 new)
> \
> +{
> \
> +int size = sizeof (type);
> \
> +int off = (unsigned long)ptr % sizeof(u32);
> \
> +volatile u32 *p = ptr - off;
> \
> +int bitoff = BITOFF_CAL(size, off);
> \
> +u32 bitmask = ((0x1 << size * BITS_PER_BYTE) - 1) << bitoff;
> \
> +u32 oldv, newv, tmp;
> \
> +u32 ret;
> \
> +oldv = READ_ONCE(*p);
> \
> +do {
> \
> +ret = (oldv & bitmask) >> bitoff;
> \
> +if (skip && ret != old)
> \
> +break;
> \
> +newv = (oldv & ~bitmask) | (new << bitoff);
> \
> +tmp = oldv;
> \
> +oldv = __cmpxchg_u32##sfx((v u32*)p, oldv, newv);
> \
> +} while (tmp != oldv);
> \
> +return ret;
> \
> +}
> >>>
> >>> So for an LL/SC based arch using cmpxchg() like that is sub-optimal.
> >>>
> >>> Why did you choose to write it entirely in C?
> >>>
> >> yes, you are right. more load/store will be done in C code.
> >> However such xchg_u8/u16 is just used by qspinlock now. and I did not see
> >> any performance regression.
> >> So just wrote in C, for simple. :)
> >>
> >> Of course I have done xchg tests.
> >> we run code just like xchg((u8*)&v, j++); in several threads.
> >> and the result is,
> >> [ 768.374264] use time[1550072]ns in xchg_u8_asm
> >
> > How was xchg_u8_asm() implemented, using lbarx or using a 32bit ll/sc
> > loop with shifting and masking in it?
> >
> yes, using 32bit ll/sc loops.
>
> looks like:
> __asm__ __volatile__(
> "1: lwarx %0,0,%3\n"
> " and %1,%0,%5\n"
> " or %1,%1,%4\n"
>PPC405_ERR77(0,%2)
> " stwcx. %1,0,%3\n"
> " bne-1b"
> : "=&r" (_oldv), "=&r" (tmp), "+m" (*(volatile unsigned int *)_p)
> : "r" (_p), "r" (_newv), "r" (_oldv_mask)
> : "cc", "memory");
>
Good, so this works for all ppc ISAs too.
Given the performance benefit(maybe caused by the reason Peter
mentioned), I think we should use this as the implementation of u8/u16
{cmp}xchg for now. For Power7 and later, we can always switch to the
lbarx/lharx version if observable performance benefit can be achieved.
But the choice is left to you. After all, as you said, qspinlock is the
only user ;-)
Regards,
Boqun
>
> > Regards,
> > Boqun
> >
> >> [ 768.377102] use time[2826802]ns in xchg_u8_c
> >>
> >> I think this is because there is one more load in C.
> >> If possible, we can move such code in asm-generic/.
> >>
> >> thanks
> >> xinhui
> >>
>
signature.asc
Description: PGP signature
Re: [PATCH 1/5] x86, KASLR: Update description for decompressor worst case size
On 04/21/16 at 01:04pm, Kees Cook wrote:
> On Thu, Apr 21, 2016 at 7:47 AM, Borislav Petkov wrote:
> > On Wed, Apr 20, 2016 at 01:55:42PM -0700, Kees Cook wrote:
> > ...
> > What's "non compressed data overhead"?
> >
> > Does that want to say:
> >
> > "... resulting in 18 bytes overhead of uncompressed data."
> >
> > perhaps?
>
> Yeah, that reads much more clearly. I'll change it.
>
> >> +#
> >> +# Files divided into blocks
> >> +# 1 bit (last block flag)
> >> +# 2 bits (block type)
> >> +#
> >> +# 1 block occurs every 32K -1 bytes or when there 50% compression
> >> +# has been achieved. The smallest block type encoding is always used.
> >> +#
> >> +# stored:
> >> +#32 bits length in bytes.
> >> +#
> >> +# fixed:
> >> +#magic fixed tree.
> >> +#symbols.
> >> +#
> >> +# dynamic:
> >> +#dynamic tree encoding.
> >> +#symbols.
> >> +#
> >> +#
> >> +# The buffer for decompression in place is the length of the uncompressed
> >> +# data, plus a small amount extra to keep the algorithm safe. The
> >> +# compressed data is placed at the end of the buffer. The output pointer
> >> +# is placed at the start of the buffer and the input pointer is placed
> >> +# where the compressed data starts. Problems will occur when the output
> >> +# pointer overruns the input pointer.
> >> +#
> >> +# The output pointer can only overrun the input pointer if the input
> >> +# pointer is moving faster than the output pointer. A condition only
> >> +# triggered by data whose compressed form is larger than the uncompressed
> >> +# form.
> >> +#
> >> +# The worst case at the block level is a growth of the compressed data
> >> +# of 5 bytes per 32767 bytes.
> >> +#
> >> +# The worst case internal to a compressed block is very hard to figure.
> >> +# The worst case can at least be bounded by having one bit that represents
> >> +# 32764 bytes and then all of the rest of the bytes representing the very
> >> +# very last byte.
> >> +#
> >> +# All of which is enough to compute an amount of extra data that is
> >> required
> >> +# to be safe. To avoid problems at the block level allocating 5 extra
> >> bytes
> >> +# per 32767 bytes of data is sufficient. To avoid problems internal to a
> >> +# block adding an extra 32767 bytes (the worst case uncompressed block
> >> size)
> >> +# is sufficient, to ensure that in the worst case the decompressed data
> >> for
> >> +# block will stop the byte before the compressed data for a block begins.
> >> +# To avoid problems with the compressed data's meta information an extra
> >> 18
> >> +# bytes are needed. Leading to the formula:
> >> +#
> >> +# extra_bytes = (uncompressed_size >> 12) + 32768 + 18 + decompressor_size
> >> +#
> >> +# Adding 8 bytes per 32K is a bit excessive but much easier to calculate.
> >> +# Adding 32768 instead of 32767 just makes for round numbers.
> >> +# Adding the decompressor_size is necessary as it musht live after all
> >> +# of the data as well. Last I measured the decompressor is about 14K.
> >> +# 10K of actual data and 4K of bss.
> >
> > I guess reflow the paragraphs while at it, as well?
> >
> > "Adding 8 bytes per 32K is a bit excessive but much easier to calculate.
> > Adding 32768 instead of 32767 just makes for round numbers. Adding the
> > decompressor_size is necessary as it musht live after all of the data as
~~must
There's a typo here, it should be 'must'. I didn't notice before. It
might be fixed when take Boris's paragraph reflowing. :)
> > well. Last I measured the decompressor is about 14K. 10K of actual data
> > and 4K of bss."
> >
> > and so on...
>
> Yeah, I'd been reflowing as I went and I went back and forth on that
> one. It looked like it was a list ("Adding... Adding... Adding...") so
> I'd left it, but my initial instinct matches your: it should just get
> reflowed like all the rest.
>
> I'll fix that too.
>
> Thanks for the review!
>
> -Kees
>
> --
> Kees Cook
> Chrome OS & Brillo Security
Re: [RFC][PATCH 0/6] /dev/random - a new approach
I still have a massive problem with the claims that the "Jitter" RNG provides any amount of entropy. Just because you and I might not be able to analyze it doesn't mean that somebody else couldn't. After all, DUAL-EC DRNG was very complicated and hard to analyze. So would be something like AES(NSA_KEY, COUNTER++) Very hard to analyze indeed. Shall we run statistical tests? They'll pass with flying colors. Secure? Not so much. - Ted
Re: [PATCH v2 all 00/14] use of_platform_default_populate() to populate default bus
On 2016/4/21 21:10, Rob Herring wrote:
> On Thu, Apr 21, 2016 at 2:55 AM, Kefeng Wang
> wrote:
>> Hi Rob,
>>
>> On 2016/4/20 5:10, Rob Herring wrote:
>>> On Wed, Mar 16, 2016 at 2:35 AM, Kefeng Wang
>>> wrote:
Use helper of_platform_default_populate() in linux/of_platform
when possible, instead of calling of_platform_populate() with
the default match table.
Then it is possible for driver code build as a module, and no
need to export of_default_bus_match_table anymore.
This patchset is based on Linux 4.5.
Changes since v1:
- Add ack, test and review
- Remove v1 patch 14/15, the similar patch has posted and applied,
see https://patchwork.kernel.org/patch/8096991/
v1:
- https://lkml.org/lkml/2016/1/26/1123
>>>
>>> I was going to apply this, but I've thought about this some more and
>>> it is a lot of tree wide churn for little gain. Most of the call sites
>>> here I want to get rid of by making of_platform_populate callable
>>> multiple times. The infrastructure is almost there, but I think we
>>> just need something like this:
>>>
>>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>>> index 8d103e4..b25e710 100644
>>> --- a/drivers/of/platform.c
>>> +++ b/drivers/of/platform.c
>>> @@ -345,6 +345,9 @@ static int of_platform_bus_create(struct device_node
>>> *bus,
>>> return 0;
>>> }
>>>
>>> + if (of_node_check_flag(bus, OF_POPULATED_BUS))
>>> + return 0;
>>> +
>>> auxdata = of_dev_lookup(lookup, bus);
>>> if (auxdata) {
>>> bus_id = auxdata->name;
>>>
>>> Then we can call of_platform_populate from the DT core and remove all
>>> the default calls.
>>
>> OK, it seems that we can drop all the of_of_platform_default_populate in
>> arch code
>> by this changes, will do it.
>>
>> But replace of_platform_populate() with the default match table by
>> of_platform_default_populate
>> is a cleanup, and especially for the driver, we can not need export
>> of_default_bus_match_table
>> after that.
>>
>> There is a v3 patchset[1], it is based 4.6-rc2 with some updated, should
>> this be merge firstly,
>> then drop all the default of_platform_populate in arch code, and I think the
>> of_iommu_init() in
>> arch code could do the same thing.
>>
>> If not, I will repost the patches with new ways, but still exists the part
>> of unexport
>> of_default_bus_match_table by helper of_platform_default_populate().
>>
>> Hope the v3 patchset could be merge in advance, after all, it has been
>> reviewed fully. Thanks a lot.
>
> We'd be touching the same line twice in a bunch of places if we apply
> this series first, so it makes more sense to remove all these calls
> first and then use of_platform_default_populate where it is still
> needed.
Agree, will repost them.
BRs,
Kefeng
>
> Rob
>
> .
>
Re: [RFC][PATCH 2/4] tracing: Use pid bitmap instead of a pid array for set_event_pid
Hi Steve,
On Tue, Apr 19, 2016 at 10:34:23AM -0400, Steven Rostedt wrote:
> From: Steven Rostedt
>
> In order to add the ability to let tasks that are filtered by the events
> have their children also be traced on fork (and then not traced on exit),
> convert the array into a pid bitmask. Most of the time the number of pids is
> only 32768 pids or a 4k bitmask, which is the same size as the default list
> currently is, and that list could grow if more pids are listed.
>
> This also greatly simplifies the code.
>
> Suggested-by: "H. Peter Anvin"
> Signed-off-by: Steven Rostedt
> ---
[SNIP]
> @@ -1571,7 +1572,7 @@ ftrace_event_pid_write(struct file *filp, const char
> __user *ubuf,
> struct seq_file *m = filp->private_data;
> struct trace_array *tr = m->private;
> struct trace_pid_list *filtered_pids = NULL;
> - struct trace_pid_list *pid_list = NULL;
> + struct trace_pid_list *pid_list;
> struct trace_event_file *file;
> struct trace_parser parser;
> unsigned long val;
> @@ -1579,7 +1580,7 @@ ftrace_event_pid_write(struct file *filp, const char
> __user *ubuf,
> ssize_t read = 0;
> ssize_t ret = 0;
> pid_t pid;
> - int i;
> + int nr_pids = 0;
>
> if (!cnt)
> return 0;
> @@ -1592,10 +1593,43 @@ ftrace_event_pid_write(struct file *filp, const char
> __user *ubuf,
> return -ENOMEM;
>
> mutex_lock(&event_mutex);
> + filtered_pids = rcu_dereference_protected(tr->filtered_pids,
> + lockdep_is_held(&event_mutex));
> +
> /*
> - * Load as many pids into the array before doing a
> - * swap from the tr->filtered_pids to the new list.
> + * Always recreate a new array. The write is an all or nothing
> + * operation. Always create a new array when adding new pids by
> + * the user. If the operation fails, then the current list is
> + * not modified.
>*/
> + pid_list = kmalloc(sizeof(*pid_list), GFP_KERNEL);
> + if (!pid_list) {
> + read = -ENOMEM;
> + goto out;
> + }
> + pid_list->pid_max = READ_ONCE(pid_max);
> + /* Only truncating will shrink pid_max */
> + if (filtered_pids && filtered_pids->pid_max > pid_list->pid_max)
> + pid_list->pid_max = filtered_pids->pid_max;
> + pid_list->pids = vzalloc((pid_list->pid_max + 7) >> 3);
> + if (!pid_list->pids) {
> + kfree(pid_list);
> + read = -ENOMEM;
> + goto out;
> + }
> + if (filtered_pids) {
> + /* copy the current bits to the new max */
> + pid = find_first_bit(filtered_pids->pids,
> + filtered_pids->pid_max);
> + while (pid < filtered_pids->pid_max) {
> + set_bit(pid, pid_list->pids);
> + pid = find_next_bit(filtered_pids->pids,
> + filtered_pids->pid_max,
> + pid + 1);
> + nr_pids++;
> + }
Why not just use memcpy and keep nr_pids in the pid_list?
Thanks,
Namhyung
> + }
> +
> while (cnt > 0) {
>
> this_pos = 0;
> @@ -1613,92 +1647,35 @@ ftrace_event_pid_write(struct file *filp, const char
> __user *ubuf,
> ret = -EINVAL;
> if (kstrtoul(parser.buffer, 0, &val))
> break;
> - if (val > INT_MAX)
> + if (val >= pid_list->pid_max)
> break;
>
> pid = (pid_t)val;
>
> - ret = -ENOMEM;
> - if (!pid_list) {
> - pid_list = kmalloc(sizeof(*pid_list), GFP_KERNEL);
> - if (!pid_list)
> - break;
> -
> - filtered_pids =
> rcu_dereference_protected(tr->filtered_pids,
> -
> lockdep_is_held(&event_mutex));
> - if (filtered_pids)
> - pid_list->order = filtered_pids->order;
> - else
> - pid_list->order = 0;
> -
> - pid_list->pids = (void *)__get_free_pages(GFP_KERNEL,
> -
> pid_list->order);
> - if (!pid_list->pids)
> - break;
> -
> - if (filtered_pids) {
> - pid_list->nr_pids = filtered_pids->nr_pids;
> - memcpy(pid_list->pids, filtered_pids->pids,
> -pid_list->nr_pids * sizeof(pid_t));
> - } else
> - pid_list->nr_pids = 0;
> - }
> -
> - if (pid_list->nr_pids >= max_pids(pid_list)) {
> - pid_t *pid_page;
> -
> -
Re: [PATCH V3 05/11] staging: mt29f_spinand: set ECC algorithm explicitly
On Thu, Apr 21, 2016 at 10:20:56PM +0200, Boris Brezillon wrote: > Hi Greg, > > On Sun, 17 Apr 2016 22:53:01 +0200 > Rafał Miłecki wrote: > > > This is part of process deprecating NAND_ECC_SOFT_BCH (and switching to > > enum nand_ecc_algo). > > Do you mind if I take this patch through the NAND tree in order to avoid > dependency problems? Not at all: Acked-by: Greg Kroah-Hartman
linux-next: build failure after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/notifier.h:13:0,
from include/linux/memory_hotplug.h:6,
from include/linux/mmzone.h:744,
from include/linux/gfp.h:5,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from sound/soc/codecs/hdmi-codec.c:15:
sound/soc/codecs/hdmi-codec.c: In function 'hdmi_eld_ctl_get':
sound/soc/codecs/hdmi-codec.c:68:17: error: 'struct hdmi_codec_priv' has no
member named 'eld_lock'
mutex_lock(&hcp->eld_lock);
^
include/linux/mutex.h:146:44: note: in definition of macro 'mutex_lock'
#define mutex_lock(lock) mutex_lock_nested(lock, 0)
^
sound/soc/codecs/hdmi-codec.c:70:19: error: 'struct hdmi_codec_priv' has no
member named 'eld_lock'
mutex_unlock(&hcp->eld_lock);
^
Caused by commit
81151cfb6bfe ("ASoC: hdmi-codec: Add ELD control")
I have used the sound-asoc tree from next-20160421 for today.
--
Cheers,
Stephen Rothwell
Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16
On 2016年04月21日 23:52, Boqun Feng wrote:
> On Thu, Apr 21, 2016 at 11:35:07PM +0800, Pan Xinhui wrote:
>> On 2016年04月20日 22:24, Peter Zijlstra wrote:
>>> On Wed, Apr 20, 2016 at 09:24:00PM +0800, Pan Xinhui wrote:
>>>
+#define __XCHG_GEN(cmp, type, sfx, skip, v)
\
+static __always_inline unsigned long
\
+__cmpxchg_u32##sfx(v unsigned int *p, unsigned long old, \
+ unsigned long new);\
+static __always_inline u32
\
+__##cmp##xchg_##type##sfx(v void *ptr, u32 old, u32 new) \
+{ \
+ int size = sizeof (type); \
+ int off = (unsigned long)ptr % sizeof(u32); \
+ volatile u32 *p = ptr - off;\
+ int bitoff = BITOFF_CAL(size, off); \
+ u32 bitmask = ((0x1 << size * BITS_PER_BYTE) - 1) << bitoff;\
+ u32 oldv, newv, tmp;\
+ u32 ret;\
+ oldv = READ_ONCE(*p); \
+ do {\
+ ret = (oldv & bitmask) >> bitoff; \
+ if (skip && ret != old) \
+ break; \
+ newv = (oldv & ~bitmask) | (new << bitoff); \
+ tmp = oldv; \
+ oldv = __cmpxchg_u32##sfx((v u32*)p, oldv, newv); \
+ } while (tmp != oldv); \
+ return ret; \
+}
>>>
>>> So for an LL/SC based arch using cmpxchg() like that is sub-optimal.
>>>
>>> Why did you choose to write it entirely in C?
>>>
>> yes, you are right. more load/store will be done in C code.
>> However such xchg_u8/u16 is just used by qspinlock now. and I did not see
>> any performance regression.
>> So just wrote in C, for simple. :)
>>
>> Of course I have done xchg tests.
>> we run code just like xchg((u8*)&v, j++); in several threads.
>> and the result is,
>> [ 768.374264] use time[1550072]ns in xchg_u8_asm
>
> How was xchg_u8_asm() implemented, using lbarx or using a 32bit ll/sc
> loop with shifting and masking in it?
>
yes, using 32bit ll/sc loops.
looks like:
__asm__ __volatile__(
"1: lwarx %0,0,%3\n"
" and %1,%0,%5\n"
" or %1,%1,%4\n"
PPC405_ERR77(0,%2)
" stwcx. %1,0,%3\n"
" bne-1b"
: "=&r" (_oldv), "=&r" (tmp), "+m" (*(volatile unsigned int *)_p)
: "r" (_p), "r" (_newv), "r" (_oldv_mask)
: "cc", "memory");
> Regards,
> Boqun
>
>> [ 768.377102] use time[2826802]ns in xchg_u8_c
>>
>> I think this is because there is one more load in C.
>> If possible, we can move such code in asm-generic/.
>>
>> thanks
>> xinhui
>>
[PATCH][RESEND] of: add missing const for of_parse_phandle_with_args() in !CONFIG_OF
From: Kuninori Morimoto
commit 93c667ca2598bd84f1bd3f2fa176af69707699fe
("of: *node argument to of_parse_phandle_with_args should be const")
changed to const for struct device node *np,
but it cares CONFIG_OF case only, !CONFIG_OF case need it too.
Signed-off-by: Kuninori Morimoto
---
include/linux/of.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index 7fcb681..4f2ce1b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -585,7 +585,7 @@ static inline struct device_node *of_parse_phandle(const
struct device_node *np,
return NULL;
}
-static inline int of_parse_phandle_with_args(struct device_node *np,
+static inline int of_parse_phandle_with_args(const struct device_node *np,
const char *list_name,
const char *cells_name,
int index,
--
1.9.1
Re: [PATCH 7/9] thermal: of: Add support for hardware-tracked trip points
Hi Brian, Eduardo, Sascha
在 2016年04月21日 09:12, Brian Norris 写道:
+ Sascha
On Wed, Apr 20, 2016 at 04:48:18PM -0700, Eduardo Valentin wrote:
On Mon, Apr 18, 2016 at 11:35:59AM +0800, Caesar Wang wrote:
From: Mikko Perttunen
This adds support for hardware-tracked trip points to the device tree
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 97b86c5..6ef932a 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -335,12 +335,14 @@ struct thermal_genl_event {
* @get_trend: a pointer to a function that reads the sensor temperature
trend.
* @set_emul_temp: a pointer to a function that sets sensor emulated
* temperature.
+ * @set_trips: a pointer to a function that set low/high trip temperature.
*/
struct thermal_zone_of_device_ops {
int (*get_temp)(void *, int *);
int (*get_trend)(void *, long *);
int (*set_emul_temp)(void *, int);
int (*set_trip_temp)(void *, int, int);
+ int (*set_trips)(void *, int, int);
This is unfortunately a diverges from API available on thermal core. Can
you please add first on thermal core then, use it in of thermal?
I don't want to have callbacks available only via of thermal. If we
allow it, OF thermal becomes a separate API.
What ever happened to this effort?
http://thread.gmane.org/gmane.linux.power-management.general/59451
Patch 12 and 13 look to accomplish something similar, yet they do what
Eduardo suggested. I was testing that series at my previous job, but
unfortunately (for the fate of this series) I left that employer before
I could finish reviewing and testing it. Perhaps Caesar can resurrect
and test it?
@Brian
Yes, I can
Sure, I can.
I see the Sascha's newest thermal patches in patchwork.
The following patches are still needed, right?
6446191 New [06/16] thermal: inline only once used function
6446111 New [07/16] thermal: streamline get_trend callbacks
6445871 New [08/16] thermal: Allow sensor ops to fail with -ENOSYS
6445861 New [09/16] thermal: of: always set sensor related
callbacks
6446221 New [10/16] thermal: Make struct
thermal_zone_device_ops const
6446201 New [11/16] thermal: bang-bang governor: act on lower
trip boundary
6445891 New [12/16] thermal: thermal: Add support for
hardware-tracked trip points
6445911 New [13/16] thermal: of: implement .set_trips for
device tree thermal zones
@Sascha, Eduardo
Can you share your discussion content for the above patches as remembered?
Thanks,
-Caesar
Brian
___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
[PATCH] dma: rcar-dmac: use list_add() on rcar_dmac_desc_put()
From: Kuninori Morimoto Current rcar_dmac_desc_put() is using list_add_tail() in order to push used descriptor to list of free descriptors, and next DMA transfer try to reuse it from this list. But because it is using *_tail(), this reuse effect can't be obtained without using all of them. For a longer-term solution, we should allocate hardware descriptors using GFP_KERNEL instead of GFP_NOWAIT, but it is difficult today. This patch uses list_add() instead of list_add_tail() for short-term solution. Signed-off-by: Kuninori Morimoto --- drivers/dma/sh/rcar-dmac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c index 02b86c6..616c63a 100644 --- a/drivers/dma/sh/rcar-dmac.c +++ b/drivers/dma/sh/rcar-dmac.c @@ -519,7 +519,7 @@ static void rcar_dmac_desc_put(struct rcar_dmac_chan *chan, spin_lock_irqsave(&chan->lock, flags); list_splice_tail_init(&desc->chunks, &chan->desc.chunks_free); - list_add_tail(&desc->node, &chan->desc.free); + list_add(&desc->node, &chan->desc.free); spin_unlock_irqrestore(&chan->lock, flags); } -- 1.9.1
Re: [PATCH] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs
Hi Marc:
On 2016年04月22日 05:12, Marc Zyngier wrote:
On Thu, 21 Apr 2016 22:24:09 +0200
Heiko Stübner wrote:
Am Donnerstag, 21. April 2016, 12:30:18 schrieb Marc Zyngier:
On Thu, 21 Apr 2016 18:47:20 +0800
"Huang, Tao" wrote:
Hi, Mark:
On 2016年04月21日 18:19, Mark Rutland wrote:
On Thu, Apr 21, 2016 at 11:58:12AM +0800, Jianqun Xu wrote:
+ cpu_l0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ #cooling-cells = <2>; /* min followed by max */
+ clocks = <&cru ARMCLKL>;
+ };
+ cpu_b0: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72", "arm,armv8";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ #cooling-cells = <2>; /* min followed by max */
+ clocks = <&cru ARMCLKB>;
+ };
+
+ arm-pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ;
+ };
This is wrong, and must go. There should be a separate node for the PMU
of each microarchitecture, with the appropriate compatible string to
represent that (see the juno dts).
You are right. The first version we wrote is:
pmu_a53 {
compatible = "arm,cortex-a53-pmu";
interrupts = ;
interrupt-affinity = <&cpu_l0>,
<&cpu_l1>,
<&cpu_l2>,
<&cpu_l3>;
};
pmu_a72 {
compatible = "arm,cortex-a72-pmu";
interrupts = ;
interrupt-affinity = <&cpu_b0>,
<&cpu_b1>;
};
but unfortunately, the arm pmu driver do not support PPI in two cluster
well,
so we have to replace with this implementation.
In this case things are messier as the same PPI number is being used
across clusters. Marc (Cc'd) has been working on PPI partitions, which
should allow us to support that.
Great! So what we can do right now? Wait this feature, and delete
arm-pmu node?
I'd rather you have a look at the patches, test them with your HW,
and comment on what doesn't work!
I would think we could do it in two tracks, testing and fixing but also letting
the rk3399 devicetrees move forward without the pmu at first :-) .
Where would the fun be then? ;-)
thanks for your advices, and I will try to test the percpu-partition
patches.
by the way, do you think it's better to let the dtsi be reviewed first,
then the percpu-partition patches could be tested by more people ?
Jianqun
M.
Re: [PATCH v3] KVM: remove buggy vcpu id check on vcpu creation
2016-04-21 23:29 GMT+08:00 Radim Krčmář :
> 2016-04-21 13:29+0200, Greg Kurz:
>> On Wed, 20 Apr 2016 20:29:09 +0200
>> Radim Krčmář wrote:
>>> 2016-04-20 17:44+0200, Greg Kurz:
>>> > Commit 338c7dbadd26 ("KVM: Improve create VCPU parameter (CVE-2013-4587)")
>>> > introduced a check to prevent potential kernel memory corruption in case
>>> > the vcpu id is too great.
>>> >
>>> > Unfortunately this check assumes vcpu ids grow in sequence with a common
>>> > difference of 1, which is wrong: archs are free to use vcpu id as they
>>> > fit.
>>> > For example, QEMU originated vcpu ids for PowerPC cpus running in
>>> > boot3s_hv
>>> > mode, can grow with a common difference of 2, 4 or 8: if KVM_MAX_VCPUS is
>>> > 1024, guests may be limited down to 128 vcpus on POWER8.
>>> >
>>> > This means the check does not belong here and should be moved to some arch
>>> > specific function: kvm_arch_vcpu_create() looks like a good candidate.
>>> >
>>> > ARM and s390 already have such a check.
>>> >
>>> > I could not spot any path in the PowerPC or common KVM code where a vcpu
>>> > id is used as described in the above commit: I believe PowerPC can live
>>> > without this check.
>>>
>>> The only problematic path I see is kvm_get_vcpu_by_id(), which returns
>>> NULL for any id above KVM_MAX_VCPUS.
>>
>> Oops my bad, I started to work on a 4.4 tree and I missed this check brought
>> by commit c896939f7cff (KVM: use heuristic for fast VCPU lookup by id).
>>
>> But again, I believe the check is wrong there also: the changelog just
>> mentions
>> this is a fastpath for the usual case where "VCPU ids match the array
>> index"...
>> why does the patch add a NULL return path if id >= KVM_MAX_VCPUS ?
>
> (The patch had to check id >= KVM_MAX_VCPUS for sanity and there could
> not be a VCPU with that index according to the spec, so it made a
> shortcut to the correct NULL result ...)
>
>>> Second issue is that Documentation/virtual/kvm/api.txt says
>>> 4.7 KVM_CREATE_VCPU
>>> [...]
>>> This API adds a vcpu to a virtual machine. The vcpu id is a small
>>> integer in the range [0, max_vcpus).
>>>
>>
>> Yeah and I find the meaning of max_vcpus is unclear.
>>
>> Here it is considered as a limit for vcpu id, but if you look at the code,
>> KVM_MAX_VCPUS is also used as a limit for the number of vcpus:
>>
>> virt/kvm/kvm_main.c:if (atomic_read(&kvm->online_vcpus) ==
>> KVM_MAX_VCPUS) {
>
> I agree. Naming of KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS would make
> you think that online_vcpus limit interpretation is the correct one, but
> the code is conflicted.
>
>>> so we'd remove those two lines and change the API too. The change would
>>> be somewhat backward compatible, but doesn't PowerPC use high vcpu_id
>>> just because KVM is lacking an API to set DT ID?
>>
>> This is related to a limitation when running in book3s_hv mode with cpus
>> that support SMT (multiple HW threads): all HW threads within a core
>> cannot be running in different guests at the same time.
>>
>> We solve this by using a vcpu numbering scheme as follows:
>>
>> vcpu_id[N] = (N * thread_per_core_guest) / threads_per_core_host + N %
>> threads_per_core_guest
>>
>> where N means "the Nth vcpu presented to the guest". This allows to have
>> groups of vcpus
>> that can be scheduled to run on the same real core.
>>
>> So, in the "worst" case where we want to run a guest with 1 thread/core and
>> the host
>> has 8 threads/core, we will need the vcpu_id limit to be 8*KVM_MAX_VCPUS.
>
> I see, thanks. Accommodating existing users seems like an acceptable
> excuse to change the API.
>
>>> x86 (APIC ID) is affected by this and ARM (MP ID) probably too.
>>>
>>
>> x86 is limited to KVM_MAX_VCPUS (== 255) vcpus: it won't be affected if we
>> also
>> patch kvm_get_vcpu_by_id() like suggested above.
>
> x86 vcpu_id encodes APIC ID and APIC ID encodes CPU topology by
> reserving blocks of bits for socket/core/thread, so if core or thread
> count isn't a power of two, then the set of valid APIC IDs is sparse,
^^^
^^^
Is this the root reason why recommand max vCPUs per vm is 160 and the
KVM_MAX_VCPUS is 255 instead of due to perforamnce concern?
Regards,
Wanpeng Li
> but max id is still limited by 255, so the effective maximum VCPU count
> is lower.
RE: [PATCH kernel 1/2] mm: add the related functions to build the free page bitmap
> On Wed, Apr 20, 2016 at 01:41:24AM +, Li, Liang Z wrote: > > > Cc: Rik van Riel; v...@zeniv.linux.org.uk; > > > linux-kernel@vger.kernel.org; quint...@redhat.com; > > > amit.s...@redhat.com; pbonz...@redhat.com; dgilb...@redhat.com; > > > linux...@kvack.org; k...@vger.kernel.org; qemu- de...@nongnu.org; > > > ag...@suse.de; borntrae...@de.ibm.com > > > Subject: Re: [PATCH kernel 1/2] mm: add the related functions to > > > build the free page bitmap > > > > > > On Tue, Apr 19, 2016 at 03:02:09PM +, Li, Liang Z wrote: > > > > > On Tue, 2016-04-19 at 22:34 +0800, Liang Li wrote: > > > > > > The free page bitmap will be sent to QEMU through virtio > > > > > > interface and used for live migration optimization. > > > > > > Drop the cache before building the free page bitmap can get > > > > > > more free pages. Whether dropping the cache is decided by user. > > > > > > > > > > > > > > > > How do you prevent the guest from using those recently-freed > > > > > pages for something else, between when you build the bitmap and > > > > > the live migration completes? > > > > > > > > Because the dirty page logging is enabled before building the > > > > bitmap, there is no need to prevent the guest from using the > > > > recently-freed > > > pages ... > > > > > > > > Liang > > > > > > Well one point of telling host that page is free is so that it can > > > mark it clean even if it was dirty previously. > > > So I think you must pass the pages to guest under the lock. > > > > Thanks! You mean save the free page bitmap in host pages? > > No, I literally mean don't release &zone->lock before you pass the list of > pages to host. > > > > This will allow host optimizations such as marking these pages > > > MADV_DONTNEED or MADV_FREE Otherwise it's all too tied up to a > > > specific usecase - you aren't telling host that a page is free, you > > > are telling it that a page was free in the past. > > > > > > > Then we should prevent the guest from using those recently-freed > > pages, before doing the MADV_DONTNEED or MADV_FREE, or the pages in > > the free page bitmap may be not free any more. In which case we will > > do something like this? Balloon? > > > > Liang > > > > Wouldn't keeping &zone->lock make sure these pages aren't used? > > Yes, keep the &zone->lock can ensure this, and it can make sure we get a real free page bitmap, its more semantic correct. But once we get a 'real' free page bitmap, the pages in the free page bitmap may became no free anymore before using it for some purposes, is there any mechanism to prevent this? If there is no strong reason, it's better to take the lock as short as possible. Could you elaborate some use cases which require a 'real' free page bitmap? Liang > > > -- > > > MST
Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
On Fri, Apr 15, 2016 at 10:03:16AM +, Yoshihiro Shimoda wrote:
> Hi,
>
> > From: Yoshihiro Shimoda
> > Sent: Friday, April 15, 2016 6:59 PM
> >
> > Hi,
> >
> > > From: Roger Quadros
> > > Sent: Thursday, April 14, 2016 8:32 PM
> > >
> > > On 14/04/16 14:15, Yoshihiro Shimoda wrote:
> > > > Hi,
> > > >
> > < snip >
> > > >>> @@ -865,7 +867,8 @@ int usb_otg_register_hcd(struct usb_hcd *hcd,
> > > >>> unsigned int irqnum,
> > > >>>* we're ready only if we have shared HCD
> > > >>>* or we don't need shared HCD.
> > > >>>*/
> > > >>> - if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
> > > >>> + if (otg->shared_hcd.hcd || (!otg->caps->needs_companion &&
> > > >>> + !otg->primary_hcd.hcd->shared_hcd))
> > > >>> {
> > > >>> otg->host = hcd_to_bus(hcd);
> > > >>> /* FIXME: set bus->otg_port if this is true OTG port
> > > >>> with HNP */
> > > >>>
> > > >>
> > > >> These changes look good to me. Thanks.
> > > >
> > > > Thank you for the comment.
> > > > If we change the "needs_companion" place to the otg_config,
> > > > do we need to add a flag into the otg, instead of otg->caps?
> > >
> > > Yes we can add a flag in struct usb_otg.
> >
> > Thank you for the comment.
> >
> > I made a fixed patch.
> > So, should I send this patch to ML after you sent v7 patches?
> > Or, would you apply this patch before you send v7 patches?
>
> Oops, I sent this email without my patch...
>
> ---
> Subject: [PATCH] usb: otg: add hcd companion support
>
> Since some host controller (e.g. EHCI) needs a companion host controller
> (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> core.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> Documentation/devicetree/bindings/usb/generic.txt | 3 +++
> drivers/usb/common/usb-otg.c | 17 +
> include/linux/usb/otg.h | 7 ++-
> 3 files changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/generic.txt
> b/Documentation/devicetree/bindings/usb/generic.txt
> index f6866c1..1db1c33 100644
> --- a/Documentation/devicetree/bindings/usb/generic.txt
> +++ b/Documentation/devicetree/bindings/usb/generic.txt
> @@ -27,6 +27,9 @@ Optional properties:
> - otg-controller: phandle to otg controller. Host or gadget controllers can
> contain this property to link it to a particular OTG
> controller.
> + - hcd-needs-companion: must be present if otg controller is dealing with
> + EHCI host controller that needs a companion OHCI host
> + controller.
>
> This is an attribute to a USB controller such as:
>
> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> index 41e762a..83c8c96 100644
> --- a/drivers/usb/common/usb-otg.c
> +++ b/drivers/usb/common/usb-otg.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -600,6 +601,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
> else
> INIT_WORK(&otg->work, usb_otg_work);
>
> + if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
> + config->hcd_needs_companion)/* needs comanion ? */
> + otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
> +
> otg->wq = create_singlethread_workqueue("usb_otg");
> if (!otg->wq) {
> dev_err(dev, "otg: %s: can't create workqueue\n",
> @@ -823,13 +828,15 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned
> int irqnum,
> /* HCD will be started by OTG fsm when needed */
> mutex_lock(&otg->fsm.lock);
> if (otg->primary_hcd.hcd) {
> - /* probably a shared HCD ? */
> - if (usb_otg_hcd_is_primary_hcd(hcd)) {
> + /* probably a shared HCD or a companion OHCI HCD ? */
> + if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
> + usb_otg_hcd_is_primary_hcd(hcd)) {
> dev_err(otg_dev, "otg: primary host already
> registered\n");
> goto err;
> }
>
> - if (hcd->shared_hcd == otg->primary_hcd.hcd) {
> + if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
> + (hcd->shared_hcd == otg->primary_hcd.hcd)) {
> if (otg->shared_hcd.hcd) {
> dev_err(otg_dev, "otg: shared host already
> registered\n");
> goto err;
> @@ -865,7 +872,9 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned
> int irqnum,
>* we're ready only if we have shared HCD
>* or we don't need shared HCD.
>*/
> - if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
> + if (otg->shared_hcd.hcd ||
> + (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
> + !
Re: [PATCH V4] audit: add tty field to LOGIN event
On Thu, Apr 21, 2016 at 2:14 PM, Richard Guy Briggs wrote:
> The tty field was missing from AUDIT_LOGIN events.
>
> Refactor code to create a new function audit_get_tty(), using it to
> replace the call in audit_log_task_info() and to add it to
> audit_log_set_loginuid(). Lock and bump the kref to protect it, adding
> audit_put_tty() alias to decrement it.
>
> Signed-off-by: Richard Guy Briggs
> ---
>
> V4: Add missing prototype for audit_put_tty() when audit syscall is not
> enabled (MIPS).
>
> V3: Introduce audit_put_tty() alias to decrement kref.
>
> V2: Use kref to protect tty signal struct while in use.
>
> ---
>
> include/linux/audit.h | 24
> kernel/audit.c| 18 +-
> kernel/auditsc.c |8 ++--
> 3 files changed, 35 insertions(+), 15 deletions(-)
>
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index b40ed5d..32cdafb 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #define AUDIT_INO_UNSET ((unsigned long)-1)
> #define AUDIT_DEV_UNSET ((dev_t)-1)
> @@ -343,6 +344,23 @@ static inline unsigned int audit_get_sessionid(struct
> task_struct *tsk)
> return tsk->sessionid;
> }
>
> +static inline struct tty_struct *audit_get_tty(struct task_struct *tsk)
> +{
> + struct tty_struct *tty = NULL;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&tsk->sighand->siglock, flags);
> + if (tsk->signal)
> + tty = tty_kref_get(tsk->signal->tty);
> + spin_unlock_irqrestore(&tsk->sighand->siglock, flags);
> + return tty;
> +}
> +
> +static inline void audit_put_tty(struct tty_struct *tty)
> +{
> + tty_kref_put(tty);
> +}
I'm generally not a big fan of defining functions as inlines in header
files, with the general exception of dummy functions that will get
compiled out. Although I guess there might be some performance
argument to be made wrt audit_log_task_info().
I guess I'm fine with this, but what was the idea behind the static
inlines in audit.h? Performance, or something else?
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 195ffae..71e14d8 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -1980,6 +1980,7 @@ static void audit_log_set_loginuid(kuid_t koldloginuid,
> kuid_t kloginuid,
> {
> struct audit_buffer *ab;
> uid_t uid, oldloginuid, loginuid;
> + struct tty_struct *tty;
>
> if (!audit_enabled)
> return;
> @@ -1987,14 +1988,17 @@ static void audit_log_set_loginuid(kuid_t
> koldloginuid, kuid_t kloginuid,
> uid = from_kuid(&init_user_ns, task_uid(current));
> oldloginuid = from_kuid(&init_user_ns, koldloginuid);
> loginuid = from_kuid(&init_user_ns, kloginuid),
> + tty = audit_get_tty(current);
>
> ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_LOGIN);
> if (!ab)
> return;
> audit_log_format(ab, "pid=%d uid=%u", task_pid_nr(current), uid);
> audit_log_task_context(ab);
> - audit_log_format(ab, " old-auid=%u auid=%u old-ses=%u ses=%u res=%d",
> -oldloginuid, loginuid, oldsessionid, sessionid, !rc);
> + audit_log_format(ab, " old-auid=%u auid=%u tty=%s old-ses=%u ses=%u
> res=%d",
> +oldloginuid, loginuid, tty ? tty_name(tty) :
> "(none)",
> +oldsessionid, sessionid, !rc);
> + audit_put_tty(tty);
> audit_log_end(ab);
> }
Because we are still using the crappy fixed string format for
kernel<->userspace communication, this patch will likely "break the
world" ... let's check with Steve but I believe the way to handle this
is to add the tty information to the end of the record.
--
paul moore
www.paul-moore.com
Re: [PATCH v11 3/3] printk: make printk.synchronous param rw
Hello,
On (04/21/16 13:07), Petr Mladek wrote:
[..]
> Please, what is the purpose of "printk_initcall_done" then? If I get
> this correctly, it will always be true when printk_sync_set() is
> called.
well, this is a bit ugly, yes. kernel_param_ops defines ->set callback
as printk_sync_set(). and this ->set callback is getting called from 2
different paths (but it's really about underlying __init_printk_kthread()).
__init_printk_kthread() can be executed from:
1) when command line is getting parsed, and we have printk.synchronous=[0|1]
[0.00] Kernel command line: BOOT_IMAGE=/vmlinuz-4.6.0-rc4-next-20160421
... printk.synchronous=0
[..]
[0.00] [] printk_sync_set+0x12/0x52
[0.00] [] parse_args+0x1ad/0x2bb
[0.00] [] ? vprintk_default+0x18/0x1a
[0.00] [] start_kernel+0x175/0x378
[0.00] [] ? set_init_arg+0x55/0x55
[0.00] [] x86_64_start_reservations+0x2a/0x2c
[0.00] [] x86_64_start_kernel+0x138/0x148
can't invoke __init_printk_kthread().
2) late_initcall(init_printk_kthread)
can invoke __init_printk_kthread() at this point.
2) when write to /sys/module/printk/parameters/synchronous happens from user
space
[ 65.441956] [] printk_sync_set+0x12/0x52
[ 65.441959] [] param_attr_store+0x65/0x8b
[ 65.441960] [] module_attr_store+0x19/0x25
[ 65.441963] [] sysfs_kf_write+0x36/0x38
[ 65.441964] [] kernfs_fop_write+0xe8/0x12e
[ 65.441966] [] __vfs_write+0x21/0xc3
[ 65.441967] [] ? filp_close+0x57/0x61
[ 65.441969] [] ? percpu_down_read+0xe/0x37
[ 65.441970] [] vfs_write+0xb9/0x143
[ 65.441971] [] SyS_write+0x49/0x84
[ 65.441974] [] entry_SYSCALL_64_fastpath+0x13/0x8f
can invoke __init_printk_kthread().
alternatively, I had this idea to re-define ->set() callback in
init_printk_kthread().
IOW, by default we use param_set_bool(), so parse_args() will not cause any
problems:
static /*** can't 'const' anymore ***/ struct kernel_param_ops
param_ops_printk_sync = {
.set = param_set_bool,
.get = param_get_bool,
};
and change it to printk_sync_set() in:
static __init int init_printk_kthread(void)
{
param_ops_printk_sync.set = printk_sync_set;
return __init_printk_kthread();
}
but I think that this bool flag is simpler to understand after all.
> > sysfs knob -> __init_printk_kthread() is protected by printk_sync_lock
> > mutex, obviously there can be parallel calls from user space.
>
> I think that this could not happen. We have discussed similar problem
> with livepatching some time ago. AFAIK, writes to sysfs are
> synchronized out of box.
oh, indeed.
kernfs_fop_write(struct file *file)
{
..
mutex_lock(&((struct seq_file *)file->private_data)->mutex);
ops->write();
mutex_unlock(&((struct seq_file *)file->private_data)->mutex);
..
}
good to know! will drop the mutex and re-spin.
[..]
> Otherwise the patch looks fine. I am bit concerned because
> the synchronization between the setting and testing of
> printk_sync/printk_kthread is a bit weak. But it works
> because we always either wakeup the kthread or call
> the console directly. So, we are on the safe side.
thanks.
> PS: I am sorry for the late comment. I was not able to do so
> immediately and I wrongly marked the mail as read :-(
no prob!
-ss
Re: [PATCH] bcache: bch_writeback_thread() is not freezable
On Wed, 20 Apr 2016, Jiri Kosina wrote: > On Tue, 19 Apr 2016, Eric Wheeler wrote: > > > > bch_writeback_thread() is calling try_to_freeze(), but that's just an > > > expensive no-op given the fact that the thread is not marked freezable. > > > > > > I/O helper kthreads, exactly such as the bcache writeback thread, > > > actually > > > shouldn't be freezable, because they are potentially necessary for > > > finalizing the image write-out. > > > > This is good timing, as Maciej Piechotka just reported a hang when > > suspending his system. > > Could you please point me to the actual report? Thanks. > > On Tue, 19 Apr 2016, Maciej Piechotka wrote: > Eric Wheeler lists.ewheeler.net> writes: > > Interesting. Can you collect the dmesg output as it suspends/resumes via > > serial or something other means? > > I'll try to capture the output today. No technical data yet, but this is the thread: http://comments.gmane.org/gmane.linux.kernel.bcache.devel/3820 > > What is the proper way to safely support suspend? Assuming the > > try_to_freeze() calls are in the right place, should we simply > > set_freezable() on these kthreads? > > Unfortunately, this is really a tricky question; the issue is that frezing > semantics is rather undefined for kthreads. For starters, please see > > https://lwn.net/Articles/662703/ > http://lkml.org/lkml/2007/4/27/608 Interesting indeed. So suspend should succeed independent of kernel threads since we want to get rid of freezable kthreads? Does this also mean that IO kthreads will always break suspend? > I don't belive in freezable kthreads which serve as I/O helpers. Such > threads simply have to keep going until the image is written out and > machine powered down. > > So I'd like to start with understanding how bcache is preventning suspend. > Maciej? We await backtraces from Maciej, but I can say that bcache uses only two kthreads, one for garbage collection and another for writeback. Speculation: The writeback thread can (probably) be made unrunnable at any time without issue since it is (should be) fully asynchronous. However, garbage collection might deadlock if the GC thread is unrunnable while hibernate (suspend?) IO is writing through bcache while bcache waits for GC to complete under allocation contention. I'm not familiar with the bcache allocator details, so anyone else please chime here. Presumably, GC is only unsafe during writes to the cache for blocks that are not yet cached but would cause a cache allocation. If so, then perhaps we can hook the pending suspend, set cache_mode to "writearound" to prevent btree changes, and restore the cache_mode on resume. It will be interesting to see the backtrace if Maciej can get one out of the system. -- Eric Wheeler
Re: [PATCH 2/3] ASoC: simple-card: Add support jack detection via codec
On 2016年04月21日 22:19, Rob Herring wrote: On Mon, Apr 18, 2016 at 04:17:31PM +0800, Xing Zheng wrote: In most cases, many codecs already supports jack detection, previouslly, we need to create a customized machine driver every time. Hence, the simple-card need to support use them dynamically via parse dts file for better flexibility. Signed-off-by: Xing Zheng --- .../devicetree/bindings/sound/simple-card.txt | 17 +++ sound/soc/generic/simple-card.c| 126 +++- 2 files changed, 140 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt index cf3979e..d25c8eb 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ b/Documentation/devicetree/bindings/sound/simple-card.txt @@ -22,6 +22,23 @@ Optional properties: headphones are attached. - simple-audio-card,mic-det-gpio : Reference to GPIO that signals when a microphone is attached. +- simple-audio-card,codec-jack : A list of the codec supports jack detection. + The jack types which are supported refer to include/sound/jack.h. + All of the jack types: + "JACK_HEADPHONE", + "JACK_MICROPHONE", + "JACK_HEADSET", + "JACK_LINEOUT", + "JACK_MECHANICAL", + "JACK_VIDEOOUT", + "JACK_AVOUT", + "JACK_LINEIN", + "JACK_BTN_0", + "JACK_BTN_1", + "JACK_BTN_2", + "JACK_BTN_3", + "JACK_BTN_4", + "JACK_BTN_5". simple-card is not so simple... I think this information be part of the codec node if the codec provides the functionality. The binding should not be different whether a codec is part of simple-card or not. Also, I would make all these just boolean props. Yes, these things seem like make simple-card becomes more complicated, and the generic jack detection method is still a problem currently. Hi Mark, the other question here, how do we make sense to use the simple-card to call the "snd_soc_dai_set_pll" if the codec (like da7219) requires do this? Thanks. -- - Xing Zheng
RE: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
On Tue, 19 Apr 2016, Matthew Fortune wrote: > > I have a fix in the works and to have it integrated upstream I just > > need to accompany it with suitable cases -- like the fragment above -- > > for the GAS testsuite. I'll send an update when it's ready. > > I do not think the change in behaviour was intentional. I think it came > about because I separated the handling of an explicit .set mips* directive > from the implicit setting of gp/fp. I needed to ensure that gp/fp was > only updated when there was a .set mips* directive but missed the case > where you have an explicit directive that matches the current mips* > setting. I had thought it might have been intentional before I realised the problem also affected ISA restoration, at which point I concluded it had been simply an oversight. While looking at it I've noticed we support somewhat questionable settings with the related `.module' directive, such as: .module at=$k0 .module nomove They have no command-line counterparts, so there's really no difference between having a `.module' or a corresponding `.set' directive at the top of a source file. There's no `.module' support for the similar `nomacro' or `noreorder' settings though. Was there a hidden motivation that you had to make such an arrangement? > The conditional nature of updating 'fp' is however very much intentional > in that if a user enters 'fpxx' mode where fp==0 then the implicit update > of fp does not happen. This is OK as this behaviour only triggers when > using the newly added fpxx feature anyway. Sure, my only concern has been the inconsistency between the case where the ISA is actually switched and one where it remains the same after a `.set' pseudo-op. > I am generally not in favour of these implicit side-effect behaviours > as they are only useful in niche cases and are somewhat non-intuitive but > we are stuck with them because of history. It would be possible to write > code that does not need them by explicitly using the .set gp or .set fp > options. There is little we can do about that given historic precedent > though. Instead code that does not want the implicit behaviour has to > explicitly do things like: > > .set mips3 > .set gp=default > .set fp=default Well, historically we had very little control and old code adapted to it. Even the `.set gp=' and `.set fp=' directives are relatively recent in the history of the MIPS port. So I agree -- had we had control we have today back when the MIPS port started, this would have been better handled with these more finegrained knobs. Before NewABI support was added even using e.g. `-mips3' on the command line made full 64-bit registers available. I have fixed the bug upstream now: commit 22522f880a8e17a17c4f195796ec89caece7652b Author: Maciej W. Rozycki Date: Fri Apr 22 01:04:52 2016 +0100 MIPS/GAS: Fix an ISA override not lifting ABI restrictions and included suitable test cases with the fix. The lack of testsuite coverage here is what let this bug remain unnoticed. Maciej
Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings
On 4/21/2016 8:22 PM, Matthew Wilcox wrote:
On Thu, Apr 21, 2016 at 07:43:39PM -0400, Toshi Kani wrote:
On 4/21/2016 4:21 PM, Mike Kravetz wrote:
Might want to keep the future possibility of PUD_SIZE THP in mind?
Yes, this is why the func name does not say 'pmd'. It can be extended to
support
PUD_SIZE in future.
Sure ... but what does that look like? I think it should look a little
like this:
Yes, I had something similar in mind, too. Do you want me to use this
version without the call with PUD_SIZE?
unsigned long __thp_get_unmapped_area(struct file *filp, unsigned long len,
loff_t off, unsigned long flags, unsigned long size);
{
unsigned long addr;
loff_t off_end = off + len;
loff_t off_align = round_up(off, size);
unsigned long len_size;
if ((off_end <= off_align) || ((off_end - off_align) < size))
return NULL;
len_size = len + size;
if ((len_size < len) || (off + len_size) < off)
return NULL;
addr = current->mm->get_unmapped_area(filp, NULL, len_size,
off >> PAGE_SHIFT, flags);
if (IS_ERR_VALUE(addr))
return NULL;
addr += (off - addr) & (size - 1);
return addr;
}
unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr,
unsigned long len, unsigned long pgoff, unsigned long flags)
{
loff_t off = (loff_t)pgoff << PAGE_SHIFT;
if (addr)
goto out;
if (IS_DAX(filp->f_mapping->host) && !IS_ENABLED(CONFIG_FS_DAX_PMD))
goto out;
/* Kirill, please fill in the right condition here for THP pagecache */
addr = __thp_get_unmapped_area(filp, len, off, flags, PUD_SIZE);
if (addr)
return addr;
addr = __thp_get_unmapped_area(filp, len, off, flags, PMD_SIZE);
if (addr)
return addr;
out:
return current->mm->get_unmapped_area(filp, addr, len, pgoff, flags);
}
By the way, I added an extra check here, when we add len and size
(PMD_SIZE in the original), we need to make sure that doesn't wrap.
NB: I'm not even compiling these suggestions, just throwing them out
here as ideas to be criticised.
Yes, I agree with the extra check. Thanks for pointing this out.
Also, len_size is a stupid name, but I can't think of a better one.
How about len_pad?
Thanks,
-Toshi
[git pull] drm fixes
Hi Linus, i915, nouveau and amdgpu/radeon fixes in this. Two nouveau fixes, one for a regression with dithering and one for a bug hit by the userspace drivers. i915 has a few fixes, mostly things heading for stable, two important skylake GT3/4 hangs. radeon/amdgpu has some audio, suspend/resume and some runtime PM fixes, along with two patches to harden the userptr ABI a bit. Thanks, (Since this only contained one other capital letter, I decided to add one here.) Dave. The following changes since commit 5f44abd041c5f3be76d57579ab254d78e601315b: Merge tag 'rtc-4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux (2016-04-21 15:41:13 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 18cdfe751f26ffa610f2a7b59775c5cc4c1c9619: Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2016-04-22 10:39:26 +1000) Akash Goel (1): drm/i915: Fixup the free space logic in ring_prepare Alex Deucher (8): drm/radeon: fix initial connector audio value drm/radeon: print pci revision as well as pci ids on driver load drm/radeon: add a quirk for a XFX R9 270X drm/amdgpu/acp: fix resume on CZ systems with AZ audio Revert "drm/radeon: disable runtime pm on PX laptops without dGPU power control" drm/radeon: print a message if ATPX dGPU power control is missing drm/amdgpu: use defines for CRTCs and AMFT blocks drm/amdgpu: bump the afmt limit for CZ, ST, Polaris Ben Skeggs (2): drm/nouveau/kms: fix setting of default values for dithering properties drm/nouveau/gr/gf100: select a stream master to fixup tfb offset queries Chris Wilson (2): drm/i915/userptr: Hold mmref whilst calling get-user-pages drm/i915: Force ringbuffers to not be at offset 0 Dave Airlie (4): Merge tag 'drm-intel-fixes-2016-04-21' of git://anongit.freedesktop.org/drm-intel into drm-fixes Merge branch 'linux-4.6' of git://github.com/skeggsb/linux into drm-fixes Merge branch 'linux-4.6' of git://github.com/skeggsb/linux into drm-fixes Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Huacai Chen (1): drm: Loongson-3 doesn't fully support wc memory Jérôme Glisse (2): drm/radeon: forbid mapping of userptr bo through radeon device file drm/amdgpu: forbid mapping of userptr bo through radeon device file Kumar, Mahesh (1): drm/i915/skl+: Use plane size for relative data rate calculation Michał Winiarski (1): drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write Mika Kuoppala (2): drm/i915/skl: Fix rc6 based gpu/system hang drm/i915/skl: Fix spurious gpu hang with gt3/gt4 revs Rex Zhu (1): drm/amdgpu: when suspending, if uvd/vce was running. need to cancel delay work. Sonny Jiang (1): amdgpu/uvd: add uvd fw version for amdgpu Ville Syrjälä (1): drm/i915: Use fw_domains_put_with_fifo() on HSW cp...@redhat.com (1): drm/dp/mst: Validate port in drm_dp_payload_send_msg() drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c| 4 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 6 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 5 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c| 1 + drivers/gpu/drm/drm_dp_mst_topology.c | 9 +- drivers/gpu/drm/i915/i915_drv.h| 5 +-- drivers/gpu/drm/i915/i915_gem_userptr.c| 29 ++ drivers/gpu/drm/i915/intel_lrc.c | 16 +++--- drivers/gpu/drm/i915/intel_pm.c| 42 +- drivers/gpu/drm/i915/intel_ringbuffer.c| 18 ++- drivers/gpu/drm/i915/intel_uncore.c| 6 +++- drivers/gpu/drm/nouveau/nouveau_connector.c| 4 +-- drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 ++ drivers/gpu/drm/radeon/radeon_atpx_handler.c | 11 --- drivers/gpu/drm/radeon/radeon_connectors.c | 7 - drivers/gpu/drm/radeon/radeon_device.c | 14 +++-- drivers/gpu/drm/radeon/radeon_ttm.c| 2 ++ drivers/gpu/drm/radeon/si_dpm.c| 1 + include/drm/drm_cache.h| 2 ++ 22 files changed, 126 insertions(+), 63 deletions(-)
linux-next: build failure after merge of the pci tree
Hi Bjorn,
After merging the pci tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/pci/host/pci-keystone.c: In function 'ks_pcie_probe':
drivers/pci/host/pci-keystone.c:412:16: error: 'node' undeclared (first use in
this function)
ks_pcie->np = node;
^
Caused by commit
7be92716c1aa ("PCI: keystone: Add error IRQ handler")
I have used the pci tree from next-20160421 for today.
--
Cheers,
Stephen Rothwell
Re: [PATCH 1/3] mfd: add Cypress FM33256B Processor Companion driver
Hi, [auto build test ERROR on ljones-mfd/for-mfd-next] [also build test ERROR on v4.6-rc4 next-20160421] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Jeppe-Ledet-Pedersen/Cypress-FM33256B-processor-companion-support/20160420-193004 base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next config: x86_64-randconfig-n0-04220648 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All error/warnings (new ones prefixed by >>): warning: (BMP085_SPI && TOUCHSCREEN_TSC2005 && SERIAL_MAX310X && SERIAL_SC16IS7XX_SPI && MFD_FM33256B && MFD_DA9052_SPI && MFD_MC13XXX_SPI && MFD_TPS65912_SPI && MFD_ARIZONA_SPI && MFD_WM831X_SPI && SND_SOC && SND_SOC_ADAU1761_SPI && SND_SOC_ADAU1781_SPI && SND_SOC_ADAU1977_SPI && SND_SOC_CS4271_SPI && SND_SOC_PCM3168A_SPI && SND_SOC_PCM512x_SPI && SND_SOC_SSM2602_SPI && SND_SOC_WM8804_SPI && RTC_I2C_AND_SPI && RTC_DRV_DS1343 && RTC_DRV_RX6110 && BMC150_ACCEL_SPI && MMA7455_SPI && AD5380 && BMG160_SPI && AFE4403 && INV_MPU6050_SPI && SENSORS_HMC5843_SPI) selects REGMAP_SPI which has unmet direct dependencies (SPI) drivers/built-in.o: In function `regmap_spi_read': >> regmap-spi.c:(.text+0x29e4c9): undefined reference to `spi_write_then_read' drivers/built-in.o: In function `regmap_spi_gather_write': >> regmap-spi.c:(.text+0x29e5e9): undefined reference to `spi_sync' drivers/built-in.o: In function `regmap_spi_write': regmap-spi.c:(.text+0x29e6d9): undefined reference to `spi_sync' drivers/built-in.o: In function `regmap_spi_async_write': >> regmap-spi.c:(.text+0x29e9eb): undefined reference to `spi_async' drivers/built-in.o: In function `fm33256b_probe': >> fm33256b.c:(.text+0x35c975): undefined reference to `spi_setup' drivers/built-in.o: In function `fm33256b_io': >> fm33256b.c:(.text+0x35cec6): undefined reference to `spi_sync' fm33256b.c:(.text+0x35cf53): undefined reference to `spi_sync' drivers/built-in.o: In function `fm33256b_spi_driver_init': >> fm33256b.c:(.init.text+0x131e9): undefined reference to >> `__spi_register_driver' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
[BUG linux-next] kernel NULL pointer dereference on linux-next-20160420
Hi folks, I did the below test with huge tmpfs on linux-next-20160420: # mount -t tmpfs huge=1 tmpfs /mnt # cd /mnt Then clone linux kernel Then I got the below bug, such test works well on non-huge tmpfs. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] release_freepages+0x18/0xa0 PGD 0 Oops: [#1] PREEMPT SMP Modules linked in: CPU: 6 PID: 110 Comm: kcompactd0 Not tainted 4.6.0-rc4-next-20160420-WR7.0.0.0_standard #4 Hardware name: Intel Corporation S5520HC/S5520HC, BIOS S5500.86B.01.10.0025.030220091519 03/02/2009 task: 880361708040 ti: 880361704000 task.ti: 880361704000 RIP: 0010:[] [] release_freepages+0x18/0xa0 RSP: 0018:880361707cf8 EFLAGS: 00010282 RAX: RBX: 88036ffde7c0 RCX: 0009 RDX: 1bf1 RSI: 000f RDI: 880361707dd0 RBP: 880361707d20 R08: 0007 R09: 1600 R10: 88036ffde7c0 R11: R12: R13: 880361707dd0 R14: 880361707dc0 R15: 880361707db0 FS: () GS:880363cc() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 02206000 CR4: 06e0 Stack: 88036ffde7c0 1a00 880361707dc0 880361707db0 880361707da0 8119f13d 81196239 880361708040 0001 0010 Call Trace: [] compact_zone+0x55d/0x9f0 [] ? fragmentation_index+0x19/0x70 [] kcompactd_do_work+0x10f/0x230 [] kcompactd+0x90/0x1e0 [] ? wait_woken+0xa0/0xa0 [] ? kcompactd_do_work+0x230/0x230 [] kthread+0xdd/0x100 [] ret_from_fork+0x22/0x40 [] ? kthread_create_on_node+0x180/0x180 Code: c1 fa 06 31 f6 e8 a9 9b fd ff eb 98 0f 1f 80 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 57 41 56 41 55 49 89 fd 41 54 53 48 8b 07 <48> 8b 10 48 8d 78 e0 49 39 c5 4c 8d 62 e0 74 70 49 be 00 00 00 RIP [] release_freepages+0x18/0xa0 RSP CR2: ---[ end trace 855da7e142f7311f ]---
Re: [PATCH] cpufreq: mt8173: use list_for_each_entry*()
On Tuesday, April 05, 2016 08:35:57 AM Viresh Kumar wrote: > On 05-04-16, 10:38, Geliang Tang wrote: > > Use list_for_each_entry*() instead of list_for_each*() to simplify > > the code. > > > > Signed-off-by: Geliang Tang > > --- > > drivers/cpufreq/mt8173-cpufreq.c | 14 -- > > 1 file changed, 4 insertions(+), 10 deletions(-) > > Acked-by: Viresh Kumar Applied, thanks!
Re: [PATCH] cpuidle: Indicate when a device has been unregistered
On Wednesday, April 06, 2016 12:00:48 PM Daniel Lezcano wrote:
> On Tue, Apr 05, 2016 at 02:05:38PM -0500, Dave Gerlach wrote:
> > Currently the 'registered' member of the cpuidle_device struct is set
> > to 1 during cpuidle_register_device. In this same function there are
> > checks to see if the device is already registered to prevent duplicate
> > calls to register the device, but this value is never set to 0 even on
> > unregister of the device. Because of this, any attempt to call
> > cpuidle_register_device after a call to cpuidle_unregister_device will
> > fail which shouldn't be the case.
> >
> > To prevent this, set registered to 0 when the device is unregistered.
> >
> > Fixes: c878a52d3c7c ("cpuidle: Check if device is already registered")
> > Signed-off-by: Dave Gerlach
> > ---
>
> Acked-by: Daniel Lezcano
Applied, thanks!
