[PATCH 1/2] dt-bindings: dmaengine: Add Mediatek High-Speed DMA controller bindings
From: Sean Wang
Document the devicetree bindings for Mediatek High-Speed DMA controller
which could be found on MT7623 SoC or other similar Mediatek SoCs.
Signed-off-by: Sean Wang
---
.../devicetree/bindings/dma/mtk-hsdma.txt | 30 ++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/mtk-hsdma.txt
diff --git a/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
b/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
new file mode 100644
index 000..62cdda4
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
@@ -0,0 +1,30 @@
+Mediatek High-Speed DMA Controller
+==
+
+This driver follows the generic DMA bindings defined in dma/dma.txt.
+
+Required properties:
+
+- compatible: Must be one of
+ "mediatek,mt7623-hsdma".
+- reg: Should contain the register's base address and length.
+- interrupts: Should contain a reference to the interrupt used by this
+ device.
+- clocks: Should be the clock specifiers corresponding to the entry in
+ clock-names property.
+- clock-names: Should contain "hsdma" entries.
+- #dma-cells: The length of the DMA specifier, must be <1>. This one cell
+ in dmas property of a client device represents the channel
+ number.
+Example:
+
+hsdma: hsdma@1b007000 {
+ compatible = "mediatek,mt7623-hsdma";
+ reg = <0 0x1b007000 0 0x1000>;
+ interrupts = ;
+ clocks = <ðsys CLK_ETHSYS_HSDMA>;
+ clock-names = "hsdma";
+ status = "okay";
+ };
+
+DMA clients must use the format described in dma/dma.txt file.
--
2.7.4
[PATCH 2/2] dmaengine: mtk-hsdma: Add Mediatek High-Speed DMA controller on MT7623 SoC
From: Sean Wang Add dmaengine driver for Mediatek High-Speed DMA based on the feature DMA_VIRTUAL_CHANNELS. Mediatek High-Speed DMA controller (HSDMA) on MT7623 SoC has the single channel which is dedicated to memory-to-memory transfer through ring-based descriptor management. Even though there is only one physical channel available inside HSDMA, the driver is extended to the support for multiple virtual channels processing simultaneously in round-round way by means of the feature DMA_VIRTUAL_CHANNELS. Signed-off-by: Sean Wang --- drivers/dma/Kconfig | 14 + drivers/dma/Makefile| 1 + drivers/dma/mtk-hsdma.c | 890 3 files changed, 905 insertions(+) create mode 100644 drivers/dma/mtk-hsdma.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index fc3435c..656beac 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -329,6 +329,20 @@ config MPC512X_DMA ---help--- Enable support for the Freescale MPC512x built-in DMA engine. +config MTK_HSDMA + tristate "Mediatek High-Speed DMA controller support" + depends on ARCH_MEDIATEK || COMPILE_TEST + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + ---help--- + Enable support for High-Speed DMA controller on Mediatek + SoCs. + + This controller provides the channels which is dedicated to + memory-to-memory transfer to offload from CPU through ring- + based descriptor management which could be found on MT7623 + platform. + config MV_XOR bool "Marvell XOR engine support" depends on PLAT_ORION || ARCH_MVEBU || COMPILE_TEST diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index 0b723e9..40ef3a4 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -68,6 +68,7 @@ obj-$(CONFIG_TI_EDMA) += edma.o obj-$(CONFIG_XGENE_DMA) += xgene-dma.o obj-$(CONFIG_ZX_DMA) += zx_dma.o obj-$(CONFIG_ST_FDMA) += st_fdma.o +obj-$(CONFIG_MTK_HSDMA) += mtk-hsdma.o obj-y += qcom/ obj-y += xilinx/ diff --git a/drivers/dma/mtk-hsdma.c b/drivers/dma/mtk-hsdma.c new file mode 100644 index 000..2adc1bc --- /dev/null +++ b/drivers/dma/mtk-hsdma.c @@ -0,0 +1,890 @@ +/* + * Driver for Mediatek High-Speed DMA Controller + * + * Copyright (C) 2017 Sean Wang + * + * 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. + * + * 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 +#include + +#include "virt-dma.h" + +#define MTK_DMA_DEV KBUILD_MODNAME + +#define MTK_HSDMA_USEC_POLL20 +#define MTK_HSDMA_TIMEOUT_POLL 20 + +#define MTK_HSDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED) | \ +BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \ +BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \ +BIT(DMA_SLAVE_BUSWIDTH_4_BYTES)) + +/* Max size of data one descriptor can move */ +#define MTK_DMA_MAX_DATA_ITEMS 0x3fff + +/* The default number of virtual channel */ +#define MTK_DMA_MAX_VCHANNELS 3 + +/* MTK_DMA_SIZE must be 2 of power and 4 for the minimal */ +#define MTK_DMA_SIZE 256 +#define MTK_HSDMA_NEXT_DESP_IDX(x, y) (((x) + 1) & ((y) - 1)) +#define MTK_HSDMA_PREV_DESP_IDX(x, y) (((x) - 1) & ((y) - 1)) +#define MTK_HSDMA_MAX_LEN 0x3f80 +#define MTK_HSDMA_ALIGN_SIZE 4 +#define MTK_HSDMA_TIMEOUT HZ + +/* Registers and related fields definition */ +#define MTK_HSDMA_TX_BASE 0x0 +#define MTK_HSDMA_TX_CNT 0x4 +#define MTK_HSDMA_TX_CPU 0x8 +#define MTK_HSDMA_TX_DMA 0xc +#define MTK_HSDMA_RX_BASE 0x100 +#define MTK_HSDMA_RX_CNT 0x104 +#define MTK_HSDMA_RX_CPU 0x108 +#define MTK_HSDMA_RX_DMA 0x10c +#define MTK_HSDMA_INFO 0x200 +#define MTK_HSDMA_GLO 0x204 +#define MTK_HSDMA_GLO_TX2B_OFFSET BIT(31) +#define MTK_HSDMA_GLO_MULTI_DMABIT(10) +#define MTK_HSDMA_TX_WB_DDONE BIT(6) +#define MTK_HSDMA_BURST_64BYTES(0x2 << 4) +#define MTK_HSDMA_BURST_32BYTES(0x1 << 4) +#define MTK_HSDMA_BURST_16BYTES(0x0 << 4) +#define MTK_HSDMA_GLO_RX_BUSY BIT(3) +#define MTK_HSDMA_GLO_RX_DMA BIT(2) +#define MTK_HSDMA_GLO_TX_BUSY BIT(1) +#define MTK_HSDMA_GLO_TX_DMA
Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST
On Fri, May 12, 2017 at 03:19:17PM -0700, Darren Hart wrote: > On Sat, May 13, 2017 at 12:11:09AM +0200, Peter Zijlstra wrote: > > And I really _really_ hate to see that rest crap spread here. Can't we > > just delete all that nonsense and go back to 80 column 7bit ASCII ? > > > > Depending on the source this could be a genuine appeal or satire :-D A bit of both of course ;-) > In this case, I don't think the ReST changes (with -) make the comment block > any > less readable in the C files. > > > It is an incentive not to use kerneldoc.. > > > > I like the kerneldoc if for no other reason that it helps keeps formatting > consistent. I would object if I started seeing XML or some other horrible > formatting style showing up in the code, but this honestly seems like a fairly > minimal imposition... but that's me. Well, I don't mind the '-' thing before return values too much, but the below chunk is just pure drivel. It makes a perfectly good comment worse. --- a/kernel/locking/mutex.c +++ b/kernel/locking/mutex.c @@ -227,9 +227,11 @@ static void __sched __mutex_lock_slowpath(struct mutex *lock); * (or statically defined) before it can be locked. memset()-ing * the mutex to 0 is not allowed. * - * ( The CONFIG_DEBUG_MUTEXES .config option turns on debugging + * .. note:: + * + * The CONFIG_DEBUG_MUTEXES .config option turns on debugging * checks that will enforce the restrictions and will also do - * deadlock debugging. ) + * deadlock debugging. * * This function is similar to (but not equivalent to) down(). */
Re: [PATCH v2 5/8] drm: Use new mode_valid() helpers in connector probe helper
On Monday 15 May 2017 08:47:49 Daniel Vetter wrote: > On Sun, May 14, 2017 at 02:04:24PM +0300, Laurent Pinchart wrote: > > On Friday 12 May 2017 17:06:14 Jose Abreu wrote: > >> On 12-05-2017 10:35, Laurent Pinchart wrote: > >>> On Tuesday 09 May 2017 18:00:12 Jose Abreu wrote: > +if (mode->status == MODE_OK) > +mode->status = drm_mode_validate_connector(connector, > > mode); > >>> > >>> I would reverse the arguments order to match the style of the other > >>> validation functions. > >> > >> Hmm, I think it makes more sense to pass connector first and then > >> mode ... > > > > I disagree, as this function validates a mode against a pipeline, the same > > way the other validation functions validate a mode against other > > parameters, but it's your patch :-) > > Call it drm_connector_validate_mode, because the first argument is > generally the object we operate on :-) But the function doesn't validate a mode for a connector, it validates a mode for a complete pipeline... -- Regards, Laurent Pinchart
Re: [PATCH] usb-musb: keep VBUS on when device is disconnected
> Il giorno 12 mag 2017, alle ore 17:21, Bin Liu ha scritto:
>
> […]
>
> Moreno, would you mind to test the patch below with your modem?
>
> […]
>>
>>> 8<
>>> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
>>> index 9c7ee26ef388..465281244596 100644
>>> --- a/drivers/usb/musb/musb_dsps.c
>>> +++ b/drivers/usb/musb/musb_dsps.c
>>> @@ -245,9 +245,14 @@ static int dsps_check_status(struct musb *musb, void
>>> *unused)
>>>dsps_mod_timer_optional(glue);
>>>break;
>>>case OTG_STATE_A_WAIT_BCON:
>>> + /* keep VBUS on for host-only mode */
>>> + if (musb->port_mode == MUSB_PORT_MODE_HOST) {
>>> + dsps_mod_timer_optional(glue);
>>> + break;
>>> + }
>>>musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
>>>skip_session = 1;
>>> - /* fall */
>>> + /* fall through */
>>>
>>>case OTG_STATE_A_IDLE:
>>>case OTG_STATE_B_IDLE:
Hello Bin,
I tested the above patch with my device and it seems to work correctly with the
current mainline kernel.
I tested it with my “production” kernel as well (4.9.20) but, for it to work, I
had to change it slightly.
This is what I tested for kernel 4.9.20:
--- a/drivers/usb/musb/musb_dsps.c 2017-05-15 08:40:23.0 +0200
+++ b/drivers/usb/musb/musb_dsps.c 2017-05-15 08:49:17.0 +0200
@@ -213,6 +213,12 @@ static int dsps_check_status(struct musb
msecs_to_jiffies(wrp->poll_timeout));
break;
case OTG_STATE_A_WAIT_BCON:
+ /* keep VBUS on for host-only mode */
+ if (musb->port_mode == MUSB_PORT_MODE_HOST) {
+ mod_timer(&glue->timer, jiffies +
+ msecs_to_jiffies(wrp->poll_timeout));
+ break;
+ }
musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
skip_session = 1;
/* fall */
In this form, it appears to work properly for 4.9.20 too.
Best regards,
Moreno
Re: [PATCH v3 3/3] media: mtk-mdp: Fix mdp device tree
On 15/05/17 04:31, Minghsiu Tsai wrote:
On Fri, 2017-05-12 at 17:05 +0200, Matthias Brugger wrote:
On 12/05/17 05:22, Minghsiu Tsai wrote:
From: Daniel Kurtz
If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifies the
device tree.
Although it fixes iommu assignment issue, it also break compatibility
with old device tree. So, the patch in driver is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.
Couldn't we preserve backwards compatibility by doing something like this:
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 9e4eb7dcc424..277d8fe6eb76 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -103,7 +103,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
{
struct mtk_mdp_dev *mdp;
struct device *dev = &pdev->dev;
- struct device_node *node;
+ struct device_node *node, *parent;
int i, ret = 0;
mdp = devm_kzalloc(dev, sizeof(*mdp), GFP_KERNEL);
@@ -117,8 +117,14 @@ static int mtk_mdp_probe(struct platform_device *pdev)
mutex_init(&mdp->lock);
mutex_init(&mdp->vpulock);
+ /* Old dts had the components as child nodes */
+ if (of_get_next_child(dev->of_node, NULL))
+ parent = dev->of_node;
+ else
+ parent = dev->of_node->parent;
+
/* Iterate over sibling MDP function blocks */
- for_each_child_of_node(dev->of_node, node) {
+ for_each_child_of_node(parent, node) {
const struct of_device_id *of_id;
enum mtk_mdp_comp_type comp_type;
int comp_id;
Maybe even by putting a warning in the if branch to make sure, people
are aware of their out-of-date device tree blobs.
Regards,
Matthias
Hi Matthias,
It is a good idea to do compatible in such a way and put a warning the
device tree is out of date. People can find out cause soon if device
tree is old.
I modify the code as below:
+ /* Old dts had the components as child nodes */
+ if (of_get_next_child(dev->of_node, NULL)) {
+ parent = dev->of_node;
+ dev_warn(dev, "device tree is out of date\n");
+ } else {
+ parent = dev->of_node->parent;
+ }
Will you upload it in a separate patch?
If not, I can merge it in my patch series and upload v4.
Please integrate it into your patch series.
Mauro, are you ok with the dev_warn about the out-of-date device-tree?
Regards,
Matthias
Best Regards,
Ming Hsiu
Signed-off-by: Daniel Kurtz
Signed-off-by: Minghsiu Tsai
---
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 9e4eb7d..a5ad586 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -118,7 +118,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
mutex_init(&mdp->vpulock);
/* Iterate over sibling MDP function blocks */
- for_each_child_of_node(dev->of_node, node) {
+ for_each_child_of_node(dev->of_node->parent, node) {
const struct of_device_id *of_id;
enum mtk_mdp_comp_type comp_type;
int comp_id;
Re: [PATCH 0/2] spi: spidev: Introduce SPI_IOC_WR_DEFAULT_MAX_SPEED_HZ command
Any thoughts on this ?
[PATCH v2] i2c: mux: only print failure message on error
As is, a failure message is printed unconditionally, which is confusing.
And noisy.
Fixes: 8d4d159f25a7 ("i2c: mux: provide more info on failure in
i2c_mux_add_adapter")
Signed-off-by: Peter Rosin
---
drivers/i2c/i2c-mux.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
Wolfram, you can take this one directly if you wish. You can also
take [1] (and optionally [2]) directly if you wish. Or just holler
and I'll send you a pull request with [1] and this patch for-current.
[1] i2c: mux: reg: put away the parent i2c adapter on probe failure
https://patchwork.ozlabs.org/patch/759487/
[2] i2c: mux: reg: rename label to indicate what it does
https://patchwork.ozlabs.org/patch/759486/
Changes since v1:
- Use goto instead of having two kfree, as pointed out by Leon Romanovsky.
Cheers,
peda
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 26f7237558ba..9669ca4937b8 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -395,18 +395,20 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
if (force_nr) {
priv->adap.nr = force_nr;
ret = i2c_add_numbered_adapter(&priv->adap);
- dev_err(&parent->dev,
- "failed to add mux-adapter %u as bus %u (error=%d)\n",
- chan_id, force_nr, ret);
+ if (ret < 0) {
+ dev_err(&parent->dev,
+ "failed to add mux-adapter %u as bus %u
(error=%d)\n",
+ chan_id, force_nr, ret);
+ goto err_free_priv;
+ }
} else {
ret = i2c_add_adapter(&priv->adap);
- dev_err(&parent->dev,
- "failed to add mux-adapter %u (error=%d)\n",
- chan_id, ret);
- }
- if (ret < 0) {
- kfree(priv);
- return ret;
+ if (ret < 0) {
+ dev_err(&parent->dev,
+ "failed to add mux-adapter %u (error=%d)\n",
+ chan_id, ret);
+ goto err_free_priv;
+ }
}
WARN(sysfs_create_link(&priv->adap.dev.kobj, &muxc->dev->kobj,
@@ -422,6 +424,10 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
muxc->adapter[muxc->num_adapters++] = &priv->adap;
return 0;
+
+err_free_priv:
+ kfree(priv);
+ return ret;
}
EXPORT_SYMBOL_GPL(i2c_mux_add_adapter);
--
2.1.4
Re: [PATCH v2 2/3] iio: adc: at91-sama5d2_adc: add hw trigger and buffer support
On 14.05.2017 18:12, Jonathan Cameron wrote:
On 11/05/17 07:09, Ludovic Desroches wrote:
On Wed, May 10, 2017 at 11:49:07AM +0300, Eugen Hristev wrote:
Hello,
Thanks for the suggestions and reply.
Please see my answers inline
Eugen
On 07.05.2017 18:01, Jonathan Cameron wrote:
On 04/05/17 13:13, Eugen Hristev wrote:
Added support for the external hardware trigger on pin ADTRG,
integrated the three possible edge triggers into the subsystem
and created buffer management for data retrieval
Signed-off-by: Eugen Hristev
---
Changes in v2:
- Moved buffer allocation and freeing into the preenable and
postdisable
callbacks.
We have a total of scan bytes that can vary a lot depending on
each channel
enabled at a certain point.
How much? Having dynamic allocations are likely to prove just as
costly as you'll
almost always end up allocating a lot more than you ask for.
I'm counting worst case of 18x 2byte channels + timestamp = 48 bytes.
A quick google suggests you'll always allocate 32 bytes whatever
with slab
(lower for slob). So not a huge saving...
Worth the hassle?
I will modify the allocation of scan_bytes to make it static.
- made the at91 trigger list part of state structure
- made the iio trigger list preallocated in state structure
- moved irq enabling/disabling into the try_reenable callback
I'd have liked a little explanation on why we need to explicitly
disable
the irq. It will have little effect it if triggers too often as the
trigger consumers are all oneshot anyway.
Regarding the irq, the discussion is a bit longer.
As it is now, the interrupt is not a oneshot threaded one, because only
the top half handler is installed, and the threaded one is NULL.
Calling trigger_poll without disabling the interrupt will make the
handler loop, so that is the reason for disabling and reenabling
the interrupt.
One solution is to change it to oneshot threaded interrupt and call
trigger_poll_chained to make it a nested handling. This will make a
longer response time for conversions though.
One other option is to do irq_save and irq_restore before issuing the
trigger poll, but that limits the usability of the trigger by any
other device I guess.
I did the behavior with disabling and enabling the interrupt considering
the old at91 driver and the stm32-adc driver which looks to be fairly
similar with this implementation.
Can you please advise on which approach you think it's best for this
driver ?
So I can try that, and resend the patch.
Leave it as is. Thanks for the explanation.
- on trigger disable must write disable registries as well
Basically looks good. A few questions inline.
Jonathan
drivers/iio/adc/at91-sama5d2_adc.c | 231
-
1 file changed, 228 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/at91-sama5d2_adc.c
b/drivers/iio/adc/at91-sama5d2_adc.c
index e10dca3..11f5570 100644
--- a/drivers/iio/adc/at91-sama5d2_adc.c
+++ b/drivers/iio/adc/at91-sama5d2_adc.c
@@ -23,8 +23,15 @@
#include
#include
#include
+#include
+
#include
#include
+#include
+#include
+#include
+#include
+
#include
/* Control Register */
@@ -132,6 +139,17 @@
#define AT91_SAMA5D2_PRESSR0xbc
/* Trigger Register */
#define AT91_SAMA5D2_TRGR0xc0
+/* Mask for TRGMOD field of TRGR register */
+#define AT91_SAMA5D2_TRGR_TRGMOD_MASK GENMASK(2, 0)
+/* No trigger, only software trigger can start conversions */
+#define AT91_SAMA5D2_TRGR_TRGMOD_NO_TRIGGER 0
+/* Trigger Mode external trigger rising edge */
+#define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_RISE 1
+/* Trigger Mode external trigger falling edge */
+#define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_FALL 2
+/* Trigger Mode external trigger any edge */
+#define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_ANY 3
+
/* Correction Select Register */
#define AT91_SAMA5D2_COSR0xd0
/* Correction Value Register */
@@ -145,14 +163,20 @@
/* Version Register */
#define AT91_SAMA5D2_VERSION0xfc
+#define AT91_SAMA5D2_HW_TRIG_CNT 3
+#define AT91_SAMA5D2_SINGLE_CHAN_CNT 12
+#define AT91_SAMA5D2_DIFF_CHAN_CNT 6
+
#define AT91_SAMA5D2_CHAN_SINGLE(num, addr)\
{\
.type = IIO_VOLTAGE,\
.channel = num,\
.address = addr,\
+.scan_index = num,\
.scan_type = {\
.sign = 'u',\
.realbits = 12,\
+.storagebits = 16,\
},\
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),\
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),\
@@ -168,9 +192,11 @@
.channel = num,\
.channel2 = num2,\
.address = addr,\
+.scan_index
[PATCH 2/2] zram: do not count duplicated pages as compressed
it's not same compressed pages and deduplicated pages
so we shouldn't count duplicated pages as compressed pages.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_dedup.c | 4
drivers/block/zram/zram_drv.c | 24 +++-
drivers/block/zram/zram_drv.h | 1 +
3 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/block/zram/zram_dedup.c b/drivers/block/zram/zram_dedup.c
index 14c4988f8ff7..c15848cc1b31 100644
--- a/drivers/block/zram/zram_dedup.c
+++ b/drivers/block/zram/zram_dedup.c
@@ -101,9 +101,6 @@ static unsigned long zram_dedup_put(struct zram *zram,
entry->refcount--;
if (!entry->refcount)
rb_erase(&entry->rb_node, &hash->rb_root);
- else
- atomic64_sub(entry->len, &zram->stats.dup_data_size);
-
spin_unlock(&hash->lock);
return entry->refcount;
@@ -127,7 +124,6 @@ static struct zram_entry *__zram_dedup_get(struct zram
*zram,
again:
entry->refcount++;
- atomic64_add(entry->len, &zram->stats.dup_data_size);
spin_unlock(&hash->lock);
if (prev)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index b885356551e9..8152e405117b 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -624,15 +624,22 @@ static void zram_free_page(struct zram *zram, size_t
index)
return;
}
+ if (zram_dedup_enabled(zram) &&
+ zram_test_flag(zram, index, ZRAM_DUP)) {
+ zram_clear_flag(zram, index, ZRAM_DUP);
+ atomic64_sub(entry->len, &zram->stats.dup_data_size);
+ goto out;
+ }
+
if (!entry)
return;
- zram_entry_free(zram, entry);
-
atomic64_sub(zram_get_obj_size(zram, index),
&zram->stats.compr_data_size);
- atomic64_dec(&zram->stats.pages_stored);
+out:
+ zram_entry_free(zram, entry);
+ atomic64_dec(&zram->stats.pages_stored);
zram_set_entry(zram, index, NULL);
zram_set_obj_size(zram, index, 0);
}
@@ -794,7 +801,15 @@ static int __zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index)
entry = zram_dedup_find(zram, page, &checksum);
if (entry) {
comp_len = entry->len;
- goto found_dup;
+ zram_slot_lock(zram, index);
+ zram_free_page(zram, index);
+ zram_set_flag(zram, index, ZRAM_DUP);
+ zram_set_entry(zram, index, entry);
+ zram_set_obj_size(zram, index, comp_len);
+ zram_slot_unlock(zram, index);
+ atomic64_add(comp_len, &zram->stats.dup_data_size);
+ atomic64_inc(&zram->stats.pages_stored);
+ return 0;
}
zstrm = zcomp_stream_get(zram->comp);
@@ -818,7 +833,6 @@ static int __zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index)
zs_unmap_object(zram->mem_pool, zram_entry_handle(zram, entry));
zram_dedup_insert(zram, entry, checksum);
-found_dup:
/*
* Free memory associated with this sector
* before overwriting unused sectors.
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
index 0091e23873c1..8ccfdcd8f674 100644
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@ -64,6 +64,7 @@ static const size_t max_zpage_size = PAGE_SIZE / 4 * 3;
enum zram_pageflags {
/* Page consists entirely of zeros */
ZRAM_SAME = ZRAM_FLAG_SHIFT,
+ ZRAM_DUP,
ZRAM_ACCESS,/* page is now accessed */
__NR_ZRAM_PAGEFLAGS,
--
2.7.4
[PATCH] iio: adc: sun4i-gpadc-iio: fix parent device being used in devm function
For the sake of DT binding stability, this IIO driver is a child of an
MFD driver for Allwinner A10, A13 and A31 because there already exists a
DT binding for this IP. The MFD driver has a DT node but the IIO driver
does not.
The IIO device registers the temperature sensor in the thermal framework
using the DT node of the parent, the MFD device, so the thermal
framework could match the phandle to the MFD device in the DT and the
struct device used to register in the thermal framework.
devm_thermal_zone_of_sensor_register was previously used to register the
thermal sensor with the parent struct device of the IIO device,
representing the MFD device. By doing so, we registered actually the
parent in the devm routine and not the actual IIO device.
This lead to the devm unregister function not being called when the IIO
module driver is removed. It resulted in the thermal framework still
polling the get_temp function of the IIO module while the device doesn't
exist anymore, thus generated a kernel panic.
Use the non-devm function instead and do the unregister manually in the
remove function.
Fixes: d1caa9905538 ("iio: adc: add support for Allwinner SoCs ADC")
Signed-off-by: Quentin Schulz
Reported-by: Corentin Labbe
---
drivers/iio/adc/sun4i-gpadc-iio.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
b/drivers/iio/adc/sun4i-gpadc-iio.c
index b23527309088..0d3df17be405 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -105,6 +105,7 @@ struct sun4i_gpadc_iio {
boolno_irq;
/* prevents concurrent reads of temperature and ADC */
struct mutexmutex;
+ struct thermal_zone_device *tzd;
};
#define SUN4I_GPADC_ADC_CHANNEL(_channel, _name) { \
@@ -502,7 +503,6 @@ static int sun4i_gpadc_probe_dt(struct platform_device
*pdev,
{
struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
const struct of_device_id *of_dev;
- struct thermal_zone_device *tzd;
struct resource *mem;
void __iomem *base;
int ret;
@@ -532,13 +532,13 @@ static int sun4i_gpadc_probe_dt(struct platform_device
*pdev,
if (!IS_ENABLED(CONFIG_THERMAL_OF))
return 0;
- tzd = devm_thermal_zone_of_sensor_register(&pdev->dev, 0, info,
- &sun4i_ts_tz_ops);
- if (IS_ERR(tzd))
+ info->tzd = thermal_zone_of_sensor_register(&pdev->dev, 0, info,
+ &sun4i_ts_tz_ops);
+ if (IS_ERR(info->tzd))
dev_err(&pdev->dev, "could not register thermal sensor: %ld\n",
- PTR_ERR(tzd));
+ PTR_ERR(info->tzd));
- return PTR_ERR_OR_ZERO(tzd);
+ return PTR_ERR_OR_ZERO(info->tzd);
}
static int sun4i_gpadc_probe_mfd(struct platform_device *pdev,
@@ -584,15 +584,14 @@ static int sun4i_gpadc_probe_mfd(struct platform_device
*pdev,
* of_node, and the device from this driver as third argument to
* return the temperature.
*/
- struct thermal_zone_device *tzd;
- tzd = devm_thermal_zone_of_sensor_register(pdev->dev.parent, 0,
- info,
- &sun4i_ts_tz_ops);
- if (IS_ERR(tzd)) {
+ info->tzd = thermal_zone_of_sensor_register(pdev->dev.parent, 0,
+ info,
+ &sun4i_ts_tz_ops);
+ if (IS_ERR(info->tzd)) {
dev_err(&pdev->dev,
"could not register thermal sensor: %ld\n",
- PTR_ERR(tzd));
- return PTR_ERR(tzd);
+ PTR_ERR(info->tzd));
+ return PTR_ERR(info->tzd);
}
} else {
indio_dev->num_channels =
@@ -688,6 +687,12 @@ static int sun4i_gpadc_remove(struct platform_device *pdev)
pm_runtime_put(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+
+ if (pdev->dev.of_node)
+ thermal_zone_of_sensor_unregister(&pdev->dev, info->tzd);
+ else
+ thermal_zone_of_sensor_unregister(pdev->dev.parent, info->tzd);
+
if (!info->no_irq && IS_ENABLED(CONFIG_THERMAL_OF))
iio_map_array_unregister(indio_dev);
--
2.11.0
[PATCH 1/2] zram: count same page write as page_stored
Regardless of whether it is same page or not, it's surely write and stored to zram so we should increase pages_stored stat. Otherwise, user can see zero value via mm_stats although he writes a lot of pages to zram. Signed-off-by: Minchan Kim --- drivers/block/zram/zram_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index 372602c7da49..b885356551e9 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -516,6 +516,7 @@ static bool zram_same_page_write(struct zram *zram, u32 index, zram_slot_unlock(zram, index); atomic64_inc(&zram->stats.same_pages); + atomic64_inc(&zram->stats.pages_stored); return true; } kunmap_atomic(mem); @@ -619,6 +620,7 @@ static void zram_free_page(struct zram *zram, size_t index) zram_clear_flag(zram, index, ZRAM_SAME); zram_set_element(zram, index, 0); atomic64_dec(&zram->stats.same_pages); + atomic64_dec(&zram->stats.pages_stored); return; } -- 2.7.4
Re: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"
Hi Lv, On May 15 2017 or thereabouts, Zheng, Lv wrote: > Hi, Benjamin > > Let's stop endless discussing and focus on our needs. > > I just copied my questions here. > You can ask them directly. > For the below inlined replies, I'll stop replying if they are based on > dependent on our basic agreements. > And I'll reply if something is really bad from my point of view. > > My point of view is: > There is a gap between (BIOS ensured/Windows expected) acpi control method > lid device behavior and Linux user space expected acpi control method lid > device behavior. > Button driver default behavior should be: button.lid_init_state=ignore > If user space programs have special needs, they can fix problems on their > own, via the following mean: > echo -n "open" > /sys/modules/button/parameters/lid_init_state > echo -n "close" > /sys/modules/button/parameters/lid_init_state > Keeping open/close modes is because I don't think there is any bug in button > driver. > So I need to prepare quirk modes from button driver's point of view and use > them as a response to related bug reports reported in acpi community. > Your point of view is: > There is a gap between (BIOS ensured/Windows expected) acpi control method > lid device behavior and Linux user space expected acpi control method lid > device behavior. Yep. But our role, as kernel developers, is to not break user space even if they made wrong design choices. > Button driver default behavior should be (not 100% sure if this is your > opinion): button.lid_init_state=method Yes, I'd like to revert to the old behavior (see below for a rationale). > If user space programs have special needs, they can fix them on their own, > via the following mean: > libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open > From this point of view, we actually don't need open/close modes. We don't need close, but we need to keep open, for 2 reasons I'll detail below. > > It seems we just need to determine the following first: > 1. Who should be responsible for solving bugs triggered by the conflict > between bios and linux user space expectations: >button driver? libinput? Some other user space programs? Users? Hopefully libinput or systemd (through a udev rule). If things gets worse a acpi/button quirk might be used, but in a second time. > 2. What should be the default button driver behavior? >button.lid_init_state=ignore? button.lid_init_state=method? button.lid_init_state=method: - this was the old default state, and switching to something else creates regression - the lid switch input node is an EV_SWITCH. And this has a state we need to synchronise with the hardware first. The default EV_SW state is closed, so if we do not sync it first, we might report wrong state to user space. > 3. If non button driver quirks are working, button driver quirk modes are > useless. >The question is: Should button.lid_init_state=open/close be kept? We should keep button.lid_init_state=open: - it's kernel API now, so you can't remove it without breaking users configuration - it helps booting laptops that are not known to be working, the time the user installs the distribution and add the hwdb entry to fix it. we should not keep button.lid_init_state=close: - I don't see a good use case where it is needed, besides debugging drivers that should be debugged in an other way. > 4. From button driver's point of view, button.lid_init_state=ignore seems to > be always correct, so we won't abandon it. We can keep it, and we should, it's kernel API >If we can use libinput to manage platform quirks, then > button.lid_init_state=method also looks useless. No. 'method' is the only way to guarantee the exported input node is synced properly with the actual physical world. >The question is: Should button.lid_init_state=method be kept? Definitively. > > I should also let you know my preference: > 1. using button.lid_init_state=ignore and button.lid_init_state=method as > default behavior is ok for me if answer to 1 is not button driver, otherwise > using button.lid_init_state=method is not ok for me > 2. deletion of button.lid_init_state=open/close is ok for me if answer to 1 > is not button driver, otherwise deletion of button.lid_init_state=open/close > is not ok for me > 3. deletion of button.lid_init_state=method is always ok for me > > See the base line from my side is very clear: > If acpi community need to handle such bug reports, > button.lid_init_state=method cannot be the default behavior. I already proposed to handle those reports. I don't see why you are concerned about those future reports. > We are just using a different default behavior than "method" to drive things > to reach the final root caused solution. > > Could you let me know your preference so that we can figure out an agreement > between us. > Though I don't know if end users will buy it (th
Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"
On May 12 2017 or thereabouts, Rafael J. Wysocki wrote: > On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote: > > Hi, > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior > > > to lid_init_state=open" > > > > > > On May 11 2017 or thereabouts, Zheng, Lv wrote: > > > > Hi, > > > > > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > > > > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default behavior > > > > > to lid_init_state=open" > > > > > > > > > > This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025. > > > > > > > > > > Even if the method implementation can be buggy on some platform, > > > > > the "open" choice is worse. It breaks docking stations basically > > > > > and there is no way to have a user-space hwdb to fix that. > > > > > > > > > > On the contrary, it's rather easy in user-space to have a hwdb > > > > > with the problematic platforms. Then, libinput (1.7.0+) can fix > > > > > the state of the LID switch for us: you need to set the udev > > > > > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'. > > > > > > > > > > When libinput detects internal keyboard events, it will > > > > > overwrite the state of the switch to open, making it reliable > > > > > again. Given that logind only checks the LID switch value after > > > > > a timeout, we can assume the user will use the internal keyboard > > > > > before this timeout expires. > > > > > > > > > > For example, such a hwdb entry is: > > > > > > > > > > libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* > > > > > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open > > > > [...] > > Well, if it worked in a specific way that users depended on before the commit > in > question and now it works differently, then it does break things. > > Benjamin, my understanding is that this is the case, is it correct? That is correct. This patch I reverted introduces regression for professional laptops that expect the LID switch to be reported accurately. Cheers, Benjamin
[PATCH V2 0/6] tty: serial: lpuart: add imx7ulp support
This patch series mainly intends to add imx7ulp support which is also using FSL lpuart. The lpuart in imx7ulp is basically the same as ls1021a. It's also 32 bit width register, but unlike ls1021a, it's little endian. Besides that, imx7ulp lpuart has a minor different register layout from ls1021a that it has four extra registers (verid, param, global, pincfg) located at the beginning of register map, which are currently not used by the driver and less to be used later. Furthermore, this patch serial also add a new more accurate baud rate calculation method as MX7ULP can't divide a suitable baud rate with the default setting. Currently the new baud rate calculation is only enabled on MX7ULP. However, i guess the Layerscape may also be able to use it as there seems to be no difference in baud rate setting register after checking the Layerscape Reference Manual. As i don't have Layerscape boards, i can't test it, so i only enable it for MX7ULP by default to avoid a potential break. I copied LayerScape guys in this series and hope they can help test later. If it works on Layerscape as well, then they can switch to the new setting too and totally remove the old stuff. ChangeLog: v1->v2: * Patch 2/4/5 chagned, other no changes. See individuals for details. Dong Aisheng (6): tty: serial: lpuart: introduce lpuart_soc_data to represent SoC property tty: serial: lpuart: add little endian 32 bit register support dt-bindings: serial: fsl-lpuart: add i.MX7ULP support tty: serial: lpuart: add imx7ulp support tty: serial: lpuart: add earlycon support for imx7ulp tty: serial: lpuart: add a more accurate baud rate calculation method .../devicetree/bindings/serial/fsl-lpuart.txt | 2 + drivers/tty/serial/fsl_lpuart.c| 147 ++--- 2 files changed, 134 insertions(+), 15 deletions(-) -- 2.7.4
[PATCH V2 3/6] dt-bindings: serial: fsl-lpuart: add i.MX7ULP support
The lpuart of imx7ulp is basically the same as ls1021a. It's also 32 bit width register, but unlike ls1021a, it's little endian. Besides that, imx7ulp lpuart has a minor different register layout from ls1021a. Cc: devicet...@vger.kernel.org Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Stefan Agner Cc: Mingkai Hu Cc: Yangbo Lu Acked-by: Rob Herring Acked-by: Fugang Duan Signed-off-by: Dong Aisheng --- Documentation/devicetree/bindings/serial/fsl-lpuart.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt index c95005e..a1252a0 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt @@ -6,6 +6,8 @@ Required properties: on Vybrid vf610 SoC with 8-bit register organization - "fsl,ls1021a-lpuart" for lpuart compatible with the one integrated on LS1021A SoC with 32-bit big-endian register organization + - "fsl,imx7ulp-lpuart" for lpuart compatible with the one integrated +on i.MX7ULP SoC with 32-bit little-endian register organization - reg : Address and length of the register set for the device - interrupts : Should contain uart interrupt - clocks : phandle + clock specifier pairs, one for each entry in clock-names -- 2.7.4
[PATCH V2 2/6] tty: serial: lpuart: add little endian 32 bit register support
It's based on the exist lpuart32 read/write implementation.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby (supporter:TTY LAYER)
Cc: Stefan Agner
Cc: Mingkai Hu
Cc: Yangbo Lu
Acked-by: Fugang Duan
Signed-off-by: Dong Aisheng
---
drivers/tty/serial/fsl_lpuart.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 7204103..e72b397 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -231,6 +231,8 @@
#define DEV_NAME "ttyLP"
#define UART_NR6
+static bool lpuart_is_be;
+
struct lpuart_port {
struct uart_portport;
struct clk *clk;
@@ -260,6 +262,7 @@ struct lpuart_port {
struct lpuart_soc_data {
boolis_32;
+ boolis_be;
};
static const struct lpuart_soc_data vf_data = {
@@ -268,6 +271,7 @@ static const struct lpuart_soc_data vf_data = {
static const struct lpuart_soc_data ls_data = {
.is_32 = true,
+ .is_be = true,
};
static const struct of_device_id lpuart_dt_ids[] = {
@@ -282,12 +286,15 @@ static void lpuart_dma_tx_complete(void *arg);
static u32 lpuart32_read(void __iomem *addr)
{
- return ioread32be(addr);
+ return lpuart_is_be ? ioread32be(addr) : readl(addr);
}
static void lpuart32_write(u32 val, void __iomem *addr)
{
- iowrite32be(val, addr);
+ if (lpuart_is_be)
+ iowrite32be(val, addr);
+ else
+ writel(val, addr);
}
static void lpuart_stop_tx(struct uart_port *port)
@@ -2000,6 +2007,7 @@ static int lpuart_probe(struct platform_device *pdev)
}
sport->port.line = ret;
sport->lpuart32 = sdata->is_32;
+ lpuart_is_be = sdata->is_be;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sport->port.membase = devm_ioremap_resource(&pdev->dev, res);
--
2.7.4
[PATCH V2 4/6] tty: serial: lpuart: add imx7ulp support
The lpuart of imx7ulp is basically the same as ls1021a. It's also
32 bit width register, but unlike ls1021a, it's little endian.
Besides that, imx7ulp lpuart has a minor different register layout
from ls1021a that it has four extra registers (verid, param, global,
pincfg) located at the beginning of register map, which are currently
not used by the driver and less to be used later.
To ease the register difference handling, we add a reg_off member
in lpuart_soc_data structure to represent if the normal
lpuart32_{read|write} requires plus a offset to hide the issue.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Stefan Agner
Cc: Mingkai Hu
Cc: Yangbo Lu
Acked-by: Fugang Duan
Signed-off-by: Dong Aisheng
---
ChangeLog:
v1->v2:
* remove lpuart_reg_off according to Stefan's suggestion
---
drivers/tty/serial/fsl_lpuart.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index e72b397..a3ee825 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -231,6 +231,9 @@
#define DEV_NAME "ttyLP"
#define UART_NR6
+/* IMX lpuart has four extra unused regs located at the beginning */
+#define IMX_REG_OFF0x10
+
static bool lpuart_is_be;
struct lpuart_port {
@@ -263,6 +266,7 @@ struct lpuart_port {
struct lpuart_soc_data {
boolis_32;
boolis_be;
+ u8 reg_off;
};
static const struct lpuart_soc_data vf_data = {
@@ -272,11 +276,19 @@ static const struct lpuart_soc_data vf_data = {
static const struct lpuart_soc_data ls_data = {
.is_32 = true,
.is_be = true,
+ .reg_off = 0x0,
+};
+
+static struct lpuart_soc_data imx_data = {
+ .is_32 = true,
+ .is_be = false,
+ .reg_off = IMX_REG_OFF,
};
static const struct of_device_id lpuart_dt_ids[] = {
{ .compatible = "fsl,vf610-lpuart", .data = &vf_data, },
{ .compatible = "fsl,ls1021a-lpuart", .data = &ls_data, },
+ { .compatible = "fsl,imx7ulp-lpuart", .data = &imx_data, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, lpuart_dt_ids);
@@ -2014,6 +2026,7 @@ static int lpuart_probe(struct platform_device *pdev)
if (IS_ERR(sport->port.membase))
return PTR_ERR(sport->port.membase);
+ sport->port.membase += sdata->reg_off;
sport->port.mapbase = res->start;
sport->port.dev = &pdev->dev;
sport->port.type = PORT_LPUART;
--
2.7.4
[PATCH V2 6/6] tty: serial: lpuart: add a more accurate baud rate calculation method
On new LPUART versions, the oversampling ratio for the receiver can be
changed from 4x (00011) to 32x (1) which could help us get a more
accurate baud rate divider.
The idea is to use the best OSR (over-sampling rate) possible.
Note, OSR is typically hard-set to 16 in other LPUART instantiations.
Loop to find the best OSR value possible, one that generates minimum
baud diff iterate through the rest of the supported values of OSR.
Currently only i.MX7ULP is using it.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Stefan Agner
Cc: Mingkai Hu
Cc: Yangbo Lu
Acked-by: Fugang Duan
Signed-off-by: Dong Aisheng
---
drivers/tty/serial/fsl_lpuart.c | 85 ++---
1 file changed, 79 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 107d0911..bda4b0c 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -140,6 +140,8 @@
#define UARTBAUD_SBNS 0x2000
#define UARTBAUD_SBR 0x
#define UARTBAUD_SBR_MASK 0x1fff
+#define UARTBAUD_OSR_MASK 0x1f
+#define UARTBAUD_OSR_SHIFT 24
#define UARTSTAT_LBKDIF0x8000
#define UARTSTAT_RXEDGIF 0x4000
@@ -1506,6 +1508,72 @@ lpuart_set_termios(struct uart_port *port, struct
ktermios *termios,
}
static void
+lpuart32_serial_setbrg(struct lpuart_port *sport, unsigned int baudrate)
+{
+ u32 sbr, osr, baud_diff, tmp_osr, tmp_sbr, tmp_diff, tmp;
+ u32 clk = sport->port.uartclk;
+
+ /*
+* The idea is to use the best OSR (over-sampling rate) possible.
+* Note, OSR is typically hard-set to 16 in other LPUART instantiations.
+* Loop to find the best OSR value possible, one that generates minimum
+* baud_diff iterate through the rest of the supported values of OSR.
+*
+* Calculation Formula:
+* Baud Rate = baud clock / ((OSR+1) × SBR)
+*/
+ baud_diff = baudrate;
+ osr = 0;
+ sbr = 0;
+
+ for (tmp_osr = 4; tmp_osr <= 32; tmp_osr++) {
+ /* calculate the temporary sbr value */
+ tmp_sbr = (clk / (baudrate * tmp_osr));
+ if (tmp_sbr == 0)
+ tmp_sbr = 1;
+
+ /*
+* calculate the baud rate difference based on the temporary
+* osr and sbr values
+*/
+ tmp_diff = clk / (tmp_osr * tmp_sbr) - baudrate;
+
+ /* select best values between sbr and sbr+1 */
+ tmp = clk / (tmp_osr * (tmp_sbr + 1));
+ if (tmp_diff > (baudrate - tmp)) {
+ tmp_diff = baudrate - tmp;
+ tmp_sbr++;
+ }
+
+ if (tmp_diff <= baud_diff) {
+ baud_diff = tmp_diff;
+ osr = tmp_osr;
+ sbr = tmp_sbr;
+ }
+ }
+
+ /* handle buadrate outside acceptable rate */
+ if (baud_diff > ((baudrate / 100) * 3))
+ dev_warn(sport->port.dev,
+"unacceptable baud rate difference of more than
3%%\n");
+
+ tmp = lpuart32_read(sport->port.membase + UARTBAUD);
+
+ if ((osr > 3) && (osr < 8))
+ tmp |= UARTBAUD_BOTHEDGE;
+
+ tmp &= ~(UARTBAUD_OSR_MASK << UARTBAUD_OSR_SHIFT);
+ tmp |= (((osr-1) & UARTBAUD_OSR_MASK) << UARTBAUD_OSR_SHIFT);
+
+ tmp &= ~UARTBAUD_SBR_MASK;
+ tmp |= sbr & UARTBAUD_SBR_MASK;
+
+ tmp &= ~(UARTBAUD_TDMAE | UARTBAUD_RDMAE);
+
+ lpuart32_write(tmp, sport->port.membase + UARTBAUD);
+}
+
+static void
lpuart32_set_termios(struct uart_port *port, struct ktermios *termios,
struct ktermios *old)
{
@@ -1611,12 +1679,17 @@ lpuart32_set_termios(struct uart_port *port, struct
ktermios *termios,
lpuart32_write(old_ctrl & ~(UARTCTRL_TE | UARTCTRL_RE),
sport->port.membase + UARTCTRL);
- sbr = sport->port.uartclk / (16 * baud);
- bd &= ~UARTBAUD_SBR_MASK;
- bd |= sbr & UARTBAUD_SBR_MASK;
- bd |= UARTBAUD_BOTHEDGE;
- bd &= ~(UARTBAUD_TDMAE | UARTBAUD_RDMAE);
- lpuart32_write(bd, sport->port.membase + UARTBAUD);
+ if (of_device_is_compatible(port->dev->of_node, "fsl,imx7ulp-lpuart")) {
+ lpuart32_serial_setbrg(sport, baud);
+ } else {
+ sbr = sport->port.uartclk / (16 * baud);
+ bd &= ~UARTBAUD_SBR_MASK;
+ bd |= sbr & UARTBAUD_SBR_MASK;
+ bd |= UARTBAUD_BOTHEDGE;
+ bd &= ~(UARTBAUD_TDMAE | UARTBAUD_RDMAE);
+ lpuart32_write(bd, sport->port.membase + UARTBAUD);
+ }
+
lpuart32_write(modem, sport->port.membase + UARTMODIR);
lpuart32_write(ctrl, sport->port.membase + UARTCTRL);
/* restore control register */
--
2.7.4
[PATCH V2 5/6] tty: serial: lpuart: add earlycon support for imx7ulp
earlycon is executed quite early before the device tree probe,
so we need configure the correct reg_off for imx7ulp during
early console setup.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Stefan Agner
Cc: Mingkai Hu
Cc: Yangbo Lu
Acked-by: Fugang Duan
Signed-off-by: Dong Aisheng
---
Change Log:
v1->v2:
* updated due to lpuart_reg_off removed
---
drivers/tty/serial/fsl_lpuart.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index a3ee825..107d0911 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -1976,8 +1976,20 @@ static int __init lpuart32_early_console_setup(struct
earlycon_device *device,
return 0;
}
+static int __init lpuart32_imx_early_console_setup(struct earlycon_device
*device,
+ const char *opt)
+{
+ if (!device->port.membase)
+ return -ENODEV;
+
+ device->port.membase += IMX_REG_OFF;
+ device->con->write = lpuart32_early_write;
+
+ return 0;
+}
OF_EARLYCON_DECLARE(lpuart, "fsl,vf610-lpuart", lpuart_early_console_setup);
OF_EARLYCON_DECLARE(lpuart32, "fsl,ls1021a-lpuart",
lpuart32_early_console_setup);
+OF_EARLYCON_DECLARE(lpuart32, "fsl,imx7ulp-lpuart",
lpuart32_imx_early_console_setup);
EARLYCON_DECLARE(lpuart, lpuart_early_console_setup);
EARLYCON_DECLARE(lpuart32, lpuart32_early_console_setup);
--
2.7.4
[PATCH V2 1/6] tty: serial: lpuart: introduce lpuart_soc_data to represent SoC property
This is used to dynamically check the SoC specific lpuart properies.
Currently only the checking of 32 bit register width is added which
functions the same as before. More will be added later for supporting
new chips.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Stefan Agner
Cc: Mingkai Hu
Cc: Yangbo Lu
Acked-by: Fugang Duan
Signed-off-by: Dong Aisheng
---
ChangeLog:
v1->v2:
* make all soc_data const
---
drivers/tty/serial/fsl_lpuart.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 15df1ba7..7204103 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -258,13 +258,21 @@ struct lpuart_port {
wait_queue_head_t dma_wait;
};
+struct lpuart_soc_data {
+ boolis_32;
+};
+
+static const struct lpuart_soc_data vf_data = {
+ .is_32 = false,
+};
+
+static const struct lpuart_soc_data ls_data = {
+ .is_32 = true,
+};
+
static const struct of_device_id lpuart_dt_ids[] = {
- {
- .compatible = "fsl,vf610-lpuart",
- },
- {
- .compatible = "fsl,ls1021a-lpuart",
- },
+ { .compatible = "fsl,vf610-lpuart", .data = &vf_data, },
+ { .compatible = "fsl,ls1021a-lpuart", .data = &ls_data, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, lpuart_dt_ids);
@@ -1971,6 +1979,9 @@ static struct uart_driver lpuart_reg = {
static int lpuart_probe(struct platform_device *pdev)
{
+ const struct of_device_id *of_id = of_match_device(lpuart_dt_ids,
+ &pdev->dev);
+ const struct lpuart_soc_data *sdata = of_id->data;
struct device_node *np = pdev->dev.of_node;
struct lpuart_port *sport;
struct resource *res;
@@ -1988,7 +1999,7 @@ static int lpuart_probe(struct platform_device *pdev)
return ret;
}
sport->port.line = ret;
- sport->lpuart32 = of_device_is_compatible(np, "fsl,ls1021a-lpuart");
+ sport->lpuart32 = sdata->is_32;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sport->port.membase = devm_ioremap_resource(&pdev->dev, res);
--
2.7.4
Re: [PATCH v3 3/9] dt-bindings: arm: mediatek: update for MT7623n SoC and relevant boards
On 12/05/17 09:56, sean.w...@mediatek.com wrote: From: Sean Wang Because there are two versions of MT7623 SoC that is MT7623a and MT7623n respectively. So update the part of MT7623n bindings to allow that people tend to differentiate which MT7623 SoC the boards applies. Signed-off-by: John Crispin Signed-off-by: Sean Wang --- Documentation/devicetree/bindings/arm/mediatek.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt index c860b24..0924b62 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.txt +++ b/Documentation/devicetree/bindings/arm/mediatek.txt @@ -1,6 +1,6 @@ MediaTek mt65xx, mt67xx & mt81xx Platforms Device Tree Bindings -Boards with a MediaTek mt65xx/mt67xx/mt81xx SoC shall have the +Boards with a MediaTek mt65xx/mt67xx/mt762x/mt81xx SoC shall have the following property: Required root node property: @@ -12,7 +12,7 @@ compatible: Must contain one of "mediatek,mt6592" "mediatek,mt6755" "mediatek,mt6795" - "mediatek,mt7623" + "mediatek,mt7623" which is referred to MT7623N SoC "mediatek,mt8127" "mediatek,mt8135" "mediatek,mt8173" @@ -38,9 +38,9 @@ Supported boards: - Evaluation board for MT6795(Helio X10): Required root node properties: - compatible = "mediatek,mt6795-evb", "mediatek,mt6795"; -- Evaluation board for MT7623: +- Reference board for MT7623n with NAND: Required root node properties: - - compatible = "mediatek,mt7623-evb", "mediatek,mt7623"; + - compatible = "mediatek,mt7623n-rfb-nand", "mediatek,mt7623"; Please explain in the commit message why you change this binding and why this is not problematic. Either in this patch or add a new one. For convenience for the device-tree maintainer, add the binding patches at the beginning of your patch list. It makes their life easier and a review faster, a clear win-win situation :) Thanks, Matthias - MTK mt8127 tablet moose EVB: Required root node properties: - compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
Re: [PATCH linux-next v2 0/1] improve imx spi performance
On Mon, May 01, 2017 at 03:31:43AM -0700, jiada_w...@mentor.com wrote: > From: Jiada Wang > > previously burst length (BURST_LENGTH) is always set to equal > to bits_per_word, causes a 10us gap between each word in transfer, > which significantly affects performance. Please don't send cover letters for single patches, if there is anything that needs saying put it in the changelog of the patch or after the --- if it's administrative stuff. This reduces mail volume and ensures that any important information is recorded in the changelog rather than being lost. signature.asc Description: PGP signature
Re: [PATCH v2 2/2] regulator: Allow for asymmetric settling times
On Mon, May 01, 2017 at 11:37:15AM -0700, Matthias Kaehlcke wrote: > else if (rdev->constraints->settling_time) > return rdev->constraints->settling_time; > + else if (rdev->constraints->settling_time_up && > + (new_uV > old_uV)) > + return rdev->constraints->settling_time_up; > + else if (rdev->constraints->settling_time_down && > + (new_uV < old_uV)) > + return rdev->constraints->settling_time_down; It feels like we should warn if the user mixes specific up/down settling times with the more general property, can you please send a followup patch adding a warning for that? It's not exactly obvious what the precedence is and may do the wrong thing with an older kernel or non-Linux OS. signature.asc Description: PGP signature
Re: [PATCH 1/2] spi: spidev: introduce SPI_IOC_WR_DEFAULT_MAX_SPEED_HZ command
On Tue, May 09, 2017 at 02:24:00PM +0200, Seraphime Kirkovski wrote: > I think, this change is necessary, on the one hand, because there are still > a lot of longterm[2] supported kernels out there, whose users may be relying > on > SPI_IOC_WR_MAX_SPEED being system-wide and, on the other hand, this > same command has been exhibiting a different behaviour for 3 years now, > so its users may break, if 9169051617df7 is reverted in one way or > another. Do we have any evidence that such users exist? signature.asc Description: PGP signature
Re: [RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry
On Thu, May 04, 2017 at 12:36:25AM -0400, Javier Martinez Canillas wrote: > Acked-by: Mark Brown Since I'm expected to apply this I wouldn't normally expect to see my ack - like I say if I'm acking something for me it's normally because I expect someone else to actually apply it (that's the standard thing). signature.asc Description: PGP signature
Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
On Wed, May 03, 2017 at 12:21:54PM +0100, Sudeep Holla wrote: > On 30/04/17 13:49, Mark Brown wrote: > > DT doesn't much care about that though. > No sure about that, may be doesn't care about the internals, but we need > to care about interface, no ? Well, we need to at least describe what's there - my point is that it's no different to describing a piece of hardware, the fact that it happens to be implemented as firmware doesn't really change the abstraction level DT is operating at. signature.asc Description: PGP signature
Re: [PATCH][RESEND] regulator: lp8755: fix spelling mistake "acceess" -> "access"
On Wed, May 10, 2017 at 09:30:20AM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_err messages. If this is a resend why do I not seem to have a copy of this patch? signature.asc Description: PGP signature
Re: [PATCH 2/2] spi: spidev: document SPI_IOC_WR_DEFAULT_MAX_SPEED_HZ
On Tue, May 09, 2017 at 02:24:01PM +0200, Seraphime Kirkovski wrote: > This adds documentation of the new spidev ioctl. This should have been part of the first path adding the new ioctl() :( signature.asc Description: PGP signature
Re: [PATCH] spi: SPI_TI_QSPI should depend on HAS_DMA
On Thu, May 04, 2017 at 09:37:18AM +0200, Geert Uytterhoeven wrote: > If NO_DMA=y: > > ERROR: "bad_dma_ops" [drivers/spi/spi-ti-qspi.ko] undefined! > > Add a dependency on HAS_DMA to fix this. There's no progress on fixing the architectures that don't do DMA to stub it out? :( signature.asc Description: PGP signature
Re: [PATCH] ASoC: max98927: Adding support for TDM mode and Envelop tracking control
On Fri, May 05, 2017 at 10:42:15AM -0700, Ryan Lee wrote: > Signed-off-by: Ryan Lee > --- The subject line suggests that this is adding two new features. Unless they are very closely related in the code they should be submitted as separate patches as covered in SubmittingPatches. > default: > - dev_err(codec->dev, "DAI clock mode unsupported"); > + dev_err(codec->dev, "DAI clock mode unsupported\n"); > return -EINVAL; > } > It also seems like there are a number of unrelated stylistic changes in this patch. While it's fine to make such changes they too should be in separate patches. signature.asc Description: PGP signature
Re: [PATCH] ASoC: codec: wm9860: avoid maybe-uninitialized warning
On Wed, Apr 19, 2017 at 07:04:20PM +0200, Arnd Bergmann wrote: > The new PLL configuration code triggers a harmless warning: This doens't apply against current code, please check and resend. signature.asc Description: PGP signature
Re: [PATCH 6/9] regulator: palmas: Drop unnecessary static
On Thu, May 04, 2017 at 10:10:51PM +0200, Julia Lawall wrote: > Drop static on a local variable, when the variable is initialized before > any use, on every possible execution path through the function. When sending a bunch of changes like this please either send the cover letter to everyone or send each patch separately (this seems like it stands alone just fine). The first question when only one patch in a series is visible is always what are the interdependencies. signature.asc Description: PGP signature
Re: [RFC] regulator: Shared regulators (configured by bootloader)
On Mon, May 08, 2017 at 03:51:02PM +0530, Viresh Kumar wrote: > I am looking to solve a problem faced by some of the Qualcomm > platforms and want your suggestions on how should we fix it. One of my > ex-colleague tried to solve [1] this problem but that thread never > concluded (and I don't really agree with the solution it offered). Please engage with the feedback I offered then. I see no point in repeating myself here, I'm just going to provide the same feedback as before and if I'm going to be ignored (which appears to be the case) it doesn't seem like it's worth the effort. signature.asc Description: PGP signature
Re: [PATCH v2 15/18] dt-bindings: sound: Add bindings for Cirrus Logic Madera codecs
On Tue, Apr 25, 2017 at 05:27:44PM +0100, Richard Fitzgerald wrote: > On Tue, 2017-04-25 at 16:52 +0100, Mark Brown wrote: > > > +Required properties: > > > + - compatible : One of the following chip-specific strings: > > > +"cirrus,cs47l35-codec" > > > +"cirrus,cs47l85-codec" > > > +"cirrus,cs47l90-codec" > > You shouldn't have compatible strings for subfunctions of a MFD unless > > these represent meaningful reusable IPs that can exist separately from > > the parent chip, that's clearly not the case here. All you're doing > > here is encoding Linux internal abstractions which aren't OS neutral and > > might change in future (for example clocking might move more into the > > clock API). > While that's nice, the of_node doesn't get populated if there isn't a > compatible string. And people don't like workarounds for the missing > of_node. What workarounds are you referring to? Why would this need any kind of workaround, there is no requirement for magic broken nodes like this in the subsystem and if there is we should fix that rather than bodge the ABI. signature.asc Description: PGP signature
Applied "ASoC: Intel: sst: fix spelling mistake: "allocationf" -> "allocation"" to the asoc tree
The patch
ASoC: Intel: sst: fix spelling mistake: "allocationf" -> "allocation"
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 3c0a98c595d87b9c961bafa755c2c0f3c031249c Mon Sep 17 00:00:00 2001
From: Colin Ian King
Date: Wed, 10 May 2017 11:29:40 +0100
Subject: [PATCH] ASoC: Intel: sst: fix spelling mistake: "allocationf" ->
"allocation"
Trivial fix to spelling mistake in dev_err message. Also replace "fail"
with "failure".
Signed-off-by: Colin Ian King
Signed-off-by: Mark Brown
---
sound/soc/intel/atom/sst-mfld-platform-pcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
index 21cac1c8dd4c..b082b31023d5 100644
--- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
+++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
@@ -690,7 +690,7 @@ static int sst_pcm_new(struct snd_soc_pcm_runtime *rtd)
snd_dma_continuous_data(GFP_DMA),
SST_MIN_BUFFER, SST_MAX_BUFFER);
if (retval) {
- dev_err(rtd->dev, "dma buffer allocationf fail\n");
+ dev_err(rtd->dev, "dma buffer allocation failure\n");
return retval;
}
}
--
2.11.0
Applied "rt286: add Thinkpad Helix 2 to force_combo_jack_table" to the asoc tree
The patch
rt286: add Thinkpad Helix 2 to force_combo_jack_table
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From fe0dfd6358a17c79bd7d6996af7512ba452a7059 Mon Sep 17 00:00:00 2001
From: Yifeng Li
Date: Thu, 4 May 2017 01:34:14 +0800
Subject: [PATCH] rt286: add Thinkpad Helix 2 to force_combo_jack_table
Thinkpad Helix 2 is a tablet PC, the audio is powered by Core M
broadwell-audio and rt286 codec. For all versions of Linux kernel,
the stereo output doesn't work properly when earphones are plugged
in, the sound was coming out from both channels even if the audio
contains only the left or right channel. Furthermore, if a music
recorded in stereo is played, the two channels cancle out each other
out, as a result, no voice but only distorted background music can be
heard, like a sound card with builtin a Karaoke sount effect.
Apparently this tablet uses a combo jack with polarity incorrectly
set by rt286 driver. This patch adds DMI information of Thinkpad Helix 2
to force_combo_jack_table[] and the issue is resolved. The microphone
input doesn't work regardless to the presence of this patch and still
needs help from other developers to investigate.
This is my first patch to LKML directly, sorry for CC-ing too many
people here.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=93841
Signed-off-by: Yifeng Li
Signed-off-by: Mark Brown
---
sound/soc/codecs/rt286.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/sound/soc/codecs/rt286.c b/sound/soc/codecs/rt286.c
index 9c365a7f758d..7899a2cdeb42 100644
--- a/sound/soc/codecs/rt286.c
+++ b/sound/soc/codecs/rt286.c
@@ -1108,6 +1108,13 @@ static const struct dmi_system_id
force_combo_jack_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "Kabylake Client platform")
}
},
+ {
+ .ident = "Thinkpad Helix 2nd",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad Helix 2nd")
+ }
+ },
{ }
};
--
2.11.0
Applied "ASoC: da7213: Fix incorrect usage of bitwise '&' operator for SRM check" to the asoc tree
The patch ASoC: da7213: Fix incorrect usage of bitwise '&' operator for SRM check has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 14f814fbedd749992476bb365b454b2170b3b225 Mon Sep 17 00:00:00 2001 From: Adam Thomson Date: Wed, 3 May 2017 16:15:53 +0100 Subject: [PATCH] ASoC: da7213: Fix incorrect usage of bitwise '&' operator for SRM check In the SRM lock check section of code the '&' bitwise operator is used as part of checking lock status. Functionally the code works as intended, but the conditional statement is a boolean comparison so should really use '&&' logical operator instead. This commit rectifies this discrepancy. Signed-off-by: Adam Thomson Signed-off-by: Mark Brown --- sound/soc/codecs/da7213.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/da7213.c b/sound/soc/codecs/da7213.c index 6dd7578f0bb8..024d83fa6a7f 100644 --- a/sound/soc/codecs/da7213.c +++ b/sound/soc/codecs/da7213.c @@ -772,7 +772,7 @@ static int da7213_dai_event(struct snd_soc_dapm_widget *w, ++i; msleep(50); } - } while ((i < DA7213_SRM_CHECK_RETRIES) & (!srm_lock)); + } while ((i < DA7213_SRM_CHECK_RETRIES) && (!srm_lock)); if (!srm_lock) dev_warn(codec->dev, "SRM failed to lock\n"); -- 2.11.0
Re: mm: page allocation failures in swap_duplicate -> add_swap_count_continuation
On Fri 12-05-17 11:18:42, Christian Borntraeger wrote:
> Folks,
>
> recently I have seen page allocation failures during
> paging in the paging code:
> e.g.
>
> May 05 21:36:53 kernel: Call Trace:
> May 05 21:36:53 kernel: ([<00112f62>] show_trace+0x62/0x78)
> May 05 21:36:53 kernel: [<00113050>] show_stack+0x68/0xe0
> May 05 21:36:53 kernel: [<004fb97e>] dump_stack+0x7e/0xb0
> May 05 21:36:53 kernel: [<00299262>] warn_alloc+0xf2/0x190
> May 05 21:36:53 kernel: [<0029a25a>]
> __alloc_pages_nodemask+0xeda/0xfe0
> May 05 21:36:53 kernel: [<002fa570>] alloc_pages_current+0xb8/0x170
> May 05 21:36:53 kernel: [<002f03fc>]
> add_swap_count_continuation+0x3c/0x280
> May 05 21:36:53 kernel: [<002f068c>] swap_duplicate+0x4c/0x80
> May 05 21:36:53 kernel: [<002dfbfa>] try_to_unmap_one+0x372/0x578
> May 05 21:36:53 kernel: [<0030131a>] rmap_walk_ksm+0x14a/0x1d8
> May 05 21:36:53 kernel: [<002e0d60>] try_to_unmap+0x140/0x170
> May 05 21:36:53 kernel: [<002abc9c>] shrink_page_list+0x944/0xad8
> May 05 21:36:53 kernel: [<002ac720>]
> shrink_inactive_list+0x1e0/0x5b8
> May 05 21:36:53 kernel: [<002ad642>] shrink_node_memcg+0x5e2/0x800
> May 05 21:36:53 kernel: [<002ad954>] shrink_node+0xf4/0x360
> May 05 21:36:53 kernel: [<002aeb00>] kswapd+0x330/0x810
> May 05 21:36:53 kernel: [<00189f14>] kthread+0x144/0x168
> May 05 21:36:53 kernel: [<008011ea>] kernel_thread_starter+0x6/0xc
> May 05 21:36:53 kernel: [<008011e4>] kernel_thread_starter+0x0/0xc
>
> This seems to be new in 4.11 but the relevant code did not seem to have
> changed.
>
> Something like this
>
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 1781308..b2dd53e 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -3039,7 +3039,7 @@ int swap_duplicate(swp_entry_t entry)
> int err = 0;
>
> while (!err && __swap_duplicate(entry, 1) == -ENOMEM)
> - err = add_swap_count_continuation(entry, GFP_ATOMIC);
> + err = add_swap_count_continuation(entry, GFP_ATOMIC |
> __GFP_NOWARN);
> return err;
> }
>
>
> seems not appropriate, because this code does not know if the caller can
> handle returned errors.
>
> Would something like the following (white space damaged cut'n'paste be ok?
> (the try_to_unmap_one change looks fine, not sure if copy_one_pte does the
> right thing)
No, it won't. If you want to silent the warning then explain _why_ it is
a good approach. It is not immediatelly clear to me.
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 235ba51..3ae6f33 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -898,7 +898,7 @@ copy_one_pte(struct mm_struct *dst_mm, struct mm_struct
> *src_mm,
> swp_entry_t entry = pte_to_swp_entry(pte);
>
> if (likely(!non_swap_entry(entry))) {
> - if (swap_duplicate(entry) < 0)
> + if (swap_duplicate(entry, __GFP_NOWARN) < 0)
> return entry.val;
Moreover if you add a gfp_mask argument then the _full_ mask should be
given rather than just one of the modifiers.
--
Michal Hocko
SUSE Labs
Applied "regulator: max8997/8966: fix charger cv voltage set bug" to the regulator tree
The patch
regulator: max8997/8966: fix charger cv voltage set bug
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From f74521ca578f38daa3e800efde7fdb2ac3ba76ef Mon Sep 17 00:00:00 2001
From: MyungJoo Ham
Date: Mon, 8 May 2017 05:45:44 +
Subject: [PATCH] regulator: max8997/8966: fix charger cv voltage set bug
When min charger-CV is <= 4.0V and max charger-CV is >= 4.0V,
we can use 4.00V as CV (register value = 0x1).`
The original code had a typo that wrote ">=" (max_uV >= 400),
which should've been "<", which is not necessary anyway
as mentioned by Dan Carpenter.
Reported-By: Dan Carpenter
Signed-off-by: MyungJoo Ham
Reviewed-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Chanwoo Choi
Signed-off-by: Mark Brown
---
drivers/regulator/max8997-regulator.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/max8997-regulator.c
b/drivers/regulator/max8997-regulator.c
index efabc0ea0e96..559b9ac45404 100644
--- a/drivers/regulator/max8997-regulator.c
+++ b/drivers/regulator/max8997-regulator.c
@@ -428,12 +428,9 @@ static int max8997_set_voltage_charger_cv(struct
regulator_dev *rdev,
if (max_uV < 400 || min_uV > 435)
return -EINVAL;
- if (min_uV <= 400) {
- if (max_uV >= 400)
- return -EINVAL;
- else
- val = 0x1;
- } else if (min_uV <= 420 && max_uV >= 420)
+ if (min_uV <= 400)
+ val = 0x1;
+ else if (min_uV <= 420 && max_uV >= 420)
val = 0x0;
else {
lb = (min_uV - 401) / 2 + 2;
--
2.11.0
Applied "ASoC: rt5665: fix gcc-7 warning" to the asoc tree
The patch
ASoC: rt5665: fix gcc-7 warning
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 27a655c4bd8d9851c0f2ef9ec0d3793d068acbe9 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann
Date: Thu, 11 May 2017 13:44:39 +0200
Subject: [PATCH] ASoC: rt5665: fix gcc-7 warning
gcc-7 warns that there is a duplicate 'const' specifier in some
variables that are declared using the SOC_ENUM_SINGLE_DECL macro:
sound/soc/codecs/rt5665.c:915:14: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_01_adc_enum,
sound/soc/codecs/rt5665.c:918:14: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_23_adc_enum,
sound/soc/codecs/rt5665.c:921:14: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_45_adc_enum,
sound/soc/codecs/rt5665.c:924:14: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_67_adc_enum,
...
This removes one to fix the 68 warnings in this file
Fixes: 33ada14a26c8 ("ASoC: add rt5665 codec driver")
Signed-off-by: Arnd Bergmann
Signed-off-by: Mark Brown
---
sound/soc/codecs/rt5665.c | 136 +++---
1 file changed, 68 insertions(+), 68 deletions(-)
diff --git a/sound/soc/codecs/rt5665.c b/sound/soc/codecs/rt5665.c
index 8cd22307f5b6..14b0cf89edf5 100644
--- a/sound/soc/codecs/rt5665.c
+++ b/sound/soc/codecs/rt5665.c
@@ -912,46 +912,46 @@ static const char * const rt5665_data_select[] = {
"L/R", "R/L", "L/L", "R/R"
};
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_01_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_1_01_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_1_DS_ADC_SLOT01_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_23_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_1_23_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_1_DS_ADC_SLOT23_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_45_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_1_45_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_1_DS_ADC_SLOT45_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_67_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_1_67_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_1_DS_ADC_SLOT67_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_2_01_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_2_01_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_2_DS_ADC_SLOT01_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_2_23_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_2_23_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_2_DS_ADC_SLOT23_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_2_45_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_2_45_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_2_DS_ADC_SLOT45_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_2_67_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_2_67_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_2_DS_ADC_SLOT67_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if2_1_dac_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if2_1_dac_enum,
RT5665_DIG_INF2_DATA, RT5665_IF2_1_DAC_SEL_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if2_1_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if2_1_adc_enum,
RT5665_DIG_INF2_DATA, RT5665_IF2_1_ADC_SEL_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if2_2_dac_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if2_2_dac_enum,
RT5665_DIG_INF2_DATA, RT5665_IF2_2_DAC_SEL_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if2_2_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if2_2_adc_enum,
RT5665_DIG_INF2_DATA, RT5665_IF2_2_ADC_SEL_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if3_dac_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if3_dac_enum,
RT
Applied "spi: imx: dynamic burst length adjust for PIO mode" to the spi tree
The patch
spi: imx: dynamic burst length adjust for PIO mode
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 8d4a6cad7adb3ddac32cd52635f20e11de11a658 Mon Sep 17 00:00:00 2001
From: Jiada Wang
Date: Mon, 1 May 2017 03:31:44 -0700
Subject: [PATCH] spi: imx: dynamic burst length adjust for PIO mode
previously burst length (BURST_LENGTH) is always set to equal
to bits_per_word, causes a 10us gap between each word in
transfer, which significantly affects performance.
This patch uses 32 bits transfer to simulate lower bits transfer,
and adjusts burst length runtimely to use biggeest burst length
as possible to reduce the gaps in transfer for PIO mode.
Signed-off-by: Jiada Wang
Signed-off-by: Mark Brown
---
drivers/spi/spi-imx.c | 157 +++---
1 file changed, 149 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index b402530a7a9a..782045f0d79e 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -56,9 +56,11 @@
/* The maximum bytes that a sdma BD can transfer.*/
#define MAX_SDMA_BD_BYTES (1 << 15)
+#define MX51_ECSPI_CTRL_MAX_BURST 512
struct spi_imx_config {
unsigned int speed_hz;
unsigned int bpw;
+ unsigned int len;
};
enum spi_imx_devtype {
@@ -97,12 +99,14 @@ struct spi_imx_data {
unsigned int bytes_per_word;
unsigned int spi_drctl;
- unsigned int count;
+ unsigned int count, count_index;
void (*tx)(struct spi_imx_data *);
void (*rx)(struct spi_imx_data *);
void *rx_buf;
const void *tx_buf;
unsigned int txfifo; /* number of words pushed in tx FIFO */
+ unsigned int dynamic_burst, bpw_rx;
+ unsigned int bpw_w;
/* DMA */
bool usedma;
@@ -252,6 +256,7 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
#define MX51_ECSPI_CTRL_PREDIV_OFFSET 12
#define MX51_ECSPI_CTRL_CS(cs) ((cs) << 18)
#define MX51_ECSPI_CTRL_BL_OFFSET 20
+#define MX51_ECSPI_CTRL_BL_MASK(0xfff << 20)
#define MX51_ECSPI_CONFIG 0x0c
#define MX51_ECSPI_CONFIG_SCLKPHA(cs) (1 << ((cs) + 0))
@@ -279,6 +284,71 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
#define MX51_ECSPI_TESTREG 0x20
#define MX51_ECSPI_TESTREG_LBC BIT(31)
+static void spi_imx_u32_swap_u8(struct spi_transfer *transfer, u32 *buf)
+{
+ int i;
+
+ for (i = 0; i < transfer->len / 4; i++)
+ *(buf + i) = cpu_to_be32(*(buf + i));
+}
+
+static void spi_imx_u32_swap_u16(struct spi_transfer *transfer, u32 *buf)
+{
+ int i;
+
+ for (i = 0; i < transfer->len / 4; i++) {
+ u16 *temp = (u16 *)buf;
+
+ *(temp + i * 2) = cpu_to_be16(*(temp + i * 2));
+ *(temp + i * 2 + 1) = cpu_to_be16(*(temp + i * 2 + 1));
+
+ *(buf + i) = cpu_to_be32(*(buf + i));
+ }
+}
+
+static void spi_imx_buf_rx_swap(struct spi_imx_data *spi_imx)
+{
+ if (!spi_imx->bpw_rx) {
+ spi_imx_buf_rx_u32(spi_imx);
+ return;
+ }
+
+ if (spi_imx->bpw_w == 1)
+ spi_imx_buf_rx_u8(spi_imx);
+ else if (spi_imx->bpw_w == 2)
+ spi_imx_buf_rx_u16(spi_imx);
+}
+
+static void spi_imx_buf_tx_swap(struct spi_imx_data *spi_imx)
+{
+ u32 ctrl, val;
+
+ if (spi_imx->count == spi_imx->count_index) {
+ spi_imx->count_index = spi_imx->count > sizeof(u32) ?
+ spi_imx->count % sizeof(u32) : 0;
+ ctrl = readl(spi_imx->base + MX51_ECSPI_CTRL);
+ ctrl &= ~MX51_ECSPI_CTRL_BL_MASK;
+ if (spi_imx->count >= sizeof(u32)) {
+ val = spi_imx->count - spi_imx->count_index;
+ } else {
+ val = spi_imx->bpw_w;
+ spi_imx->bpw_rx = 1;
+ }
+ ctrl |= ((val * 8 - 1) << MX51_ECSPI_CTRL_BL_OFFSET);
+ writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
+ }
+
+ if (spi_imx->count >= sizeof(u32)) {
+
Applied "spi: bcm63xx-hsspi: Export OF device ID table as module aliases" to the spi tree
The patch
spi: bcm63xx-hsspi: Export OF device ID table as module aliases
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 0b85a84217903e6d24342cc50bc5a685f8355711 Mon Sep 17 00:00:00 2001
From: Andres Galacho
Date: Mon, 1 May 2017 16:13:38 -0400
Subject: [PATCH] spi: bcm63xx-hsspi: Export OF device ID table as module
aliases
The device table is required to load modules based on
modaliases. After adding MODULE_DEVICE_TABLE, below entries
for example will be added to module.alias:
alias: of:N*T*Cbrcm,bcm6328-hsspiC*
alias: of:N*T*Cbrcm,bcm6328-hsspi
Signed-off-by: Andres Galacho
Acked-by: Jonas Gorski
Reviewed-by: Florian Fainelli
Signed-off-by: Mark Brown
---
drivers/spi/spi-bcm63xx-hsspi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-bcm63xx-hsspi.c b/drivers/spi/spi-bcm63xx-hsspi.c
index 5514cd02e93a..4da2d4a524ca 100644
--- a/drivers/spi/spi-bcm63xx-hsspi.c
+++ b/drivers/spi/spi-bcm63xx-hsspi.c
@@ -484,6 +484,7 @@ static const struct of_device_id bcm63xx_hsspi_of_match[] =
{
{ .compatible = "brcm,bcm6328-hsspi", },
{ },
};
+MODULE_DEVICE_TABLE(of, bcm63xx_hsspi_of_match);
static struct platform_driver bcm63xx_hsspi_driver = {
.driver = {
--
2.11.0
Applied "ASoC: rt5514: fix gcc-7 warning" to the asoc tree
The patch
ASoC: rt5514: fix gcc-7 warning
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 03ba791df98d15d07ea74075122af71e35c7611c Mon Sep 17 00:00:00 2001
From: Arnd Bergmann
Date: Thu, 11 May 2017 13:44:38 +0200
Subject: [PATCH] ASoC: rt5514: fix gcc-7 warning
gcc-7 warns that there is a duplicate 'const' specifier in some
variables that are declared using the SOC_ENUM_SINGLE_DECL macro:
sound/soc/codecs/rt5514.c:398:14: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(
sound/soc/codecs/rt5514.c:405:14: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(
This removes one to fix the warning.
Fixes: 4a6180ea7399 ("ASoC: rt5514: add rt5514 codec driver")
Signed-off-by: Arnd Bergmann
Signed-off-by: Mark Brown
---
sound/soc/codecs/rt5514.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/rt5514.c b/sound/soc/codecs/rt5514.c
index f91221b1ddf0..28ab9e2bb051 100644
--- a/sound/soc/codecs/rt5514.c
+++ b/sound/soc/codecs/rt5514.c
@@ -395,14 +395,14 @@ static const char * const rt5514_dmic_src[] = {
"DMIC1", "DMIC2"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5514_stereo1_dmic_enum, RT5514_DIG_SOURCE_CTRL,
RT5514_AD0_DMIC_INPUT_SEL_SFT, rt5514_dmic_src);
static const struct snd_kcontrol_new rt5514_sto1_dmic_mux =
SOC_DAPM_ENUM("Stereo1 DMIC Source", rt5514_stereo1_dmic_enum);
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5514_stereo2_dmic_enum, RT5514_DIG_SOURCE_CTRL,
RT5514_AD1_DMIC_INPUT_SEL_SFT, rt5514_dmic_src);
--
2.11.0
Applied "spi: spidev: use memdup_user" to the spi tree
The patch
spi: spidev: use memdup_user
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From f7929436a286ca31f0365a7013de968017f76818 Mon Sep 17 00:00:00 2001
From: Geliang Tang
Date: Sat, 6 May 2017 23:42:17 +0800
Subject: [PATCH] spi: spidev: use memdup_user
Use memdup_user() helper instead of open-coding to simplify the code.
Signed-off-by: Geliang Tang
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Mark Brown
---
drivers/spi/spidev.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 3b570018705c..d4d2d8d9f3e7 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -324,7 +324,6 @@ static struct spi_ioc_transfer *
spidev_get_ioc_message(unsigned int cmd, struct spi_ioc_transfer __user *u_ioc,
unsigned *n_ioc)
{
- struct spi_ioc_transfer *ioc;
u32 tmp;
/* Check type, command number and direction */
@@ -341,14 +340,7 @@ spidev_get_ioc_message(unsigned int cmd, struct
spi_ioc_transfer __user *u_ioc,
return NULL;
/* copy into scratch area */
- ioc = kmalloc(tmp, GFP_KERNEL);
- if (!ioc)
- return ERR_PTR(-ENOMEM);
- if (__copy_from_user(ioc, u_ioc, tmp)) {
- kfree(ioc);
- return ERR_PTR(-EFAULT);
- }
- return ioc;
+ return memdup_user(u_ioc, tmp);
}
static long
--
2.11.0
Applied "spi: SPI_TI_QSPI should depend on HAS_DMA" to the spi tree
The patch spi: SPI_TI_QSPI should depend on HAS_DMA has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 967d6941f49f1ddd5764d3a09423a63841b9394c Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 4 May 2017 09:37:18 +0200 Subject: [PATCH] spi: SPI_TI_QSPI should depend on HAS_DMA If NO_DMA=y: ERROR: "bad_dma_ops" [drivers/spi/spi-ti-qspi.ko] undefined! Add a dependency on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown --- drivers/spi/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 1761c9004fc1..097883362036 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -457,6 +457,7 @@ config SPI_OMAP24XX config SPI_TI_QSPI tristate "DRA7xxx QSPI controller support" + depends on HAS_DMA depends on ARCH_OMAP2PLUS || COMPILE_TEST help QSPI master controller for DRA7xxx used for flash devices. -- 2.11.0
Applied "spi: spidev: remove unused completion" to the spi tree
The patch
spi: spidev: remove unused completion
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 76bf569466c68fb3705a3b38cdee026df9861101 Mon Sep 17 00:00:00 2001
From: Seraphime Kirkovski
Date: Fri, 5 May 2017 14:30:49 +0200
Subject: [PATCH] spi: spidev: remove unused completion
This removes an unused completion from spidev_sync.
It was introduced in
commit 25d5cb4b0375e ("spi: remove some spidev oops-on-rmmod paths")
and it was no longer used after:
commit 98d6f47958001 ("spi: spidev: use spi_sync instead of spi_async")
Signed-off-by: Seraphime Kirkovski (Haapie)
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Mark Brown
---
drivers/spi/spidev.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 9a2a79a871ba..3b570018705c 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -99,7 +99,6 @@ MODULE_PARM_DESC(bufsiz, "data bytes in biggest supported SPI
message");
static ssize_t
spidev_sync(struct spidev_data *spidev, struct spi_message *message)
{
- DECLARE_COMPLETION_ONSTACK(done);
int status;
struct spi_device *spi;
--
2.11.0
Applied "MAINTAINERS: Update MAX77802 PMIC entry" to the regulator tree
The patch MAINTAINERS: Update MAX77802 PMIC entry has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 64f7d692c5bdfbf0eb6efe4eacc597ff44d0e421 Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas Date: Thu, 4 May 2017 00:36:25 -0400 Subject: [PATCH] MAINTAINERS: Update MAX77802 PMIC entry The Samsung email address will stop working soon, so use my personal email address instead. Also, there used to be a MFD and RTC drivers for max77802 but now these have been merged with the max77686 MFD and RTC drivers. The only driver that's still max77802 specific is the regulator one since there are too many differences with max77686 there to justify merging the two drivers. Signed-off-by: Javier Martinez Canillas Acked-by: Lee Jones Signed-off-by: Mark Brown --- MAINTAINERS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index f7d568b8f133..04796e2d56c2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8054,11 +8054,11 @@ S: Supported F: drivers/power/supply/max14577_charger.c F: drivers/power/supply/max77693_charger.c -MAXIM MAX77802 MULTIFUNCTION PMIC DEVICE DRIVERS -M: Javier Martinez Canillas +MAXIM MAX77802 PMIC REGULATOR DEVICE DRIVER +M: Javier Martinez Canillas L: linux-kernel@vger.kernel.org S: Supported -F: drivers/*/*max77802*.c +F: drivers/regulator/max77802-regulator.c F: Documentation/devicetree/bindings/*/*max77802.txt F: include/dt-bindings/*/*max77802.h -- 2.11.0
Re: [PATCH v2 01/18] dt-bindings: arm: amlogic: Reorder boards
On 05/13/2017 04:33 PM, Andreas Färber wrote: > Enforce groupment by SoCs, and order alphabetically within the group > (with some exceptions). This should facilitate adding new boards. > > Signed-off-by: Andreas Färber > --- > v1 -> v2: > * Rebased (new boards added) > * Pointed out alphabetical order in the binding, too (Rob) > > Documentation/devicetree/bindings/arm/amlogic.txt | 20 +--- > 1 file changed, 13 insertions(+), 7 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt > b/Documentation/devicetree/bindings/arm/amlogic.txt > index bfd5b558477d..cad5b5a48d92 100644 > --- a/Documentation/devicetree/bindings/arm/amlogic.txt > +++ b/Documentation/devicetree/bindings/arm/amlogic.txt > @@ -29,26 +29,32 @@ Boards with the Amlogic Meson GXM S912 SoC shall have the > following properties: >Required root node property: > compatible: "amlogic,s912", "amlogic,meson-gxm"; > > -Board compatible values: > +Board compatible values (alphabetically, grouped by SoC): > + >- "geniatech,atv1200" (Meson6) > + >- "minix,neo-x8" (Meson8) > - - "tronfy,mxq" (Meson8b) > + >- "hardkernel,odroid-c1" (Meson8b) > + - "tronfy,mxq" (Meson8b) > + > + - "amlogic,p200" (Meson gxbb) > + - "amlogic,p201" (Meson gxbb) > + - "hardkernel,odroid-c2" (Meson gxbb) > + - "nexbox,a95x" (Meson gxbb or Meson gxl s905x) >- "tronsmart,vega-s95-pro", "tronsmart,vega-s95" (Meson gxbb) >- "tronsmart,vega-s95-meta", "tronsmart,vega-s95" (Meson gxbb) >- "tronsmart,vega-s95-telos", "tronsmart,vega-s95" (Meson gxbb) > - - "hardkernel,odroid-c2" (Meson gxbb) > - - "amlogic,p200" (Meson gxbb) > - - "amlogic,p201" (Meson gxbb) >- "wetek,hub" (Meson gxbb) >- "wetek,play2" (Meson gxbb) > + >- "amlogic,p212" (Meson gxl s905x) > + - "hwacom,amazetv" (Meson gxl s905x) >- "khadas,vim" (Meson gxl s905x) > >- "amlogic,p230" (Meson gxl s905d) >- "amlogic,p231" (Meson gxl s905d) > - - "hwacom,amazetv" (Meson gxl s905x) > + >- "amlogic,q200" (Meson gxm s912) >- "amlogic,q201" (Meson gxm s912) > - - "nexbox,a95x" (Meson gxbb or Meson gxl s905x) >- "nexbox,a1" (Meson gxm s912) > Like patch 2, S905X should go after S905D. Neil
[PATCH] regmap: add regmap_debugfs_exit as devres action
Instead of manually cleanup regmap_debugfs_exit, use devres action to do the cleanup. This also works for external users of regmap_attach_dev. Signed-off-by: Stefan Agner --- The cast is not that pretty, but I found it better than making regmap_debugfs_exit type unsafe... This fixes warnings when reloading certain drivers making use of regmap_debugfs_exit: imx7d-pinctrl 3033.iomuxc: Failed to create debugfs directory -- Stefan drivers/base/regmap/regmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c index b9a779a4a739..0e32e0e2f00a 100644 --- a/drivers/base/regmap/regmap.c +++ b/drivers/base/regmap/regmap.c @@ -528,6 +528,7 @@ int regmap_attach_dev(struct device *dev, struct regmap *map, return -ENOMEM; } *m = map; + devm_add_action(dev, (void (*)(void *))regmap_debugfs_exit, map); devres_add(dev, m); return 0; @@ -1215,7 +1216,6 @@ void regmap_exit(struct regmap *map) struct regmap_async *async; regcache_exit(map); - regmap_debugfs_exit(map); regmap_range_exit(map); if (map->bus && map->bus->free_context) map->bus->free_context(map->bus_context); -- 2.13.0
Re: [PATCH 28/36] docs-rst: convert s390-drivers DocBook to ReST
On Fri, 12 May 2017 11:00:11 -0300 Mauro Carvalho Chehab wrote: > Use pandoc to convert documentation to ReST by calling > Documentation/sphinx/tmplcvt script. > > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/DocBook/Makefile| 2 +- > Documentation/DocBook/s390-drivers.tmpl | 161 > -- > Documentation/driver-api/index.rst| 1 + > Documentation/driver-api/s390-drivers.rst | 111 > 4 files changed, 113 insertions(+), 162 deletions(-) > delete mode 100644 Documentation/DocBook/s390-drivers.tmpl > create mode 100644 Documentation/driver-api/s390-drivers.rst Acked-by: Cornelia Huck ...but I wonder how good the information in there still is, given that I haven't touched it in ages...
Re: mm: page allocation failures in swap_duplicate -> add_swap_count_continuation
On 05/15/2017 10:03 AM, Michal Hocko wrote:
> On Fri 12-05-17 11:18:42, Christian Borntraeger wrote:
>> Folks,
>>
>> recently I have seen page allocation failures during
>> paging in the paging code:
>> e.g.
>>
>> May 05 21:36:53 kernel: Call Trace:
>> May 05 21:36:53 kernel: ([<00112f62>] show_trace+0x62/0x78)
>> May 05 21:36:53 kernel: [<00113050>] show_stack+0x68/0xe0
>> May 05 21:36:53 kernel: [<004fb97e>] dump_stack+0x7e/0xb0
>> May 05 21:36:53 kernel: [<00299262>] warn_alloc+0xf2/0x190
>> May 05 21:36:53 kernel: [<0029a25a>]
>> __alloc_pages_nodemask+0xeda/0xfe0
>> May 05 21:36:53 kernel: [<002fa570>]
>> alloc_pages_current+0xb8/0x170
>> May 05 21:36:53 kernel: [<002f03fc>]
>> add_swap_count_continuation+0x3c/0x280
>> May 05 21:36:53 kernel: [<002f068c>] swap_duplicate+0x4c/0x80
>> May 05 21:36:53 kernel: [<002dfbfa>] try_to_unmap_one+0x372/0x578
>> May 05 21:36:53 kernel: [<0030131a>] rmap_walk_ksm+0x14a/0x1d8
>> May 05 21:36:53 kernel: [<002e0d60>] try_to_unmap+0x140/0x170
>> May 05 21:36:53 kernel: [<002abc9c>] shrink_page_list+0x944/0xad8
>> May 05 21:36:53 kernel: [<002ac720>]
>> shrink_inactive_list+0x1e0/0x5b8
>> May 05 21:36:53 kernel: [<002ad642>] shrink_node_memcg+0x5e2/0x800
>> May 05 21:36:53 kernel: [<002ad954>] shrink_node+0xf4/0x360
>> May 05 21:36:53 kernel: [<002aeb00>] kswapd+0x330/0x810
>> May 05 21:36:53 kernel: [<00189f14>] kthread+0x144/0x168
>> May 05 21:36:53 kernel: [<008011ea>] kernel_thread_starter+0x6/0xc
>> May 05 21:36:53 kernel: [<008011e4>] kernel_thread_starter+0x0/0xc
>>
>> This seems to be new in 4.11 but the relevant code did not seem to have
>> changed.
>>
>> Something like this
>>
>> diff --git a/mm/swapfile.c b/mm/swapfile.c
>> index 1781308..b2dd53e 100644
>> --- a/mm/swapfile.c
>> +++ b/mm/swapfile.c
>> @@ -3039,7 +3039,7 @@ int swap_duplicate(swp_entry_t entry)
>> int err = 0;
>>
>> while (!err && __swap_duplicate(entry, 1) == -ENOMEM)
>> - err = add_swap_count_continuation(entry, GFP_ATOMIC);
>> + err = add_swap_count_continuation(entry, GFP_ATOMIC |
>> __GFP_NOWARN);
>> return err;
>> }
>>
>>
>> seems not appropriate, because this code does not know if the caller can
>> handle returned errors.
>>
>> Would something like the following (white space damaged cut'n'paste be ok?
>> (the try_to_unmap_one change looks fine, not sure if copy_one_pte does the
>> right thing)
>
> No, it won't. If you want to silent the warning then explain _why_ it is
> a good approach. It is not immediatelly clear to me.
Consider my mail a bug report, not a proper fix. As far as I can tell,
try_to_unmap_one
can handle allocation failure gracefully, so not warn here _looks_ fine to me.
>
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 235ba51..3ae6f33 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -898,7 +898,7 @@ copy_one_pte(struct mm_struct *dst_mm, struct mm_struct
>> *src_mm,
>> swp_entry_t entry = pte_to_swp_entry(pte);
>>
>> if (likely(!non_swap_entry(entry))) {
>> - if (swap_duplicate(entry) < 0)
>> + if (swap_duplicate(entry, __GFP_NOWARN) < 0)
>> return entry.val;
This code has special casing for the allocation failure path, but I cannot
decide if it does the right thing here.
>
> Moreover if you add a gfp_mask argument then the _full_ mask should be
> given rather than just one of the modifiers.
>
Re: [PATCH v2 08/18] arm64: dts: meson-gxl-s905x: Comment typo fix
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> Reviewed-by: Neil Armstrong
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2: Unchanged
>
> arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> index 0f78d836edaf..3314a0b3dad9 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> @@ -48,7 +48,7 @@
> compatible = "amlogic,s905x", "amlogic,meson-gxl";
> };
>
> -/* S905X Only has access to its internal PHY */
> +/* S905X only has access to its internal PHY */
> ðmac {
> phy-mode = "rmii";
> phy-handle = <&internal_phy>;
>
Reviewed-by: Neil Armstrong
Re: [PATCH v2 05/18] arm64: dts: meson-gx-p23x-q20x: Fix Wifi node name
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> bcrmf -> brcmf -> wifi
>
> Fixes: bb51b5350d2f ("ARM64: dts: Add support for Meson GXM")
> Cc: Neil Armstrong
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2:
> * Renamed node brmcf -> wifi (Rob)
>
> arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> index a84e27622639..25eed18a7439 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> @@ -154,7 +154,7 @@
> vmmc-supply = <&vddao_3v3>;
> vqmmc-supply = <&vddio_boot>;
>
> - brcmf: bcrmf@1 {
> + brcmf: wifi@1 {
> reg = <1>;
> compatible = "brcm,bcm4329-fmac";
> };
>
Reviewed-by: Neil Armstrong
Re: [PATCH v2 13/18] arm64: dts: meson-gxbb-nexbox-a95x: Fix node order
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2:
> * Rebased (new nodes added)
>
> .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts| 52
> +++---
> 1 file changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> index 87198eafb04b..a1078b3e1c76 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> @@ -165,10 +165,10 @@
> };
> };
>
> -&uart_AO {
> - status = "okay";
> - pinctrl-0 = <&uart_ao_a_pins>;
> - pinctrl-names = "default";
> +&cvbs_vdac_port {
> + cvbs_vdac_out: endpoint {
> + remote-endpoint = <&cvbs_connector_in>;
> + };
> };
>
> ðmac {
> @@ -195,12 +195,32 @@
> };
> };
>
> +&hdmi_tx {
> + status = "okay";
> + pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> + pinctrl-names = "default";
> +};
> +
> +&hdmi_tx_tmds_port {
> + hdmi_tx_tmds_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> +};
> +
> &ir {
> status = "okay";
> pinctrl-0 = <&remote_input_ao_pins>;
> pinctrl-names = "default";
> };
>
> +&pwm_ef {
> + status = "okay";
> + pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-names = "default";
> + clocks = <&clkc CLKID_FCLK_DIV4>;
> + clock-names = "clkin0";
> +};
> +
> /* Wireless SDIO Module */
> &sd_emmc_a {
> status = "okay";
> @@ -260,28 +280,8 @@
> vqmmc-supply = <&vddio_boot>;
> };
>
> -&pwm_ef {
> - status = "okay";
> - pinctrl-0 = <&pwm_e_pins>;
> - pinctrl-names = "default";
> - clocks = <&clkc CLKID_FCLK_DIV4>;
> - clock-names = "clkin0";
> -};
> -
> -&cvbs_vdac_port {
> - cvbs_vdac_out: endpoint {
> - remote-endpoint = <&cvbs_connector_in>;
> - };
> -};
> -
> -&hdmi_tx {
> +&uart_AO {
> status = "okay";
> - pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> + pinctrl-0 = <&uart_ao_a_pins>;
> pinctrl-names = "default";
> };
> -
> -&hdmi_tx_tmds_port {
> - hdmi_tx_tmds_out: endpoint {
> - remote-endpoint = <&hdmi_connector_in>;
> - };
> -};
>
Hi Andreas,
Like a previous attempt, I'm not OK with such rework since it will break bisect
and add complexity for new patches handling.
The order is not alphabetically ordered, live with it.
Neil
Re: [PATCH v2 09/18] arm64: dts: meson-gxbb-wetek-hub: Reference CVBS node by label
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> Makes the override safer.
>
> Acked-by: Neil Armstrong
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2:
> * Extended commit message
>
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> index a5be438a5c03..0ec1d19522dd 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -126,7 +126,7 @@
> clock-names = "ext_clock";
> };
>
> - cvbs-connector {
> + cvbs_connector: cvbs-connector {
> compatible = "composite-video-connector";
>
> port {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
> index f057fb48fee5..1878ac2b2b83 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
> @@ -59,10 +59,10 @@
> panic-indicator;
> };
> };
> +};
>
> - cvbs-connector {
> - status = "disabled";
> - };
> +&cvbs_connector {
> + status = "disabled";
> };
>
> ðmac {
>
Reviewed-by: Neil Armstrong
Re: [PATCH v2 03/18] arm64: dts: meson-gxbb-vega-s95: Fix Wifi node name
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> bcrmf -> brcmf -> wifi
>
> Fixes: ab5b24fdd2d5 ("ARM64: dts: meson-gxbb-vega-s95: Add SD/SDIO/MMC and
> PWM nodes")
> Cc: Martin Blumenstingl
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2:
> * Renamed node brmcf -> wifi (Rob)
>
> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
> index aefa66dff72d..f4bfee8e2e08 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
> @@ -186,7 +186,7 @@
> vmmc-supply = <&vcc_3v3>;
> vqmmc-supply = <&vcc_1v8>;
>
> - brcmf: bcrmf@1 {
> + brcmf: wifi@1 {
> reg = <1>;
> compatible = "brcm,bcm4329-fmac";
> };
>
Reviewed-by: Neil Armstrong
Re: [PATCH 2/2] spi: spidev: document SPI_IOC_WR_DEFAULT_MAX_SPEED_HZ
On Sun, May 14, 2017 at 06:27:43PM +0900, Mark Brown wrote: > On Tue, May 09, 2017 at 02:24:01PM +0200, Seraphime Kirkovski wrote: > > This adds documentation of the new spidev ioctl. > > This should have been part of the first path adding the new ioctl() :( Will change.
Re: [PATCH v2 04/18] arm64: dts: meson-gxbb-p20x: Fix Wifi node name
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> bcrmf -> brcmf -> wifi
>
> Fixes: ab3943fe57a2 ("ARM64: dts: meson-gxbb: Add P20x Wifi SDIO support")
> Cc: Neil Armstrong
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2:
> * Renamed node brmcf -> wifi (Rob)
>
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> index 3c6c0b7f4187..a5be438a5c03 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -198,7 +198,7 @@
> vmmc-supply = <&vddao_3v3>;
> vqmmc-supply = <&vddio_boot>;
>
> - brcmf: bcrmf@1 {
> + brcmf: wifi@1 {
> reg = <1>;
> compatible = "brcm,bcm4329-fmac";
> };
>
Reviewed-by: Neil Armstrong
Re: [PATCH v2 06/18] arm64: dts: meson-gxl-s905x-khadas-vim: Fix Wifi node name
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> bcrmf -> brcmf -> wifi
>
> Fixes: e15d2774b8c0 ("ARM64: dts: meson-gxl: add support for the Khadas VIM
> board")
> Cc: Martin Blumenstingl
> Signed-off-by: Andreas Färber
> ---
> v2: New
>
> arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
> index 3c8b0b51ef27..6a81f0168da5 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
> @@ -95,7 +95,7 @@
> };
>
> &sd_emmc_a {
> - brcmf: bcrmf@1 {
> + brcmf: wifi@1 {
> reg = <1>;
> compatible = "brcm,bcm4329-fmac";
> };
>
Reviewed-by: Neil Armstrong
Re: [PATCH v2 07/18] arm64: dts: meson-gxm-nexbox-a1: Drop UART comment
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> Product pictures show no DB9 connector, so this seems copy&paste.
>
> Acked-by: Neil Armstrong
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2: Unchanged
>
> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> index 11b0bf46a95c..920fac10de93 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -113,7 +113,6 @@
> };
> };
>
> -/* This UART is brought out to the DB9 connector */
> &uart_AO {
> status = "okay";
> pinctrl-0 = <&uart_ao_a_pins>;
>
Reviewed-by: Neil Armstrong
[PATCH 1/2] ALSA: firewire-tascam: Fix infinite loop in snd_tscm_stream_get_rate()
Obviously the intention was to put a limit on the maximum number of
operations. However, for this to work, the check should be
"&& trials++ < 5", not "|| trials++ < 5".
Fixes: 35efa5c489de63a9 ("ALSA: firewire-tascam: add streaming functionality")
Signed-off-by: Geert Uytterhoeven
---
Compile-tested only.
Triggered by a false-positive warning from gcc-4.1.2:
warning: ‘err’ may be used uninitialized in this function
---
sound/firewire/tascam/tascam-stream.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/firewire/tascam/tascam-stream.c
b/sound/firewire/tascam/tascam-stream.c
index f1657a4e0621ef49..e433b92ac6904db5 100644
--- a/sound/firewire/tascam/tascam-stream.c
+++ b/sound/firewire/tascam/tascam-stream.c
@@ -84,7 +84,7 @@ int snd_tscm_stream_get_rate(struct snd_tscm *tscm, unsigned
int *rate)
unsigned int trials = 0;
int err;
- while (data == 0x0 || trials++ < 5) {
+ while (data == 0x0 && trials++ < 5) {
err = get_clock(tscm, &data);
if (err < 0)
return err;
--
2.7.4
[PATCH 2/2] ALSA: firewire-tascam: Use do { } while for loops executed at least once
If a loop is intended to be executed at least once, it is better to use
"do { ... } while (...)" instead of "while (...) { ... }".
The former is easier to understand for the casual reviewer, and doesn't
require preinitializing the canary variable.
Signed-off-by: Geert Uytterhoeven
---
Compile-tested only.
---
sound/firewire/tascam/tascam-stream.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/firewire/tascam/tascam-stream.c
b/sound/firewire/tascam/tascam-stream.c
index e433b92ac6904db5..4ea6845aae87fdef 100644
--- a/sound/firewire/tascam/tascam-stream.c
+++ b/sound/firewire/tascam/tascam-stream.c
@@ -80,17 +80,17 @@ static int set_clock(struct snd_tscm *tscm, unsigned int
rate,
int snd_tscm_stream_get_rate(struct snd_tscm *tscm, unsigned int *rate)
{
- u32 data = 0x0;
unsigned int trials = 0;
+ u32 data;
int err;
- while (data == 0x0 && trials++ < 5) {
+ do {
err = get_clock(tscm, &data);
if (err < 0)
return err;
data = (data & 0xff00) >> 24;
- }
+ } while (data == 0x0 && ++trials < 5);
/* Check base rate. */
if ((data & 0x0f) == 0x01)
--
2.7.4
RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform
Hi Williamson, We cannot assume BIOS supports SR-IOV, actually only newer server motherboard BIOS supports SR-IOV. Normal desktop motherboard BIOS or older server motherboard BIOS doesn't support SR-IOV. This issue would happen if an user plugs our AMD SR-IOV capable GPU card to a normal desktop motherboard. I agree that failure to allocate VF resources should leave the device in no worse condition than before it tried. I hope kernel could allocate PF device resource before allocating VF device resource, and keep PF device resource valid and functional if failed to allocate VF device resource. I will send out dmesg log lspci info tomorrow. Thanks. -Collins Cheng -Original Message- From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Friday, May 12, 2017 10:43 PM To: Cheng, Collins Cc: Bjorn Helgaas ; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Deucher, Alexander ; Zytaruk, Kelly ; Yinghai Lu Subject: Re: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform On Fri, 12 May 2017 04:51:43 + "Cheng, Collins" wrote: > Hi Williamson, > > I verified the patch is working for both AMD SR-IOV GPU and Intel SR-IOV NIC. > I don't think it is redundant to check the VF BAR valid before call > sriov_init(), it is safe and saving boot time, also there is no a better > method to know if system BIOS has correctly initialized the SR-IOV capability > or not. It also masks an underlying bug and creates a maintenance issue that we won't know when it's safe to remove this workaround. I don't think faster boot is valid rationale, in one case SR-IOV is completely disabled, the other we attempt to allocate the resources the BIOS failed to provide. I expect this is also a corner case, the BIOS should typically support SR-IOV, therefore this situation should be an exception. > I did not try to fix the issue from the kernel resource allocation > perspective, it is because: > 1. I am not very familiar with the PCI resource allocation scheme in > kernel. For example, in sriov_init(), kernel will re-assign the PCI resource > for both VF and PF. I don't understand why kernel allocates resource for VF > firstly, then PF. If it is PF firstly, then this issue could be avoided. > 2. I am not sure if kernel has error handler if PCI resource allocation > failed. In this case, kernel cannot allocate enough resource to PF. It should > trigger some error handler to either just keep original BAR values set by > system BIOS, or disable this device and log errors. I think these are the issues we should be trying to solve and I'm sure folks on the linux-pci list can help us identify the bug. Minimally, failure to allocate VF resources should leave the device in no worse condition than before it tried. Perhaps you could post more details about the issue, boot with pci=earlydump, post dmesg of a boot where the PF resources are incorrectly re-allocated, and include lspci -vvv for the SR-IOV device. Also, please test with the latest upstream kernel, upstream only patches old kernels through stable backports of commits to the latest kernel. Adding Yinghai as a resource allocation expert. Thanks, Alex > -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Friday, May 12, 2017 12:01 PM > To: Cheng, Collins > Cc: Bjorn Helgaas ; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org; Deucher, Alexander > ; Zytaruk, Kelly > Subject: Re: [PATCH] PCI: Make SR-IOV capable GPU working on the > SR-IOV incapable platform > > On Fri, 12 May 2017 03:42:46 + > "Cheng, Collins" wrote: > > > Hi Williamson, > > > > GPU card needs more BAR aperture resource than other PCI devices. For > > example, Intel SR-IOV network card only require 512KB memory resource for > > all VFs. AMD SR-IOV GPU card needs 256MB x16 VF = 4GB memory resource for > > frame buffer BAR aperture. > > > > If the system BIOS supports SR-IOV, it will reserve enough resource for all > > VF BARs. If the system BIOS doesn't support SR-IOV or cannot allocate the > > enough resource for VF BARs, only PF BAR will be assigned and VF BARs are > > empty. Then system boots to Linux kernel and kernel doesn't check if the VF > > BARs are empty or valid. Kernel will re-assign the BAR resources for PF and > > all VFs. The problem I saw is that kernel will fail to allocate PF BAR > > resource because some resources are assigned to VF, this is not expected. > > So kernel might need to do some check before re-assign the PF/VF resource, > > so that PF device will be correctly assigned BAR resource and user can use > > PF device. > > So the problem is that something bad happens when the kernel is trying > to reallocate resources in order to fulfill the requirements of the > VFs, leaving the PF resources incorrectly programmed? Why not just > fix that bug rather than creating special handling for this > vendor/class of
Re: [PATCH v2 10/18] arm64: dts: meson-gxbb: Fix node order
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2:
> * Rebased (new nodes added)
>
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 171
> +++-
> 1 file changed, 91 insertions(+), 80 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> index 4afe1c46ec11..92dd5d1d73c8 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -97,13 +97,6 @@
> };
> };
>
> -ðmac {
> - clocks = <&clkc CLKID_ETH>,
> - <&clkc CLKID_FCLK_DIV2>,
> - <&clkc CLKID_MPLL2>;
> - clock-names = "stmmaceth", "clkin0", "clkin1";
> -};
> -
> &aobus {
> pinctrl_aobus: pinctrl@14 {
> compatible = "amlogic,meson-gxbb-aobus-pinctrl";
> @@ -252,6 +245,97 @@
> };
> };
>
> +&apb {
> + mali: gpu@c {
> + compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
> + reg = <0x0 0xc 0x0 0x4>;
> + interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> + interrupt-names = "gp", "gpmmu", "pp", "pmu",
> + "pp0", "ppmmu0", "pp1", "ppmmu1",
> + "pp2", "ppmmu2";
> + clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
> + clock-names = "bus", "core";
> +
> + /*
> + * Mali clocking is provided by two identical clock paths
> + * MALI_0 and MALI_1 muxed to a single clock by a glitch
> + * free mux to safely change frequency while running.
> + */
> + assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
> + <&clkc CLKID_MALI_0>,
> + <&clkc CLKID_MALI>; /* Glitch free mux */
> + assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
> + <0>, /* Do Nothing */
> + <&clkc CLKID_MALI_0>;
> + assigned-clock-rates = <0>, /* Do Nothing */
> +<6>,
> +<0>; /* Do Nothing */
> + };
> +};
> +
> +&cbus {
> + spifc: spi@8c80 {
> + compatible = "amlogic,meson-gxbb-spifc";
> + reg = <0x0 0x08c80 0x0 0x80>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&clkc CLKID_SPI>;
> + status = "disabled";
> + };
> +};
> +
> +ðmac {
> + clocks = <&clkc CLKID_ETH>,
> + <&clkc CLKID_FCLK_DIV2>,
> + <&clkc CLKID_MPLL2>;
> + clock-names = "stmmaceth", "clkin0", "clkin1";
> +};
> +
> +&hdmi_tx {
> + compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
> + resets = <&reset RESET_HDMITX_CAPB3>,
> + <&reset RESET_HDMI_SYSTEM_RESET>,
> + <&reset RESET_HDMI_TX>;
> + reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
> + clocks = <&clkc CLKID_HDMI_PCLK>,
> + <&clkc CLKID_CLK81>,
> + <&clkc CLKID_GCLK_VENCI_INT0>;
> + clock-names = "isfr", "iahb", "venci";
> +};
> +
> +&hiubus {
> + clkc: clock-controller@0 {
> + compatible = "amlogic,gxbb-clkc";
> + #clock-cells = <1>;
> + reg = <0x0 0x0 0x0 0x3db>;
> + };
> +};
> +
> +&i2c_A {
> + clocks = <&clkc CLKID_I2C>;
> +};
> +
> +&i2c_AO {
> + clocks = <&clkc CLKID_AO_I2C>;
> +};
> +
> +&i2c_B {
> + clocks = <&clkc CLKID_I2C>;
> +};
> +
> +&i2c_C {
> + clocks = <&clkc CLKID_I2C>;
> +};
> +
> &periphs {
> pinctrl_periphs: pinctrl@4b0 {
> compatible = "amlogic,meson-gxbb-periphs-pinctrl";
> @@ -521,67 +605,6 @@
> };
> };
>
> -&hiubus {
> - clkc: clock-controller@0 {
> - compatible = "amlogic,gxbb-clkc";
> - #clock-cells = <1>;
> - reg = <0x0 0x0 0x0 0x3db>;
> - };
> -};
> -
> -&apb {
> - mali: gpu@c {
> - compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
> - reg = <0x0 0xc 0x0 0x4>;
> - interrupts = ,
> - ,
> - ,
> - ,
> - ,
> - ,
> - ,
> - ,
> - ,
> - ;
> - interrupt-names = "gp", "gpmmu", "pp", "pmu",
> - "pp0", "ppmmu0", "pp1", "ppmmu1",
> - "pp2", "ppmmu2";
> - clocks = <&clkc CLKID_CLK81>,
Re: [PATCH v2 12/18] arm64: dts: meson-gxbb-vega-s95: Fix node order
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2:
> * Rebased (new nodes added)
>
> .../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 54
> +++---
> 1 file changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
> index f4bfee8e2e08..346753fb6324 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
> @@ -111,18 +111,6 @@
> };
> };
>
> -&uart_AO {
> - status = "okay";
> - pinctrl-0 = <&uart_ao_a_pins>;
> - pinctrl-names = "default";
> -};
> -
> -&ir {
> - status = "okay";
> - pinctrl-0 = <&remote_input_ao_pins>;
> - pinctrl-names = "default";
> -};
> -
> ðmac {
> status = "okay";
> pinctrl-0 = <ð_rgmii_pins>;
> @@ -149,21 +137,18 @@
> };
> };
>
> -&usb0_phy {
> - status = "okay";
> - phy-supply = <&usb_vbus>;
> -};
> -
> -&usb1_phy {
> - status = "okay";
> -};
> -
> -&usb0 {
> +&ir {
> status = "okay";
> + pinctrl-0 = <&remote_input_ao_pins>;
> + pinctrl-names = "default";
> };
>
> -&usb1 {
> +&pwm_ef {
> status = "okay";
> + pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-names = "default";
> + clocks = <&clkc CLKID_FCLK_DIV4>;
> + clock-names = "clkin0";
> };
>
> /* Wireless SDIO Module */
> @@ -229,10 +214,25 @@
> vmmcq-sumpply = <&vcc_1v8>;
> };
>
> -&pwm_ef {
> +&uart_AO {
> status = "okay";
> - pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-0 = <&uart_ao_a_pins>;
> pinctrl-names = "default";
> - clocks = <&clkc CLKID_FCLK_DIV4>;
> - clock-names = "clkin0";
> +};
> +
> +&usb0_phy {
> + status = "okay";
> + phy-supply = <&usb_vbus>;
> +};
> +
> +&usb1_phy {
> + status = "okay";
> +};
> +
> +&usb0 {
> + status = "okay";
> +};
> +
> +&usb1 {
> + status = "okay";
> };
>
Hi Andreas,
Like a previous attempt, I'm not OK with such rework since it will break bisect
and add complexity for new patches handling.
The order is not alphabetically ordered, live with it.
Neil
[PATCH 1/2] spi: spidev: introduce SPI_IOC_WR_DEFAULT_MAX_SPEED_HZ command
christophe.bla...@gmail.com, f...@haapie.com Bcc: Subject: Re: [PATCH 1/2] spi: spidev: introduce SPI_IOC_WR_DEFAULT_MAX_SPEED_HZ command Reply-To: In-Reply-To: <20170514092716.kqx634djffgj3...@sirena.org.uk> On Sun, May 14, 2017 at 06:27:16PM +0900, Mark Brown wrote: > On Tue, May 09, 2017 at 02:24:00PM +0200, Seraphime Kirkovski wrote: > > > I think, this change is necessary, on the one hand, because there are still > > a lot of longterm[2] supported kernels out there, whose users may be > > relying on > > SPI_IOC_WR_MAX_SPEED being system-wide and, on the other hand, this > > same command has been exhibiting a different behaviour for 3 years now, > > so its users may break, if 9169051617df7 is reverted in one way or > > another. > > Do we have any evidence that such users exist? I can't guarantee for other such users, but this change did disturb our workflow. We were using this feature to prototype and test hardware/firmware at different speeds. I was thinking this morning that maybe a sysfs interface will be better for setting global settings. Do you prefer ?
Re: [PATCH v2 11/18] arm64: dts: meson-gxbb-odroidc2: Fix node order
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2:
> * Rebased (new nodes added)
>
> .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 108
> ++---
> 1 file changed, 54 insertions(+), 54 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 54a9c6a6b392..d147c853ab05 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -137,16 +137,6 @@
> };
> };
>
> -&scpi_clocks {
> - status = "disabled";
> -};
> -
> -&uart_AO {
> - status = "okay";
> - pinctrl-0 = <&uart_ao_a_pins>;
> - pinctrl-names = "default";
> -};
> -
> ðmac {
> status = "okay";
> pinctrl-0 = <ð_rgmii_pins>;
> @@ -172,6 +162,33 @@
> };
> };
>
> +&gpio_ao {
> + /*
> + * WARNING: The USB Hub on the Odroid-C2 needs a reset signal
> + * to be turned high in order to be detected by the USB Controller
> + * This signal should be handled by a USB specific power sequence
> + * in order to reset the Hub when USB bus is powered down.
> + */
> + usb-hub {
> + gpio-hog;
> + gpios = ;
> + output-high;
> + line-name = "usb-hub-reset";
> + };
> +};
> +
> +&i2c_A {
> + status = "okay";
> + pinctrl-0 = <&i2c_a_pins>;
> + pinctrl-names = "default";
> +};
> +
> +&ir {
> + status = "okay";
> + pinctrl-0 = <&remote_input_ao_pins>;
> + pinctrl-names = "default";
> +};
> +
> &pinctrl_aobus {
> gpio-line-names = "UART TX", "UART RX", "VCCK En", "TF 3V3/1V8 En",
> "USB HUB nRESET", "USB OTG Power En",
> @@ -223,55 +240,15 @@
> "";
> };
>
> -&ir {
> - status = "okay";
> - pinctrl-0 = <&remote_input_ao_pins>;
> - pinctrl-names = "default";
> -};
> -
> -&i2c_A {
> - status = "okay";
> - pinctrl-0 = <&i2c_a_pins>;
> - pinctrl-names = "default";
> -};
> -
> -&gpio_ao {
> - /*
> - * WARNING: The USB Hub on the Odroid-C2 needs a reset signal
> - * to be turned high in order to be detected by the USB Controller
> - * This signal should be handled by a USB specific power sequence
> - * in order to reset the Hub when USB bus is powered down.
> - */
> - usb-hub {
> - gpio-hog;
> - gpios = ;
> - output-high;
> - line-name = "usb-hub-reset";
> - };
> -};
> -
> -&usb0_phy {
> - status = "okay";
> - phy-supply = <&usb_otg_pwr>;
> -};
> -
> -&usb1_phy {
> - status = "okay";
> -};
> -
> -&usb0 {
> - status = "okay";
> -};
> -
> -&usb1 {
> - status = "okay";
> -};
> -
> &saradc {
> status = "okay";
> vref-supply = <&vcc1v8>;
> };
>
> +&scpi_clocks {
> + status = "disabled";
> +};
> +
> /* SD */
> &sd_emmc_b {
> status = "okay";
> @@ -309,3 +286,26 @@
> vmmc-supply = <&vcc3v3>;
> vqmmc-supply = <&vcc1v8>;
> };
> +
> +&uart_AO {
> + status = "okay";
> + pinctrl-0 = <&uart_ao_a_pins>;
> + pinctrl-names = "default";
> +};
> +
> +&usb0_phy {
> + status = "okay";
> + phy-supply = <&usb_otg_pwr>;
> +};
> +
> +&usb1_phy {
> + status = "okay";
> +};
> +
> +&usb0 {
> + status = "okay";
> +};
> +
> +&usb1 {
> + status = "okay";
> +};
>
Hi Andreas,
Like a previous attempt, I'm not OK with such rework since it will break bisect
and add complexity for new patches handling.
The order is not alphabetically ordered, live with it.
Neil
Re: [PATCH 1/3] arm64: dts: hi3660: add pcie node
Hello Song
You forgot to add the device tree maintainers
and the device tree mailing list to this patch.
If you use ./scripts/get_maintainer.pl
it will show you this information.
Regards,
Niklas
On 05/15/2017 08:27 AM, Song Xiaowei wrote:
> Add PCIe node for hi3660, and add binding documentation.
>
> Cc: Guodong Xu
> Signed-off-by: Song Xiaowei
> ---
> .../devicetree/bindings/pci/hisilicon-pcie.txt | 52
> ++
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 31 +
> 2 files changed, 83 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> index a339dbb15493..71491178c86c 100644
> --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> @@ -85,3 +85,55 @@ Example:
>0x0 0 0 4 &mbigen_pcie0 650 4>;
> status = "ok";
> };
> +
> +
> +
> +HiSilicon Kirin SoC PCIe host DT description
> +
> +Kirin PCIe host controller is also based on Designware PCI core.
> +It shares common functions with PCIe Designware core driver and inherits
> +common properties defined in
> +Documentation/devicetree/bindings/pci/designware-pci.txt.
> +
> +Additional properties are described here:
> +
> +Required properties
> +- compatible: Should contain "hisilicon,kirin-pcie".
> +- reg: Should contain rc_dbi, apb, phy, config registers location and length.
> +- reg-names: Must include the following entries:
> + "dbi": controller configuration registers;
> + "apb": apb Ctrl register;
> + "phy": apb PHY register;
> + "config": PCIe configuration space registers.
> +- reset-gpio: perst assert/deassert gpio
> +
> +Optional properties:
> +- status: Either "ok" or "disabled".
> +
> +Kirin960 Example:
> +kirin_pcie@f400 {
> +compatible = "hisilicon,kirin-pcie";
> +reg = <0x0 0xf400 0x0 0x1000>, <0x0 0xff3fe000
> 0x0 0x1000>,
> + <0x0 0xf3f2 0x0 0x4>, <0x0
> 0xF500 0 0x2000>;
> +reg-names = "dbi","apb","phy", "config";
> +bus-range = <0x0 0x1>;
> +#address-cells = <3>;
> +#size-cells = <2>;
> +device_type = "pci";
> +ranges = <0x0200 0x0 0x 0x0 0xf600
> 0x0 0x200>;
> +num-lanes = <1>;
> +#interrupt-cells = <1>;
> +interrupt-map-mask = <0xf800 0 0 7>;
> + interrupt-map = <0x0 0 0 2 &gic 0 0 0 283 4>,
> +<0x0 0 0 3 &gic 0 0 0 284 4>,
> +<0x0 0 0 4 &gic 0 0 0 285 4>;
> +clocks = <&crg_ctrl HI3660_PCIEPHY_REF>,
> +<&crg_ctrl HI3660_CLK_GATE_PCIEAUX>,
> +<&crg_ctrl HI3660_PCLK_GATE_PCIE_PHY>,
> +<&crg_ctrl HI3660_PCLK_GATE_PCIE_SYS>,
> +<&crg_ctrl HI3660_ACLK_GATE_PCIE>;
> +clock-names = "pcie_phy_ref", "pcie_aux",
> +"pcie_apb_phy", "pcie_apb_sys", "pcie_aclk";
> +reset-gpio = <&gpio11 1 0 >;
> +status = "ok";
> +};
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index 3983086bd67b..2406a54947df 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -156,5 +156,36 @@
> clock-names = "uartclk", "apb_pclk";
> status = "disabled";
> };
> +
> + kirin_pcie@f400 {
> + compatible = "hisilicon,kirin-pcie";
> + reg = <0x0 0xf400 0x0 0x1000>,
> + <0x0 0xff3fe000 0x0 0x1000>,
> + <0x0 0xf3f2 0x0 0x4>,
> + <0x0 0xF500 0x0 0x2000>;
> + reg-names = "dbi", "apb", "phy", "config";
> + bus-range = <0x0 0x1>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + ranges = <0x0200 0x0 0x 0x0
> + 0xf600 0x0 0x200>;
> + num-lanes = <1>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0xf800 0 0 7>;
> + interrupt-map = <0x0 0 0 1 &gic 0 0 0 282 4>,
> + <0x0 0 0 2 &gic 0 0 0 283 4>,
> + <0x0 0 0 3 &gic 0 0 0 284 4>,
> +
Re: [BUG nohz]: wrong user and system time accounting
Ping,
2017-05-02 18:01 GMT+08:00 Wanpeng Li :
> Cc Paolo,
> 2017-04-13 21:32 GMT+08:00 Frederic Weisbecker :
>> On Thu, Apr 13, 2017 at 12:31:12PM +0800, Wanpeng Li wrote:
>>> 2017-04-12 22:57 GMT+08:00 Thomas Gleixner :
>>> > On Wed, 12 Apr 2017, Frederic Weisbecker wrote:
>>> >> On Tue, Apr 11, 2017 at 04:22:48PM +0200, Thomas Gleixner wrote:
>>> >> > It's not different from the current jiffies based stuff at all. Same
>>> >> > failure mode.
>>> >>
>>> >> Yes you're right, I got confused again. So to fix this we could do our
>>> >> snapshots
>>> >> at a frequency lower than HZ but still high enough to avoid overhead.
>>> >>
>>> >> Something like TICK_NSEC / 2 ?
>>> >
>>> > If you are using TSC anyway then you can do proper accumulation for both
>>> > system and user and only account the data when the accumulation is more
>>> > than a jiffie.
>>>
>>> So I implement it as below:
>>>
>>> - HZ=1000.
>>> 1) two cpu hogs on cpu in nohz_full mode, 100% user time
>>> 2) Luzi's testcase, ~95% user time, ~5% idle time (as we expected)
>>> - HZ=250
>>>1) two cpu hogs on cpu in nohz_full mode, 100% user time
>>>2) Luzi's testcase, 100% idle
>>>
>>> So the codes below still not work correctly for HZ=250, any suggestions?
>>
>> Right, so first lets reorder that code a bit so we can see clear inside :-)
>>
>>>
>>> -->8-
>>>
>>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>>> index d67eee8..6a11771 100644
>>> --- a/include/linux/sched.h
>>> +++ b/include/linux/sched.h
>>> @@ -668,6 +668,8 @@ struct task_struct {
>>> #ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
>>> seqcount_tvtime_seqcount;
>>> unsigned long longvtime_snap;
>>> +u64vtime_acct_utime;
>>> +u64vtime_acct_stime;
>>
>> You need to accumulate guest and steal time as well.
>>
>
> Hi Frederic,
>
> Sorry for the delay since I'm too busy recently, I just add guest time
> and idle time accumulations as below, the code work as we expected for
> native kernel, however, the testcase fails when it runs in kvm guest.
> Top shows ~99% sys for Luzi's testcase "./acct-bug 1 995" which we
> expect 95% user and %5 idle. In addition, what's the design idea of
> steal time accumluation in your mind? Pass the tsk parameter in the
> function get_vtime_delta() down to the function
> steal_account_process_time()?
>
> -->8-
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 4cf9a59..56815cd 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -672,6 +672,10 @@ struct task_struct {
> #ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
> seqcount_tvtime_seqcount;
> unsigned long longvtime_snap;
> +u64vtime_acct_utime;
> +u64vtime_acct_stime;
> +u64vtime_acct_idle_time;
> +u64vtime_acct_guest_time;
> enum {
> /* Task is sleeping or running in a CPU with VTIME inactive: */
> VTIME_INACTIVE = 0,
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index f3778e2b..2d950c6 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -676,18 +676,19 @@ void thread_group_cputime_adjusted(struct
> task_struct *p, u64 *ut, u64 *st)
> #ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
> static u64 vtime_delta(struct task_struct *tsk)
> {
> -unsigned long now = READ_ONCE(jiffies);
> +unsigned long long clock;
>
> -if (time_before(now, (unsigned long)tsk->vtime_snap))
> +clock = sched_clock();
> +if (clock < tsk->vtime_snap)
> return 0;
>
> -return jiffies_to_nsecs(now - tsk->vtime_snap);
> +return clock - tsk->vtime_snap;
> }
>
> static u64 get_vtime_delta(struct task_struct *tsk)
> {
> -unsigned long now = READ_ONCE(jiffies);
> -u64 delta, other;
> +u64 delta = vtime_delta(tsk);
> +u64 other;
>
> /*
> * Unlike tick based timing, vtime based timing never has lost
> @@ -696,17 +697,16 @@ static u64 get_vtime_delta(struct task_struct *tsk)
> * elapsed time. Limit account_other_time to prevent rounding
> * errors from causing elapsed vtime to go negative.
> */
> -delta = jiffies_to_nsecs(now - tsk->vtime_snap);
> other = account_other_time(delta);
> WARN_ON_ONCE(tsk->vtime_snap_whence == VTIME_INACTIVE);
> -tsk->vtime_snap = now;
> +tsk->vtime_snap += delta;
>
> return delta - other;
> }
>
> static void __vtime_account_system(struct task_struct *tsk)
> {
> -account_system_time(tsk, irq_count(), get_vtime_delta(tsk));
> +account_system_time(tsk, irq_count(), tsk->vtime_acct_stime);
> }
>
> void vtime_account_system(struct task_struct *tsk)
> @@ -715,7 +715,11 @@ void vtime_account_system(struct task_struct *tsk)
> return;
>
> w
Re: [PATCH 2/3] PCI: dwc: kirin: add PCIe Driver for HiSilicon Kirin SoC
On 05/15/2017 08:27 AM, Song Xiaowei wrote:
> Hisilicon PCIe Driver shares the common functions fo PCIe dw-host
>
> The poweron functions is developed on hi3660 SoC, while Others Functions
> are common for Kirin series SoCs.
>
> Lowpower(L1ss and SR), hotplug and MSI feature are not supported
> currently.
>
> Cc: Guodong Xu
> Signed-off-by: Song Xiaowei
> ---
> drivers/pci/dwc/Kconfig | 10 +
> drivers/pci/dwc/Makefile | 1 +
> drivers/pci/dwc/pcie-kirin.c | 521
> +++
> 3 files changed, 532 insertions(+)
> create mode 100644 drivers/pci/dwc/pcie-kirin.c
>
> diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
> index d2d2ba5b8a68..13e617b78430 100644
> --- a/drivers/pci/dwc/Kconfig
> +++ b/drivers/pci/dwc/Kconfig
> @@ -130,4 +130,14 @@ config PCIE_ARTPEC6
> Say Y here to enable PCIe controller support on Axis ARTPEC-6
> SoCs. This PCIe controller uses the DesignWare core.
>
> +config PCIE_KIRIN
> + depends on OF && ARM64
> + bool "HiSilicon Kirin series SoCs PCIe controllers"
> + depends on PCI
> + select PCIEPORTBUS
> + select PCIE_DW_HOST
> + help
> + Say Y here if you want PCIe controller support on HiSilicon Kirin
> series SoCs
> + kirin960 SoC
> +
> endmenu
> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
> index a2df13c28798..4bd69bacd4ab 100644
> --- a/drivers/pci/dwc/Makefile
> +++ b/drivers/pci/dwc/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
> obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
> obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
> obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
> +obj-$(CONFIG_PCIE_KIRIN) += pcie-kirin.o
>
> # The following drivers are for devices that use the generic ACPI
> # pci_root.c driver but don't support standard ECAM config access.
> diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
> new file mode 100644
> index ..a19d1732ad9f
> --- /dev/null
> +++ b/drivers/pci/dwc/pcie-kirin.c
> @@ -0,0 +1,521 @@
> +/*
> + * PCIe host controller driver for Kirin Phone SoCs
> + *
> + * Copyright (C) 2015 Hilisicon Electronics Co., Ltd.
> + * http://www.huawei.com
> + *
> + * Author: Xiaowei Song
> + *
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "pcie-designware.h"
> +
> +#define to_kirin_pcie(x) dev_get_drvdata((x)->dev)
> +
> +#define REF_CLK_FREQ 1
> +
> +/* PCIe ELBI registers */
> +#define SOC_PCIECTRL_CTRL0_ADDR 0x000
> +#define SOC_PCIECTRL_CTRL1_ADDR 0x004
> +#define SOC_PCIEPHY_CTRL2_ADDR 0x008
> +#define SOC_PCIEPHY_CTRL3_ADDR 0x00c
> +#define PCIE_ELBI_SLV_DBI_ENABLE (0x1 << 21)
> +
> +#define PCIE_APP_LTSSM_ENABLE0x01c
> +#define PCIE_APB_PHY_CTRL0 0x0
> +#define PCIE_APB_PHY_CTRL1 0x4
> +#define PCIE_APB_PHY_STATUS0 0x400
> +#define PCIE_LINKUP_ENABLE (0x8020)
> +#define PCIE_LTSSM_ENABLE_BIT (0x1 << 11)
> +#define PIPE_CLK_STABLE (0x1 << 19)
> +#define PIPE_CLK_MAX_TRY_TIMES 10
> +#define PHY_REF_PAD_BIT (0x1 << 8)
> +#define PHY_PWR_DOWN_BIT (0x1 << 22)
> +#define PHY_RST_ACK_BIT (0x1 << 16)
> +
> +/* info lacated in sysctrl */
> +#define SCTRL_PCIE_CMOS_OFFSET 0x60
> +#define SCTRL_PCIE_CMOS_BIT 0x10
> +#define SCTRL_PCIE_ISO_OFFSET0x44
> +#define SCTRL_PCIE_ISO_BIT 0x30
> +#define SCTRL_PCIE_HPCLK_OFFSET 0x190
> +#define SCTRL_PCIE_HPCLK_BIT 0x184000
> +#define SCTRL_PCIE_OE_OFFSET 0x14a
> +#define PCIE_DEBOUNCE_PARAM 0xF0F400
> +#define PCIE_OE_BYPASS (0x3 << 28)
> +
> +/*peri_crg ctrl*/
> +#define CRGCTRL_PCIE_ASSERT_OFFSET 0x88
> +#define CRGCTRL_PCIE_ASSERT_BIT 0x8c00
> +
> +/* Time for delay*/
> +#define REF_2_PERST_MIN (2)
> +#define REF_2_PERST_MAX (25000)
> +#define PERST_2_ACCESS_MIN (1)
> +#define PERST_2_ACCESS_MAX (12000)
> +#define LINK_WAIT_MIN(900)
> +#define LINK_WAIT_MAX(1000)
> +
> +struct kirin_pcie {
> + void __iomem*apb_base;
> + void __iomem*phy_base;
> + struct regmap *crgctrl;
> + struct regmap *sysctrl;
> + struct clk *apb_sys_clk;
> + struct clk *apb_phy_clk;
> + struct clk *phy_ref_clk;
> + struct clk *pcie_aclk;
> + struct clk *pcie_aux_clk;
> + int gpi
Re: [PATCH v2 15/18] arm64: dts: meson-gxl: Fix node order
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2:
> * Rebased (new nodes added)
>
> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 72
> +++---
> 1 file changed, 36 insertions(+), 36 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> index d8e096dff10a..3efad5f0bca4 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> @@ -193,6 +193,42 @@
> };
> };
>
> +&hdmi_tx {
> + compatible = "amlogic,meson-gxl-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
> + resets = <&reset RESET_HDMITX_CAPB3>,
> + <&reset RESET_HDMI_SYSTEM_RESET>,
> + <&reset RESET_HDMI_TX>;
> + reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
> + clocks = <&clkc CLKID_HDMI_PCLK>,
> + <&clkc CLKID_CLK81>,
> + <&clkc CLKID_GCLK_VENCI_INT0>;
> + clock-names = "isfr", "iahb", "venci";
> +};
> +
> +&hiubus {
> + clkc: clock-controller@0 {
> + compatible = "amlogic,gxl-clkc", "amlogic,gxbb-clkc";
> + #clock-cells = <1>;
> + reg = <0x0 0x0 0x0 0x3db>;
> + };
> +};
> +
> +&i2c_A {
> + clocks = <&clkc CLKID_I2C>;
> +};
> +
> +&i2c_AO {
> + clocks = <&clkc CLKID_AO_I2C>;
> +};
> +
> +&i2c_B {
> + clocks = <&clkc CLKID_I2C>;
> +};
> +
> +&i2c_C {
> + clocks = <&clkc CLKID_I2C>;
> +};
> +
> &periphs {
> pinctrl_periphs: pinctrl@4b0 {
> compatible = "amlogic,meson-gxl-periphs-pinctrl";
> @@ -501,30 +537,6 @@
> };
> };
>
> -&hiubus {
> - clkc: clock-controller@0 {
> - compatible = "amlogic,gxl-clkc", "amlogic,gxbb-clkc";
> - #clock-cells = <1>;
> - reg = <0x0 0x0 0x0 0x3db>;
> - };
> -};
> -
> -&i2c_A {
> - clocks = <&clkc CLKID_I2C>;
> -};
> -
> -&i2c_AO {
> - clocks = <&clkc CLKID_AO_I2C>;
> -};
> -
> -&i2c_B {
> - clocks = <&clkc CLKID_I2C>;
> -};
> -
> -&i2c_C {
> - clocks = <&clkc CLKID_I2C>;
> -};
> -
> &saradc {
> compatible = "amlogic,meson-gxl-saradc", "amlogic,meson-saradc";
> clocks = <&xtal>,
> @@ -563,15 +575,3 @@
> &vpu {
> compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
> };
> -
> -&hdmi_tx {
> - compatible = "amlogic,meson-gxl-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
> - resets = <&reset RESET_HDMITX_CAPB3>,
> - <&reset RESET_HDMI_SYSTEM_RESET>,
> - <&reset RESET_HDMI_TX>;
> - reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
> - clocks = <&clkc CLKID_HDMI_PCLK>,
> - <&clkc CLKID_CLK81>,
> - <&clkc CLKID_GCLK_VENCI_INT0>;
> - clock-names = "isfr", "iahb", "venci";
> -};
>
Hi Andreas,
Like a previous attempt, I'm not OK with such rework since it will break bisect
and add complexity for new patches handling.
The order is not alphabetically ordered, live with it.
Neil
Re: [PATCH v2 18/18] arm64: dts: meson-gx-p23x-q20x: Fix node order
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2:
> * Rebased (new nodes added)
>
> .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 58
> +++---
> 1 file changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> index 25eed18a7439..dc478d094c11 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> @@ -121,19 +121,42 @@
> };
> };
>
> -/* This UART is brought out to the DB9 connector */
> -&uart_AO {
> +&cvbs_vdac_port {
> + cvbs_vdac_out: endpoint {
> + remote-endpoint = <&cvbs_connector_in>;
> + };
> +};
> +
> +ðmac {
> status = "okay";
> - pinctrl-0 = <&uart_ao_a_pins>;
> +};
> +
> +&hdmi_tx {
> + status = "okay";
> + pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> pinctrl-names = "default";
> };
>
> +&hdmi_tx_tmds_port {
> + hdmi_tx_tmds_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> +};
> +
> &ir {
> status = "okay";
> pinctrl-0 = <&remote_input_ao_pins>;
> pinctrl-names = "default";
> };
>
> +&pwm_ef {
> + status = "okay";
> + pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-names = "default";
> + clocks = <&clkc CLKID_FCLK_DIV4>;
> + clock-names = "clkin0";
> +};
> +
> /* Wireless SDIO Module */
> &sd_emmc_a {
> status = "okay";
> @@ -198,32 +221,9 @@
> vqmmc-supply = <&vddio_boot>;
> };
>
> -&pwm_ef {
> - status = "okay";
> - pinctrl-0 = <&pwm_e_pins>;
> - pinctrl-names = "default";
> - clocks = <&clkc CLKID_FCLK_DIV4>;
> - clock-names = "clkin0";
> -};
> -
> -ðmac {
> - status = "okay";
> -};
> -
> -&cvbs_vdac_port {
> - cvbs_vdac_out: endpoint {
> - remote-endpoint = <&cvbs_connector_in>;
> - };
> -};
> -
> -&hdmi_tx {
> +/* This UART is brought out to the DB9 connector */
> +&uart_AO {
> status = "okay";
> - pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> + pinctrl-0 = <&uart_ao_a_pins>;
> pinctrl-names = "default";
> };
> -
> -&hdmi_tx_tmds_port {
> - hdmi_tx_tmds_out: endpoint {
> - remote-endpoint = <&hdmi_connector_in>;
> - };
> -};
>
Hi Andreas,
Like a previous attempt, I'm not OK with such rework since it will break bisect
and add complexity for new patches handling.
The order is not alphabetically ordered, live with it.
Neil
Re: [PATCH v2 00/18] ARM64: meson: DT cleanups
Hi Andreas, On 05/13/2017 04:33 PM, Andreas Färber wrote: > Hello Kevin, > > This series fixes several cosmetic issues, on top of your for-next branch. > > Patches 3-6 rename a node, the rest should all be non-functional changes. These are OK. > > PLEASE STOP merging random new nodes at the bottom of DT files! > Just like it's a convention to sort new nodes by unit address, it has been > a convention to sort by-label nodes by their label. As discussed here and > elsewhere, this helps avoid merge conflicts and makes nodes easy to find. > I don't care whether we order A0 before A or after, but adding new HDMI > or CVBS nodes at the very bottom is totally out of alphabetical order. > Since my v1 you really should've known that... It's not perfect, but now it's done, live with it, this has already been discussed. Please try to refactor boards DTS with their parent reference design instead like it was done with the P212 and what I did with the Wetek Hub and Play2. > > Similarly, Khadas Vim shouldn't have been merged with the "bcrmf" typo. Well, this is why we have 7 rc releases after the merge window... > > Which proves my point that we need to fix these issues now so that they > don't keep spreading (Broken Window Theory). New boards have not been > checked for sort order, only boards already touched in v1. > > Board and Makefile order affect my pending R-Box Pro patches. > Node order affects Martin's pending Bluetooth patches among others. Please order S905x after S905d, and we'll be OK. > > Patches 7-9 (had and) have no dependency, please start applying. I'll wait for Kevin's advice, but I'm against these since they are only purely cosmetic and will break bisect and add unnecessary complexity to handle further patches on these board. > Thanks, > Andreas Thanks, Neil > > v1 -> v2: > * Rebased (new nodes/properties added) > * Chose a different name for the misnamed Wifi nodes (Rob) > * Added patch to fix another new misnamed Wifi node > * Dropped patch fixing a trailing white line error (resolved) > * Tweaked subjects > > Cc: Kevin Hilman > Cc: devicet...@vger.kernel.org > Cc: Rob Herring > Cc: Neil Armstrong > Cc: Martin Blumenstingl > > Andreas Färber (18): > dt-bindings: arm: amlogic: Reorder boards > arm64: dts: amlogic: Sort Makefile > arm64: dts: meson-gxbb-vega-s95: Fix Wifi node name > arm64: dts: meson-gxbb-p20x: Fix Wifi node name > arm64: dts: meson-gx-p23x-q20x: Fix Wifi node name > arm64: dts: meson-gxl-s905x-khadas-vim: Fix Wifi node name > arm64: dts: meson-gxm-nexbox-a1: Drop UART comment > arm64: dts: meson-gxl-s905x: Comment typo fix > arm64: dts: meson-gxbb-wetek-hub: Reference CVBS node by label > arm64: dts: meson-gxbb: Fix node order > arm64: dts: meson-gxbb-odroidc2: Fix node order > arm64: dts: meson-gxbb-vega-s95: Fix node order > arm64: dts: meson-gxbb-nexbox-a95x: Fix node order > arm64: dts: meson-gxbb-p20x: Fix node order > arm64: dts: meson-gxl: Fix node order > arm64: dts: meson-gxl-s905x-nexbox-a95x: Fix node order > arm64: dts: meson-gxm-nexbox-a1: Fix node order > arm64: dts: meson-gx-p23x-q20x: Fix node order > > Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++- > arch/arm64/boot/dts/amlogic/Makefile | 6 +- > .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 60 > .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts| 52 +++ > .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 108 ++--- > arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 66 > .../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 56 +++ > .../boot/dts/amlogic/meson-gxbb-wetek-hub.dts | 6 +- > arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi| 171 > +++-- > .../dts/amlogic/meson-gxl-s905x-khadas-vim.dts | 2 +- > .../dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts| 52 +++ > arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi | 2 +- > arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 72 - > .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 87 ++- > 14 files changed, 388 insertions(+), 372 deletions(-) >
Re: [PATCH v2 14/18] arm64: dts: meson-gxbb-p20x: Fix node order
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2:
> * Rebased (new nodes added)
>
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 62
>
> 1 file changed, 31 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> index 0ec1d19522dd..d904deb1018c 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -148,34 +148,36 @@
> };
> };
>
> -/* This UART is brought out to the DB9 connector */
> -&uart_AO {
> - status = "okay";
> - pinctrl-0 = <&uart_ao_a_pins>;
> - pinctrl-names = "default";
> +&cvbs_vdac_port {
> + cvbs_vdac_out: endpoint {
> + remote-endpoint = <&cvbs_connector_in>;
> + };
> };
>
> -&ir {
> +&hdmi_tx {
> status = "okay";
> - pinctrl-0 = <&remote_input_ao_pins>;
> + pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> pinctrl-names = "default";
> };
>
> -&usb0_phy {
> - status = "okay";
> - phy-supply = <&usb_pwr>;
> -};
> -
> -&usb1_phy {
> - status = "okay";
> +&hdmi_tx_tmds_port {
> + hdmi_tx_tmds_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> };
>
> -&usb0 {
> +&ir {
> status = "okay";
> + pinctrl-0 = <&remote_input_ao_pins>;
> + pinctrl-names = "default";
> };
>
> -&usb1 {
> +&pwm_ef {
> status = "okay";
> + pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-names = "default";
> + clocks = <&clkc CLKID_FCLK_DIV4>;
> + clock-names = "clkin0";
> };
>
> /* Wireless SDIO Module */
> @@ -242,28 +244,26 @@
> vqmmc-supply = <&vddio_boot>;
> };
>
> -&pwm_ef {
> +/* This UART is brought out to the DB9 connector */
> +&uart_AO {
> status = "okay";
> - pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-0 = <&uart_ao_a_pins>;
> pinctrl-names = "default";
> - clocks = <&clkc CLKID_FCLK_DIV4>;
> - clock-names = "clkin0";
> };
>
> -&cvbs_vdac_port {
> - cvbs_vdac_out: endpoint {
> - remote-endpoint = <&cvbs_connector_in>;
> - };
> +&usb0_phy {
> + status = "okay";
> + phy-supply = <&usb_pwr>;
> };
>
> -&hdmi_tx {
> +&usb1_phy {
> status = "okay";
> - pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> - pinctrl-names = "default";
> };
>
> -&hdmi_tx_tmds_port {
> - hdmi_tx_tmds_out: endpoint {
> - remote-endpoint = <&hdmi_connector_in>;
> - };
> +&usb0 {
> + status = "okay";
> +};
> +
> +&usb1 {
> + status = "okay";
> };
>
Hi Andreas,
Like a previous attempt, I'm not OK with such rework since it will break bisect
and add complexity for new patches handling.
The order is not alphabetically ordered, live with it.
Neil
Re: [PATCH v2 17/18] arm64: dts: meson-gxm-nexbox-a1: Fix node order
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2:
> * Rebased (new nodes added)
>
> .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 86
> +++---
> 1 file changed, 43 insertions(+), 43 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> index 920fac10de93..5f626d683088 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -113,10 +113,49 @@
> };
> };
>
> -&uart_AO {
> +&cvbs_vdac_port {
> + cvbs_vdac_out: endpoint {
> + remote-endpoint = <&cvbs_connector_in>;
> + };
> +};
> +
> +ðmac {
> status = "okay";
> - pinctrl-0 = <&uart_ao_a_pins>;
> +
> + pinctrl-0 = <ð_pins>;
> pinctrl-names = "default";
> +
> + /* Select external PHY by default */
> + phy-handle = <&external_phy>;
> +
> + amlogic,tx-delay-ns = <2>;
> +
> + snps,reset-gpio = <&gpio GPIOZ_14 0>;
> + snps,reset-delays-us = <0 1 100>;
> + snps,reset-active-low;
> +
> + /* External PHY is in RGMII */
> + phy-mode = "rgmii";
> +};
> +
> +&external_mdio {
> + external_phy: ethernet-phy@0 {
> + compatible = "ethernet-phy-id001c.c916",
> "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + max-speed = <1000>;
> + };
> +};
> +
> +&hdmi_tx {
> + status = "okay";
> + pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> + pinctrl-names = "default";
> +};
> +
> +&hdmi_tx_tmds_port {
> + hdmi_tx_tmds_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> };
>
> &ir {
> @@ -163,47 +202,8 @@
> vqmmc-supply = <&vddio_boot>;
> };
>
> -ðmac {
> - status = "okay";
> -
> - pinctrl-0 = <ð_pins>;
> - pinctrl-names = "default";
> -
> - /* Select external PHY by default */
> - phy-handle = <&external_phy>;
> -
> - amlogic,tx-delay-ns = <2>;
> -
> - snps,reset-gpio = <&gpio GPIOZ_14 0>;
> - snps,reset-delays-us = <0 1 100>;
> - snps,reset-active-low;
> -
> - /* External PHY is in RGMII */
> - phy-mode = "rgmii";
> -};
> -
> -&external_mdio {
> - external_phy: ethernet-phy@0 {
> - compatible = "ethernet-phy-id001c.c916",
> "ethernet-phy-ieee802.3-c22";
> - reg = <0>;
> - max-speed = <1000>;
> - };
> -};
> -
> -&cvbs_vdac_port {
> - cvbs_vdac_out: endpoint {
> - remote-endpoint = <&cvbs_connector_in>;
> - };
> -};
> -
> -&hdmi_tx {
> +&uart_AO {
> status = "okay";
> - pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> + pinctrl-0 = <&uart_ao_a_pins>;
> pinctrl-names = "default";
> };
> -
> -&hdmi_tx_tmds_port {
> - hdmi_tx_tmds_out: endpoint {
> - remote-endpoint = <&hdmi_connector_in>;
> - };
> -};
>
Hi Andreas,
Like a previous attempt, I'm not OK with such rework since it will break bisect
and add complexity for new patches handling.
The order is not alphabetically ordered, live with it.
Neil
Re: [PATCH v2 16/18] arm64: dts: meson-gxl-s905x-nexbox-a95x: Fix node order
On 05/13/2017 04:33 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber
> ---
> v1 -> v2:
> * Rebased (new nodes added)
>
> .../dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts| 52
> +++---
> 1 file changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
> index 8873c058fad2..6633a5d8fdd3 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
> @@ -140,10 +140,10 @@
> };
> };
>
> -&uart_AO {
> - status = "okay";
> - pinctrl-0 = <&uart_ao_a_pins>;
> - pinctrl-names = "default";
> +&cvbs_vdac_port {
> + cvbs_vdac_out: endpoint {
> + remote-endpoint = <&cvbs_connector_in>;
> + };
> };
>
> ðmac {
> @@ -152,12 +152,32 @@
> phy-handle = <&internal_phy>;
> };
>
> +&hdmi_tx {
> + status = "okay";
> + pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> + pinctrl-names = "default";
> +};
> +
> +&hdmi_tx_tmds_port {
> + hdmi_tx_tmds_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> +};
> +
> &ir {
> status = "okay";
> pinctrl-0 = <&remote_input_ao_pins>;
> pinctrl-names = "default";
> };
>
> +&pwm_ef {
> + status = "okay";
> + pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-names = "default";
> + clocks = <&clkc CLKID_FCLK_DIV4>;
> + clock-names = "clkin0";
> +};
> +
> /* Wireless SDIO Module */
> &sd_emmc_a {
> status = "okay";
> @@ -217,28 +237,8 @@
> vqmmc-supply = <&vddio_boot>;
> };
>
> -&pwm_ef {
> - status = "okay";
> - pinctrl-0 = <&pwm_e_pins>;
> - pinctrl-names = "default";
> - clocks = <&clkc CLKID_FCLK_DIV4>;
> - clock-names = "clkin0";
> -};
> -
> -&cvbs_vdac_port {
> - cvbs_vdac_out: endpoint {
> - remote-endpoint = <&cvbs_connector_in>;
> - };
> -};
> -
> -&hdmi_tx {
> +&uart_AO {
> status = "okay";
> - pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> + pinctrl-0 = <&uart_ao_a_pins>;
> pinctrl-names = "default";
> };
> -
> -&hdmi_tx_tmds_port {
> - hdmi_tx_tmds_out: endpoint {
> - remote-endpoint = <&hdmi_connector_in>;
> - };
> -};
>
Hi Andreas,
Like a previous attempt, I'm not OK with such rework since it will break bisect
and add complexity for new patches handling.
The order is not alphabetically ordered, live with it.
Neil
Re: [PATCH v4 0/2] Tango PCIe controller support
On 20/04/2017 16:24, Marc Gonzalez wrote:
> This patch was split in two, to ease review of two orthogonal
> parts (MSI controller and host bridge). NB: the patch is
> just split in two where host bridge support starts.
>
> Changes from v3 to v4
>
> In the MSI part:
> - Support 256 MSIs instead of only 32
> - Define tango_{ack,mask,unmask} callbacks for the HW irq_chip
> - Use a spinlock instead of a mutex
> - Rename msi_mask register to msi_enable
>
> In the host bridge part:
> - Move several quirk-handling snippets out of the config space read function
> - Check whether the PCIe link is up at probe-time
>
> Other files
> - Let the framework compute the bus-range from the config space width
> - Be slightly more verbose in the Kconfig help
>
>
> What has *not* changed, waiting from feedback from Bjorn:
>
> - Pray that config and mem space accesses NEVER occur concurrently.
> - Using of_device_is_compatible() vs of_device_get_match_data()
>
>
> Marc Gonzalez (2):
> PCI: Add tango MSI controller support
> PCI: Add tango PCIe host bridge support
>
> Documentation/devicetree/bindings/pci/tango-pcie.txt | 32
> drivers/pci/host/Kconfig | 8 +
> drivers/pci/host/Makefile| 1 +
> drivers/pci/host/pcie-tango.c| 393
> +++
> include/linux/pci_ids.h | 2 +
> 5 files changed, 436 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/tango-pcie.txt
> create mode 100644 drivers/pci/host/pcie-tango.c
Now that Linus has closed the merge window for v4.12, I hope that this
driver can be accepted in v4.13 ?
Regards.
[PATCH v1] mfd: intel-lpss: Add Intel Cannonlake PCI IDs
Intel Cannonlake PCH has the same LPSS than Intel Kabylake. Add the new IDs
to the list of supported devices.
Signed-off-by: Mika Westerberg
Signed-off-by: Andy Shevchenko
---
drivers/mfd/intel-lpss-pci.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
index 16ffeaeb1385..ad388bb056cd 100644
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -201,6 +201,19 @@ static const struct pci_device_id intel_lpss_pci_ids[] = {
{ PCI_VDEVICE(INTEL, 0x9d64), (kernel_ulong_t)&spt_i2c_info },
{ PCI_VDEVICE(INTEL, 0x9d65), (kernel_ulong_t)&spt_i2c_info },
{ PCI_VDEVICE(INTEL, 0x9d66), (kernel_ulong_t)&spt_uart_info },
+ /* CNL-LP */
+ { PCI_VDEVICE(INTEL, 0x9da8), (kernel_ulong_t)&spt_uart_info },
+ { PCI_VDEVICE(INTEL, 0x9da9), (kernel_ulong_t)&spt_uart_info },
+ { PCI_VDEVICE(INTEL, 0x9daa), (kernel_ulong_t)&spt_info },
+ { PCI_VDEVICE(INTEL, 0x9dab), (kernel_ulong_t)&spt_info },
+ { PCI_VDEVICE(INTEL, 0x9dfb), (kernel_ulong_t)&spt_info },
+ { PCI_VDEVICE(INTEL, 0x9dc5), (kernel_ulong_t)&spt_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9dc6), (kernel_ulong_t)&spt_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9dc7), (kernel_ulong_t)&spt_uart_info },
+ { PCI_VDEVICE(INTEL, 0x9de8), (kernel_ulong_t)&spt_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9de9), (kernel_ulong_t)&spt_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9dea), (kernel_ulong_t)&spt_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9deb), (kernel_ulong_t)&spt_i2c_info },
/* SPT-H */
{ PCI_VDEVICE(INTEL, 0xa127), (kernel_ulong_t)&spt_uart_info },
{ PCI_VDEVICE(INTEL, 0xa128), (kernel_ulong_t)&spt_uart_info },
@@ -219,6 +232,17 @@ static const struct pci_device_id intel_lpss_pci_ids[] = {
{ PCI_VDEVICE(INTEL, 0xa2e2), (kernel_ulong_t)&spt_i2c_info },
{ PCI_VDEVICE(INTEL, 0xa2e3), (kernel_ulong_t)&spt_i2c_info },
{ PCI_VDEVICE(INTEL, 0xa2e6), (kernel_ulong_t)&spt_uart_info },
+ /* CNL-H */
+ { PCI_VDEVICE(INTEL, 0xa328), (kernel_ulong_t)&spt_uart_info },
+ { PCI_VDEVICE(INTEL, 0xa329), (kernel_ulong_t)&spt_uart_info },
+ { PCI_VDEVICE(INTEL, 0xa32a), (kernel_ulong_t)&spt_info },
+ { PCI_VDEVICE(INTEL, 0xa32b), (kernel_ulong_t)&spt_info },
+ { PCI_VDEVICE(INTEL, 0xa37b), (kernel_ulong_t)&spt_info },
+ { PCI_VDEVICE(INTEL, 0xa347), (kernel_ulong_t)&spt_uart_info },
+ { PCI_VDEVICE(INTEL, 0xa368), (kernel_ulong_t)&spt_i2c_info },
+ { PCI_VDEVICE(INTEL, 0xa369), (kernel_ulong_t)&spt_i2c_info },
+ { PCI_VDEVICE(INTEL, 0xa36a), (kernel_ulong_t)&spt_i2c_info },
+ { PCI_VDEVICE(INTEL, 0xa36b), (kernel_ulong_t)&spt_i2c_info },
{ }
};
MODULE_DEVICE_TABLE(pci, intel_lpss_pci_ids);
--
2.11.0
[PATCH v1] hw_random : omap3-rom-rng:- Handle return value of clk_prepare_enable
Here, Clock enable can failed. So adding an error check for
clk_prepare_enable.
Signed-off-by: Arvind Yadav
---
drivers/char/hw_random/omap3-rom-rng.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/omap3-rom-rng.c
b/drivers/char/hw_random/omap3-rom-rng.c
index 37a58d7..38b7190 100644
--- a/drivers/char/hw_random/omap3-rom-rng.c
+++ b/drivers/char/hw_random/omap3-rom-rng.c
@@ -53,7 +53,10 @@ static int omap3_rom_rng_get_random(void *buf, unsigned int
count)
cancel_delayed_work_sync(&idle_work);
if (rng_idle) {
- clk_prepare_enable(rng_clk);
+ r = clk_prepare_enable(rng_clk);
+ if (r)
+ return r;
+
r = omap3_rom_rng_call(0, 0, RNG_GEN_PRNG_HW_INIT);
if (r != 0) {
clk_disable_unprepare(rng_clk);
@@ -88,6 +91,8 @@ static int omap3_rom_rng_read(struct hwrng *rng, void *data,
size_t max, bool w)
static int omap3_rom_rng_probe(struct platform_device *pdev)
{
+ int ret = 0;
+
pr_info("initializing\n");
omap3_rom_rng_call = pdev->dev.platform_data;
@@ -104,7 +109,9 @@ static int omap3_rom_rng_probe(struct platform_device *pdev)
}
/* Leave the RNG in reset state. */
- clk_prepare_enable(rng_clk);
+ ret = clk_prepare_enable(rng_clk);
+ if (ret)
+ return ret;
omap3_rom_rng_idle(0);
return hwrng_register(&omap3_rom_rng_ops);
--
1.9.1
Re: [PATCH v3 2/6] drm: Add drm_{crtc/encoder/connector}_mode_valid()
On 11.05.2017 11:05, Jose Abreu wrote:
> Add a new helper to call crtc->mode_valid, connector->mode_valid
> and encoder->mode_valid callbacks.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: Alexey Brodkin
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Andrzej Hajda
> Cc: Archit Taneja
> ---
> Changes v2->v3:
> - Move helpers to drm_probe_helper.c (Daniel)
> - Squeeze patches that introduce the helpers into a single
> one (Daniel)
>
> drivers/gpu/drm/drm_crtc_helper_internal.h | 13 ++
> drivers/gpu/drm/drm_probe_helper.c | 38
> ++
> 2 files changed, 51 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h
> b/drivers/gpu/drm/drm_crtc_helper_internal.h
> index 28295e5..97dfe20 100644
> --- a/drivers/gpu/drm/drm_crtc_helper_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_helper_internal.h
> @@ -26,7 +26,11 @@
> * implementation details and are not exported to drivers.
> */
>
> +#include
> +#include
> #include
> +#include
> +#include
>
> /* drm_fb_helper.c */
> #ifdef CONFIG_DRM_FBDEV_EMULATION
> @@ -62,4 +66,13 @@ static inline int drm_dp_aux_register_devnode(struct
> drm_dp_aux *aux)
> static inline void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux)
> {
> }
> +
> +/* drm_probe_helper.c */
> +enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
> + const struct drm_display_mode *mode);
> +enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
> + const struct drm_display_mode
> *mode);
> +enum drm_mode_status drm_connector_mode_valid(struct drm_connector
> *connector,
> + struct drm_display_mode *mode);
> +
> #endif
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 1b0c14a..f01abdc 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -38,6 +38,9 @@
> #include
> #include
> #include
> +#include
> +
> +#include "drm_crtc_helper_internal.h"
>
> /**
> * DOC: output probing helper overview
> @@ -113,6 +116,41 @@ static int drm_helper_probe_add_cmdline_mode(struct
> drm_connector *connector)
> return 1;
> }
>
> +enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
> + const struct drm_display_mode *mode)
> +{
> + const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
> +
> + if (!crtc_funcs || !crtc_funcs->mode_valid)
> + return MODE_OK;
> +
> + return crtc_funcs->mode_valid(crtc, mode);
> +}
> +
> +enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
> + const struct drm_display_mode *mode)
> +{
> + const struct drm_encoder_helper_funcs *encoder_funcs =
> + encoder->helper_private;
> +
> + if (!encoder_funcs || !encoder_funcs->mode_valid)
> + return MODE_OK;
> +
> + return encoder_funcs->mode_valid(encoder, mode);
> +}
> +
> +enum drm_mode_status drm_connector_mode_valid(struct drm_connector
> *connector,
> + struct drm_display_mode *mode)
> +{
> + const struct drm_connector_helper_funcs *connector_funcs =
> + connector->helper_private;
> +
> + if (!connector_funcs || !connector_funcs->mode_valid)
> + return MODE_OK;
> +
> + return connector_funcs->mode_valid(connector, mode);
> +}
> +
"Copy/Paste" as the main generic programming technique in C :)
I guess clever/scary macro wouldn't be an option.
Anyway:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
> /**
> * drm_kms_helper_poll_enable - re-enable output polling.
Re: [PATCH] mm/kasan: use kasan_zero_pud for p4d table
On 05/15/2017 09:20 AM, js1...@gmail.com wrote:
> From: Joonsoo Kim
>
> There is missing optimization in zero_p4d_populate() that can save
> some memory when mapping zero shadow. Implement it like as others.
>
> Signed-off-by: Joonsoo Kim
Acked-by: Andrey Ryabinin
> ---
> mm/kasan/kasan_init.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/mm/kasan/kasan_init.c b/mm/kasan/kasan_init.c
> index b96a5f7..554e4c0 100644
> --- a/mm/kasan/kasan_init.c
> +++ b/mm/kasan/kasan_init.c
> @@ -118,6 +118,18 @@ static void __init zero_p4d_populate(pgd_t *pgd,
> unsigned long addr,
>
> do {
> next = p4d_addr_end(addr, end);
> + if (IS_ALIGNED(addr, P4D_SIZE) && end - addr >= P4D_SIZE) {
> + pud_t *pud;
> + pmd_t *pmd;
> +
> + p4d_populate(&init_mm, p4d, lm_alias(kasan_zero_pud));
> + pud = pud_offset(p4d, addr);
> + pud_populate(&init_mm, pud, lm_alias(kasan_zero_pmd));
> + pmd = pmd_offset(pud, addr);
> + pmd_populate_kernel(&init_mm, pmd,
> + lm_alias(kasan_zero_pte));
> + continue;
> + }
>
> if (p4d_none(*p4d)) {
> p4d_populate(&init_mm, p4d,
>
[PATCH v4] DTS: ARM: OMAP5: uevm: add µSD card detect
If we have Linux installed in eMMC we can boot without
µSD card, but inserting one is not recognised.
The reason is that the card detect gpio (gpio5_152)
is not configured and attached to the mmc1 interface
driver and the mmc driver does not poll by default.
Hence we add pinmux and gpio setup for the SDCARD_NCD
signal.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap5-uevm.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index d58b034513da..1a6e28c3d847 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -142,6 +142,13 @@
};
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+
+ cd-gpios = <&gpio5 24 GPIO_ACTIVE_LOW>; /* gpio5_152 */
+};
+
&omap5_pmx_core {
evm_keys_pins: pinmux_evm_keys_gpio_pins {
pinctrl-single,pins = <
@@ -161,6 +168,12 @@
OMAP5_IOPAD(0x0a8, PIN_INPUT_PULLUP | MUX_MODE6)
/* gpio3_76 */
>;
};
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins = <
+ OMAP5_IOPAD(0x1d4, PIN_INPUT_PULLUP | MUX_MODE6)
/* gpio5_152 */
+ >;
+ };
};
&tpd12s015 {
--
2.12.2
Re: [PATCH 1/9] staging: sm750fb: fix length of lines
On Sun, May 14, 2017 at 12:42:34AM +0200, Matej Dujava wrote: > This patch breaks lines that are longer than 80 characters and joins > together those, that are too short and can be placed at one. > The patch basically doesn't match the changelog. regards, dan carpenter
[RFC] NVMe Configuraiton using sysctl
Hi, we are configuring interrupt coalesce for NVMe, but right now, it uses module param. so the same interrupt coalesce settings get applied for all the NVMEs connected to different RCs. ideally it should be with sysctl. for e.g. sysctl should provide interface to change Per-CPU IO queue pairs, interrupt coalesce settings etc.. please suggest if we could have/implement sysctl module for NVMe ? Regards, Oza.
[PATCH] ASoC: rt5665: Fix uninitialized warning in rt5665_i2s_pin_event()
With gcc 4.1.2:
sound/soc/codecs/rt5665.c: In function ‘rt5665_i2s_pin_event’:
sound/soc/codecs/rt5665.c:2610: warning: ‘mask1’ may be used uninitialized
in this function
sound/soc/codecs/rt5665.c:2610: warning: ‘val2’ may be used uninitialized
in this function
sound/soc/codecs/rt5665.c:2610: warning: ‘val1’ may be used uninitialized
in this function
The first one is currently a false positive, as rt5665_i2s_pin_event()
is never called with snd_soc_dapm_widget.shift set to a value not
handled by the switch() statement. But that may change, so
preinitialize mask1 to fix this, like is already done for mask2.
The last two are false-positives, the compiler is just not smart enough
to notice the mask and val variables are always used together.
Fixes: 9b5d3865b3b410d2 ("ASoC: rt5665: set i2s pin share configuration")
Signed-off-by: Geert Uytterhoeven
---
sound/soc/codecs/rt5665.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/rt5665.c b/sound/soc/codecs/rt5665.c
index 8cd22307f5b6e6ab..5e42f4ee51ba5b20 100644
--- a/sound/soc/codecs/rt5665.c
+++ b/sound/soc/codecs/rt5665.c
@@ -2607,7 +2607,7 @@ static int rt5665_i2s_pin_event(struct
snd_soc_dapm_widget *w,
struct snd_kcontrol *kcontrol, int event)
{
struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm);
- unsigned int val1, val2, mask1, mask2 = 0;
+ unsigned int val1, val2, mask1 = 0, mask2 = 0;
switch (w->shift) {
case RT5665_PWR_I2S2_1_BIT:
@@ -2635,13 +2635,17 @@ static int rt5665_i2s_pin_event(struct
snd_soc_dapm_widget *w,
}
switch (event) {
case SND_SOC_DAPM_PRE_PMU:
- snd_soc_update_bits(codec, RT5665_GPIO_CTRL_1, mask1, val1);
+ if (mask1)
+ snd_soc_update_bits(codec, RT5665_GPIO_CTRL_1,
+ mask1, val1);
if (mask2)
snd_soc_update_bits(codec, RT5665_GPIO_CTRL_2,
mask2, val2);
break;
case SND_SOC_DAPM_POST_PMD:
- snd_soc_update_bits(codec, RT5665_GPIO_CTRL_1, mask1, 0);
+ if (mask1)
+ snd_soc_update_bits(codec, RT5665_GPIO_CTRL_1,
+ mask1, 0);
if (mask2)
snd_soc_update_bits(codec, RT5665_GPIO_CTRL_2,
mask2, 0);
--
2.7.4
[PATCH] ASoC: atmel-classd: sync regcache when resuming
The PM functions used in this driver are the ones defined in
sounc/soc/soc-core.c.
When suspending (using snd_soc_suspend), the regcache is marked dirty
but is never synced on resume.
Sync regcache on resume of Atmel ClassD device.
Signed-off-by: Quentin Schulz
---
sound/soc/atmel/atmel-classd.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sound/soc/atmel/atmel-classd.c b/sound/soc/atmel/atmel-classd.c
index 7ae46c2647d4..b7ef8c59b49a 100644
--- a/sound/soc/atmel/atmel-classd.c
+++ b/sound/soc/atmel/atmel-classd.c
@@ -301,6 +301,14 @@ static int atmel_classd_codec_probe(struct snd_soc_codec
*codec)
return 0;
}
+static int atmel_classd_codec_resume(struct snd_soc_codec *codec)
+{
+ struct snd_soc_card *card = snd_soc_codec_get_drvdata(codec);
+ struct atmel_classd *dd = snd_soc_card_get_drvdata(card);
+
+ return regcache_sync(dd->regmap);
+}
+
static struct regmap *atmel_classd_codec_get_remap(struct device *dev)
{
return dev_get_regmap(dev, NULL);
@@ -308,6 +316,7 @@ static struct regmap *atmel_classd_codec_get_remap(struct
device *dev)
static struct snd_soc_codec_driver soc_codec_dev_classd = {
.probe = atmel_classd_codec_probe,
+ .resume = atmel_classd_codec_resume,
.get_regmap = atmel_classd_codec_get_remap,
.component_driver = {
.controls = atmel_classd_snd_controls,
--
2.11.0
Re: [PATCH v4 1/5] sched/deadline: Refer to cpudl.elements atomically
Hi, On 12/05/17 10:25, Steven Rostedt wrote: > On Fri, 12 May 2017 14:48:45 +0900 > Byungchul Park wrote: > > > cpudl.elements is an instance that should be protected with a spin lock. > > Without it, the code would be insane. > > And how much contention will this add? Spin locks in the scheduler code > that are shared among a domain can cause huge latency. This was why I > worked hard not to add any in the cpupri code. > > > > > > Current cpudl_find() has problems like, > > > >1. cpudl.elements[0].cpu might not match with cpudl.elements[0].dl. > >2. cpudl.elements[0].dl(u64) might not be referred atomically. > >3. Two cpudl_maximum()s might return different values. > >4. It's just insane. > > And lockless algorithms usually are insane. But locks come with a huge > cost. What happens when we have 32 core domains. This can cause > tremendous contention and makes the entire cpu priority for deadlines > useless. Might as well rip out the code. > Right. So, rationale for not taking any lock in the find() path (at the risk of getting bogus values) is that we don't want to pay to much in terms of contention, when also considering the fact that find_lock_later_ rq() might then release the rq lock, possibly making the search useless (if things change in the meantime anyway). The update path is instead guarded by a lock, to ensure consistency. Experiments on reasonably big machines (48-cores IIRC) showed that the approach was "good enough", so we looked somewhere else to improve things (as there are many to improve :). This of course doesn't prevent us to look at this again now and see if we need to do something about it. Having numbers about introduced overhead and wrong decisions caused by the lockless find() path would help a lot understanding what (and can) be done. Thanks! - Juri
Re: [PATCH 08/10] efi/x86: Move EFI BGRT init code to early init code
Hi, Thanks for the report. On 05/14/17 at 01:18am, Sabrina Dubroca wrote: > 2017-01-31, 13:21:40 +, Ard Biesheuvel wrote: > > From: Dave Young > > > > Before invoking the arch specific handler, efi_mem_reserve() reserves > > the given memory region through memblock. > > > > efi_bgrt_init() will call efi_mem_reserve() after mm_init(), at which > > time memblock is dead and should not be used anymore. > > > > The EFI BGRT code depends on ACPI initialization to get the BGRT ACPI > > table, so move parsing of the BGRT table to ACPI early boot code to > > ensure that efi_mem_reserve() in EFI BGRT code still use memblock safely. > > > > Signed-off-by: Dave Young > > Cc: Matt Fleming > > Cc: "Rafael J. Wysocki" > > Cc: Len Brown > > Cc: linux-a...@vger.kernel.org > > Tested-by: Bhupesh Sharma > > Signed-off-by: Ard Biesheuvel > > I have a box that panics in early boot after this patch. The kernel > config is based on a Fedora 25 kernel + localmodconfig. > > BUG: unable to handle kernel paging request at ff240001 > IP: efi_bgrt_init+0xdc/0x134 > PGD 1ac0c067 > PUD 1ac0e067 > PMD 1aee9067 > PTE 938070180163 > > Oops: 0009 [#1] SMP > Modules linked in: > CPU: 0 PID: 0 Comm: swapper Not tainted 4.10.0-rc5-00116-g7b0a911 #19 > Hardware name: Hewlett-Packard HP Z220 CMT Workstation/1790, BIOS K51 v01.02 > 05/03/2012 > task: 9fc10500 task.stack: 9fc0 > RIP: 0010:efi_bgrt_init+0xdc/0x134 > RSP: :9fc03d58 EFLAGS: 00010082 > RAX: ff240001 RBX: RCX: 138070180006 > RDX: 8163 RSI: 938070180163 RDI: 05be > RBP: 9fc03d70 R08: 138070181000 R09: 0002 > R10: 0002d000 R11: 98a3dedd2fc6 R12: 9f9f22b6 > R13: 9ff49480 R14: 0010 R15: > FS: () GS:9fd2() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: ff240001 CR3: 1ac09000 CR4: 000406b0 > Call Trace: > ? acpi_parse_ioapic+0x98/0x98 > acpi_parse_bgrt+0x9/0xd > acpi_table_parse+0x7a/0xa9 > acpi_boot_init+0x3c7/0x4f9 > ? acpi_parse_x2apic+0x74/0x74 > ? acpi_parse_x2apic_nmi+0x46/0x46 > setup_arch+0xb4b/0xc6f > ? printk+0x52/0x6e > start_kernel+0xb2/0x47b > ? early_idt_handler_array+0x120/0x120 > x86_64_start_reservations+0x24/0x26 > x86_64_start_kernel+0xf7/0x11a > start_cpu+0x14/0x14 > Code: 48 c7 c7 10 16 a0 9f e8 4e 94 40 ff eb 62 be 06 00 00 00 e8 f9 ff 00 00 > 48 85 c0 75 0e 48 c7 c7 40 16 a0 9f e8 31 94 40 ff eb 45 <66> 44 8b 20 be 06 > 00 00 00 48 89 c7 8b 58 02 e8 87 00 01 00 66 > RIP: efi_bgrt_init+0xdc/0x134 RSP: 9fc03d58 > CR2: ff240001 > ---[ end trace f68728a0d3053b52 ]--- > Kernel panic - not syncing: Attempted to kill the idle task! > ---[ end Kernel panic - not syncing: Attempted to kill the idle task! > > > That code is: > > > All code > >0: 48 c7 c7 10 16 a0 9fmov$0x9fa01610,%rdi >7: e8 4e 94 40 ff callq 0xff40945a >c: eb 62 jmp0x70 >e: be 06 00 00 00 mov$0x6,%esi > 13: e8 f9 ff 00 00 callq 0x10011 > 18: 48 85 c0test %rax,%rax > 1b: 75 0e jne0x2b > 1d: 48 c7 c7 40 16 a0 9fmov$0x9fa01640,%rdi > 24: e8 31 94 40 ff callq 0xff40945a > 29: eb 45 jmp0x70 > 2b:*66 44 8b 20 mov(%rax),%r12w <-- > trapping instruction > 2f: be 06 00 00 00 mov$0x6,%esi > 34: 48 89 c7mov%rax,%rdi > 37: 8b 58 02mov0x2(%rax),%ebx > 3a: e8 87 00 01 00 callq 0x100c6 > 3f: 66 data16 > > Code starting with the faulting instruction > === >0: 66 44 8b 20 mov(%rax),%r12w >4: be 06 00 00 00 mov$0x6,%esi >9: 48 89 c7mov%rax,%rdi >c: 8b 58 02mov0x2(%rax),%ebx >f: e8 87 00 01 00 callq 0x1009b > 14: 66 data16 > > > which is just after the early_memremap() call. > > I enabled early_ioremap_debug and the last warning had: > > __early_ioremap(138070181000, 1000) [1] => 0001 + ff24 The phys addr looks odd.. >From the kernel log, I do not see any efi messages so can you check if you are booting with legacy mode or efi boot? I suppose bgrt are efi only, if you are test with legacy boot it is odd that there is BGRT table populated. For debugging purpose maybe you can add some printk to dump the acpi table header in efi_bgrt_init function, just print the version, status, image_type, image_address. If you can prove it is a non-efi boot, then maybe you can test below patch: diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c index 04ca87
[PATCH 2/3] Documentation: add sprd clock bindings
This patch adds a new directory under the 'clock' for Spreadtrum platform,
also bindings which document compatible strings and properties used for
devicetree node of clocks on Spreadtrum SoCs.
Signed-off-by: Chunyan Zhang
---
.../clock/sprd/sprd,adjustable-pll-clock.txt | 17 +
.../bindings/clock/sprd/sprd,composite-clock.txt | 28 +
.../bindings/clock/sprd/sprd,divider-clock.txt | 24 +++
.../bindings/clock/sprd/sprd,gates-clock.txt | 73 ++
.../bindings/clock/sprd/sprd,muxed-clock.txt | 23 +++
5 files changed, 165 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/sprd/sprd,adjustable-pll-clock.txt
create mode 100644
Documentation/devicetree/bindings/clock/sprd/sprd,composite-clock.txt
create mode 100644
Documentation/devicetree/bindings/clock/sprd/sprd,divider-clock.txt
create mode 100644
Documentation/devicetree/bindings/clock/sprd/sprd,gates-clock.txt
create mode 100644
Documentation/devicetree/bindings/clock/sprd/sprd,muxed-clock.txt
diff --git
a/Documentation/devicetree/bindings/clock/sprd/sprd,adjustable-pll-clock.txt
b/Documentation/devicetree/bindings/clock/sprd/sprd,adjustable-pll-clock.txt
new file mode 100644
index 000..476e315
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sprd/sprd,adjustable-pll-clock.txt
@@ -0,0 +1,17 @@
+Spreadtrum adjustable pll clock driver
+
+Required properties:
+
+- compatible : must be one of:
+ "sprd,sc9836-adjustable-pll-clock"
+ "sprd,sc9860-adjustable-pll-clock"
+
+Example:
+ clk_mpll0: clk@40400024 {
+ compatible = "sprd,sc9860-adjustable-pll-clock";
+ #clock-cells = <0>;
+ reg = <0 0x40400024 0 0x4>,
+ <0 0x40400028 0 0x4>;
+ clocks = <&clk_mpll_gates 2>;
+ clock-output-names = "clk_mpll0";
+ };
diff --git
a/Documentation/devicetree/bindings/clock/sprd/sprd,composite-clock.txt
b/Documentation/devicetree/bindings/clock/sprd/sprd,composite-clock.txt
new file mode 100644
index 000..a476eb6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sprd/sprd,composite-clock.txt
@@ -0,0 +1,28 @@
+Spreadtrum composite clock driver.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+
+- compatible: should be "sprd,composite-clock"
+
+- sprd,mux-msk:arbitrary bitmask for selecting clock input
+
+- sprd,div-msk:arbitrary bitmask for programming the divider,
+ denominator of divider is the value consisted
+ of these bits plus 1
+
+Example:
+
+ clk_sensor: clk@60e00024 {
+ compatible = "sprd,composite-clock";
+ #clock-cells = <0>;
+ reg = <0 0x60e00024 0 0x4>;
+ clocks = <&ext_26m>, <&clk_twpll_48m_def>,
+<&clk_twpll_76m8_def>, <&clk_twpll_96m_def>;
+ clock-output-names = "clk_sensor";
+ sprd,mux-msk = <0x3>;
+ sprd,div-msk = <0x700>;
+ };
diff --git
a/Documentation/devicetree/bindings/clock/sprd/sprd,divider-clock.txt
b/Documentation/devicetree/bindings/clock/sprd/sprd,divider-clock.txt
new file mode 100644
index 000..0bfc0ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sprd/sprd,divider-clock.txt
@@ -0,0 +1,24 @@
+Spreadtrum divider clock driver which only supports simple indexed divider
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+
+- compatible : should be "sprd,divider-clock"
+
+- sprd,div-msk:arbitrary bitmask for programming the divider,
+ denominator of divider is the value consisted
+ of these bits plus 1.
+
+Example:
+
+ clk_sdio0_1x: clk@402d032c {
+ compatible = "sprd,divider-clock";
+ #clock-cells = <0>;
+ reg = <0 0x402d032c 0 0x4>;
+ sprd,div-msk = <0x100>;
+ clocks = <&clk_sdio0_2x>;
+ clock-output-names = "clk_sdio0_1x";
+ };
diff --git a/Documentation/devicetree/bindings/clock/sprd/sprd,gates-clock.txt
b/Documentation/devicetree/bindings/clock/sprd/sprd,gates-clock.txt
new file mode 100644
index 000..f23ecb6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sprd/sprd,gates-clock.txt
@@ -0,0 +1,73 @@
+Spreadtrum gate clock driver
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Spreadtrum's SoCs often use one register to control more than one gate clocks.
+Clock consumers can use index to get the correct gate clock.
+
+In Spreadtrum platform, some of gate clocks have three registers, respectively
+used for controlling, setting and clearing gate clock, the addresses of
+these three registers generally are , , and
+, and offset
[PATCH 0/3] add clock driver for Spreadtrum platforms
In the last cycle, the patches support Whale2 sc9860 mobile chip have been merged. This patchset adds clock driver which is used on almost all Spreadtrum SoCs. This series also adds Spreadtrum clock bindings and SC9860 clock devicetree data. This driver has been validated on Spreadtrum SC9860 mobile phone. Any comments would be greatly appreciated. Thanks, Chunyan Chunyan Zhang (1): Documentation: add sprd clock bindings Xiaolong Zhang (2): arm64: dts: add SC9860 clock tree data clk: Add common clock driver for Spreadtrum SoCs .../clock/sprd/sprd,adjustable-pll-clock.txt | 17 + .../bindings/clock/sprd/sprd,composite-clock.txt | 28 + .../bindings/clock/sprd/sprd,divider-clock.txt | 24 + .../bindings/clock/sprd/sprd,gates-clock.txt | 73 + .../bindings/clock/sprd/sprd,muxed-clock.txt | 23 + arch/arm64/boot/dts/sprd/sc9860-clocks.dtsi| 1984 arch/arm64/boot/dts/sprd/sc9860.dtsi |1 + arch/arm64/boot/dts/sprd/whale2.dtsi |7 - drivers/clk/Makefile |1 + drivers/clk/sprd/Makefile |3 + drivers/clk/sprd/clk-gates.c | 366 drivers/clk/sprd/composite.c | 109 ++ drivers/clk/sprd/divider.c | 79 + drivers/clk/sprd/mux.c | 77 + drivers/clk/sprd/pll.c | 359 drivers/clk/sprd/pll.h | 73 + drivers/clk/sprd/pll_cfg.h | 390 17 files changed, 3607 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/sprd/sprd,adjustable-pll-clock.txt create mode 100644 Documentation/devicetree/bindings/clock/sprd/sprd,composite-clock.txt create mode 100644 Documentation/devicetree/bindings/clock/sprd/sprd,divider-clock.txt create mode 100644 Documentation/devicetree/bindings/clock/sprd/sprd,gates-clock.txt create mode 100644 Documentation/devicetree/bindings/clock/sprd/sprd,muxed-clock.txt create mode 100644 arch/arm64/boot/dts/sprd/sc9860-clocks.dtsi create mode 100644 drivers/clk/sprd/Makefile create mode 100644 drivers/clk/sprd/clk-gates.c create mode 100644 drivers/clk/sprd/composite.c create mode 100644 drivers/clk/sprd/divider.c create mode 100644 drivers/clk/sprd/mux.c create mode 100644 drivers/clk/sprd/pll.c create mode 100644 drivers/clk/sprd/pll.h create mode 100644 drivers/clk/sprd/pll_cfg.h -- 2.7.4
[PATCH 3/3] clk: Add common clock driver for Spreadtrum SoCs
From: Xiaolong Zhang
This patch adds an initial common clock driver comprising clock gate,
divider, multiplexer, composite, pll, these drivers are used on almost
all Spreadtrum platforms so far.
Signed-off-by: Xiaolong Zhang
Signed-off-by: Chunyan Zhang
---
drivers/clk/Makefile | 1 +
drivers/clk/sprd/Makefile| 3 +
drivers/clk/sprd/clk-gates.c | 366
drivers/clk/sprd/composite.c | 109
drivers/clk/sprd/divider.c | 79 +
drivers/clk/sprd/mux.c | 77 +
drivers/clk/sprd/pll.c | 359 +++
drivers/clk/sprd/pll.h | 73
drivers/clk/sprd/pll_cfg.h | 390 +++
9 files changed, 1457 insertions(+)
create mode 100644 drivers/clk/sprd/Makefile
create mode 100644 drivers/clk/sprd/clk-gates.c
create mode 100644 drivers/clk/sprd/composite.c
create mode 100644 drivers/clk/sprd/divider.c
create mode 100644 drivers/clk/sprd/mux.c
create mode 100644 drivers/clk/sprd/pll.c
create mode 100644 drivers/clk/sprd/pll.h
create mode 100644 drivers/clk/sprd/pll_cfg.h
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index c19983a..1d62721 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/
obj-$(CONFIG_ARCH_SIRF)+= sirf/
obj-$(CONFIG_ARCH_SOCFPGA) += socfpga/
obj-$(CONFIG_PLAT_SPEAR) += spear/
+obj-$(CONFIG_ARCH_SPRD)+= sprd/
obj-$(CONFIG_ARCH_STI) += st/
obj-$(CONFIG_ARCH_SUNXI) += sunxi/
obj-$(CONFIG_ARCH_SUNXI) += sunxi-ng/
diff --git a/drivers/clk/sprd/Makefile b/drivers/clk/sprd/Makefile
new file mode 100644
index 000..a783c27
--- /dev/null
+++ b/drivers/clk/sprd/Makefile
@@ -0,0 +1,3 @@
+ifneq ($(CONFIG_OF),)
+obj-y += divider.o mux.o composite.o pll.o
clk-gates.o
+endif
diff --git a/drivers/clk/sprd/clk-gates.c b/drivers/clk/sprd/clk-gates.c
new file mode 100644
index 000..8d4ccb9
--- /dev/null
+++ b/drivers/clk/sprd/clk-gates.c
@@ -0,0 +1,366 @@
+/*
+ * Spreadtrum clock set/clear gate driver
+ *
+ * Copyright (C) 2015~2017 spreadtrum, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DEFINE_SPINLOCK(gate_lock);
+
+#define to_clk_gate(_hw) container_of(_hw, struct clk_gate, hw)
+#define CLK_GATE_HWSPINLOCKBIT(7)
+#define GLB_CLK_HWSPINLOCK_TIMEOUT 5000
+
+static struct hwspinlock *glb_clk_hw_lock;
+
+static void sprd_clk_lock(struct clk_gate *gate,
+ unsigned long flags)
+{
+ if (gate->lock)
+ spin_lock_irqsave(gate->lock, flags);
+ else
+ __acquire(gate->lock);
+}
+
+static void sprd_clk_unlock(struct clk_gate *gate,
+ unsigned long flags)
+{
+ if (gate->lock)
+ spin_unlock_irqrestore(gate->lock, flags);
+ else
+ __release(gate->lock);
+}
+
+static void sprd_clk_hw_lock(struct clk_gate *gate,
+ unsigned long *flags)
+{
+ int ret = 0;
+
+ if (glb_clk_hw_lock && (gate->flags & CLK_GATE_HWSPINLOCK)) {
+ ret = hwspin_lock_timeout_irqsave(glb_clk_hw_lock,
+ GLB_CLK_HWSPINLOCK_TIMEOUT,
+ flags);
+ if (ret)
+ pr_err("glb_clk:%s lock the hwlock failed.\n",
+ __clk_get_name(gate->hw.clk));
+ return;
+ }
+
+ sprd_clk_lock(gate, *flags);
+}
+
+static void sprd_clk_hw_unlock(struct clk_gate *gate,
+ unsigned long *flags)
+{
+ if (glb_clk_hw_lock && (gate->flags & CLK_GATE_HWSPINLOCK)) {
+ hwspin_unlock_irqrestore(glb_clk_hw_lock, flags);
+ return;
+ }
+
+ sprd_clk_unlock(gate, *flags);
+}
+
+static void sprd_clk_gate_endisable(struct clk_hw *hw, int enable)
+{
+ struct clk_gate *gate = to_clk_gate(hw);
+ int set = gate->flags & CLK_GATE_SET_TO_DISABLE ? 1 : 0;
+ unsigned long flags = 0;
+ u32 reg;
+
+ set ^= enable;
+
+ sprd_clk_hw_lock(gate, &flags);
+
+ reg = clk_readl(gate->reg);
+
+ if (set)
+ reg |= BIT(gate->bit_idx);
+ else
+ reg &= ~BIT(gate->bit_idx);
+
+ clk_writel(reg, gate->reg);
+
+ sprd_clk_hw_unlock(gate, &flags);
+}
+
+static int sprd_clk_gate_enable(struct clk_hw *hw)
+{
+ sprd_clk_gate_endisable(hw, 1);
+
+ return 0;
+}
+
+static void sprd_clk_gate_disable(struct clk_hw *hw)
+{
+ sprd_clk_gate_endisable(hw, 0);
+}
+
+static int sprd_clk_gate_is_enabled(struct clk_hw *hw)
+{
+ u32 reg;
+ struct clk_gate *gate = to_clk_g
Re: [RFC] NVMe Configuraiton using sysctl
On Mon, May 15, 2017 at 2:04 PM, Oza Oza wrote: > Hi, > > we are configuring interrupt coalesce for NVMe, but right now, it uses > module param. > so the same interrupt coalesce settings get applied for all the NVMEs > connected to different RCs. > > ideally it should be with sysctl. > for e.g. > sysctl should provide interface to change > Per-CPU IO queue pairs, interrupt coalesce settings etc.. > > please suggest if we could have/implement sysctl module for NVMe ? > > Regards, > Oza. + linux-n...@lists.infradead.org
[PATCH 1/3] arm64: dts: add SC9860 clock tree data
From: Xiaolong Zhang
This patch addresses SC9860 clock topology structure and provides clock
node to other devices (clock consumers) on chip.
This patch also removed replicated node of 26m fixed clock.
Signed-off-by: Xiaolong Zhang
Signed-off-by: Chunyan Zhang
---
arch/arm64/boot/dts/sprd/sc9860-clocks.dtsi | 1984 +++
arch/arm64/boot/dts/sprd/sc9860.dtsi|1 +
arch/arm64/boot/dts/sprd/whale2.dtsi|7 -
3 files changed, 1985 insertions(+), 7 deletions(-)
create mode 100644 arch/arm64/boot/dts/sprd/sc9860-clocks.dtsi
diff --git a/arch/arm64/boot/dts/sprd/sc9860-clocks.dtsi
b/arch/arm64/boot/dts/sprd/sc9860-clocks.dtsi
new file mode 100644
index 000..5756933
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sc9860-clocks.dtsi
@@ -0,0 +1,1984 @@
+/*
+ * Spreadtrum SC9860 SoC DTS file
+ *
+ * Copyright (C) 2015, Spreadtrum Communications Inc.
+ *
+ * This file is licensed under a dual GPLv2 or X11 license.
+ */
+&soc {
+ aliases {
+ apb_pclk = &clk_ap_apb;
+ };
+
+ ext_26m: ext-26m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2600>;
+ clock-output-names = "ext_26m";
+ };
+
+ ext_32m_sine0: ext-32m-sine0 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <3200>;
+ clock-output-names = "ext_32m_sine0";
+ };
+
+ ext_32m_sine1: ext-32m-sine1 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <3200>;
+ clock-output-names = "ext_32m_sine1";
+ };
+
+ clk_pll_in: clk-pll-in {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2600>;
+ clock-output-names = "ext_26m";
+ };
+
+ clk_4m: clk-4m {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-mult = <1>;
+ clock-div = <6>;
+ clocks = <&ext_26m>;
+ clock-output-names = "clk_4m";
+ };
+
+ clk_2m: clk-2m {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-mult = <1>;
+ clock-div = <13>;
+ clocks = <&ext_26m>;
+ clock-output-names = "clk_2m";
+ };
+
+ clk_1m: clk-1m {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-mult = <1>;
+ clock-div = <26>;
+ clocks = <&ext_26m>;
+ clock-output-names = "clk_1m";
+ };
+
+ clk_250k: clk-250k {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-mult = <1>;
+ clock-div = <104>;
+ clocks = <&ext_26m>;
+ clock-output-names = "clk_250k";
+ };
+
+ ext_rco_100m: ext-rco-100m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1>;
+ clock-output-names = "ext_rco_100m";
+ };
+
+ ext_32k: ext-32k {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "ext_32k";
+ };
+
+ clk_rpll0_26m: clk-rpll0-26m {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-mult = <1>;
+ clock-div = <1>;
+ clocks = <&ext_26m>;
+ clock-output-names = "clk_rpll0_26m";
+ };
+
+ clk_rpll1_26m: clk-rpll1-26m {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-mult = <1>;
+ clock-div = <1>;
+ clocks = <&ext_26m>;
+ clock-output-names = "clk_rpll1_26m";
+ };
+
+ clk_rpll_gates: clk@402b016c {
+ compatible = "sprd,sc1000-gates-clock";
+ #clock-cells = <1>;
+ reg = <0 0x402b016c 0 0x3000>;
+ clocks = <&ext_26m>;
+ clock-indices = <2>, <18>;
+ clock-output-names = "clk_rpll0_gate", "clk_rpll1_gate";
+ };
+
+ clk_mpll_gates: clk@402b00b0 {
+ compatible = "sprd,sc1000-gates-clock";
+ #clock-cells = <1>;
+ reg = <0 0x402b00b0 0 0x3000>;
+ clocks = <&ext_26m>;
+ clock-indices = <2>, <18>;
+ clock-output-names = "clk_mpll0_gate", "clk_mpll1_gate";
+ };
+
+ clk_dpll_gates: clk@402b00b4 {
+ compatible = "sprd,sc1000-gates-clock";
+ #clock-cells = <1>;
+ reg = <0 0x402b00b4 0 0x3000>;
+ clocks = <&ext_
Re: [PATCH v3 4/6] drm: Use new mode_valid() helpers in connector probe helper
On 11.05.2017 11:06, Jose Abreu wrote:
> This changes the connector probe helper function to use the new
> encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid()
> helper callbacks to validate the modes.
>
> The new callbacks are optional so the behaviour remains the same
> if they are not implemented. If they are, then the code loops
> through all the connector's encodersXbridgesXcrtcs and calls the
> callback.
>
> If at least a valid encoderXbridgeXcrtc combination is found which
> accepts the mode then the function returns MODE_OK.
>
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: Alexey Brodkin
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Andrzej Hajda
> Cc: Archit Taneja
> ---
>
> Changes v2->v3:
> - Call also bridge->mode_valid (Daniel)
> Changes v1->v2:
> - Use new helpers suggested by Ville
> - Change documentation (Daniel)
>
> drivers/gpu/drm/drm_probe_helper.c | 65
> --
> 1 file changed, 62 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index f01abdc..84d660e 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -83,6 +83,61 @@
> return MODE_OK;
> }
>
> +static enum drm_mode_status
> +drm_mode_validate_connector(struct drm_connector *connector,
> + struct drm_display_mode *mode)
> +{
> + struct drm_device *dev = connector->dev;
> + uint32_t *ids = connector->encoder_ids;
> + enum drm_mode_status ret = MODE_OK;
> + unsigned int i;
> +
> + /* Step 1: Validate against connector */
> + ret = drm_connector_mode_valid(connector, mode);
> + if (ret != MODE_OK)
> + return ret;
> +
> + /* Step 2: Validate against encoders and crtcs */
> + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> + struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]);
> + struct drm_crtc *crtc;
> +
> + if (!encoder)
> + continue;
> +
> + ret = drm_encoder_mode_valid(encoder, mode);
> + if (ret != MODE_OK) {
> + /* No point in continuing for crtc check as this encoder
> + * will not accept the mode anyway. If all encoders
> + * reject the mode then, at exit, ret will not be
> + * MODE_OK. */
> + continue;
> + }
> +
> + ret = drm_bridge_mode_valid(encoder->bridge, mode);
> + if (ret != MODE_OK) {
> + /* There is also no point in continuing for crtc check
> + * here. */
> + continue;
> + }
Maybe it is a bikeshedding, but wouldn't be better to call
drm_bridge_mode_valid from drm_encoder_mode_valid, in general call all
bridge related stuff from corresponding encoder stuff?
This is more question about role of encoder->bridge, should it be
treated as encoder's extension, or as 1st class citizen in drm?
Another concern is about order of calls, it is from sink to source, to
keep it consistent bridge should be called before encoder, am I right?
Beside this:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> +
> + drm_for_each_crtc(crtc, dev) {
> + if (!drm_encoder_crtc_ok(encoder, crtc))
> + continue;
> +
> + ret = drm_crtc_mode_valid(crtc, mode);
> + if (ret == MODE_OK) {
> + /* If we get to this point there is at least
> + * one combination of encoder+crtc that works
> + * for this mode. Lets return now. */
> + return ret;
> + }
> + }
> + }
> +
> + return ret;
> +}
> +
> static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector)
> {
> struct drm_cmdline_mode *cmdline_mode;
> @@ -322,7 +377,11 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
> *- drm_mode_validate_flag() checks the modes against basic connector
> * capabilities (interlace_allowed,doublescan_allowed,stereo_allowed)
> *- the optional &drm_connector_helper_funcs.mode_valid helper can
> perform
> - * driver and/or hardware specific checks
> + * driver and/or sink specific checks
> + *- the optional &drm_crtc_helper_funcs.mode_valid,
> + * &drm_bridge_funcs.mode_valid and &drm_encoder_helper_funcs.mode_valid
> + * helpers can perform driver and/or source specific checks which are
> also
> + * enforced by the modeset/atomic helpers
> *
> * 5. Any mode whose status is not OK is pruned from the connector's modes
> list,
> *accompanied by a debug message indicating the reason for the mode's
> @@ -466,8 +525,8 @@ int drm_helper_probe_singl
Re: [PATCH v7 01/13] dt-bindings: add binding for the Allwinner DE2 CCU
On Mon, May 15, 2017 at 12:30:33AM +0800, Icenowy Zheng wrote: > Allwinner "Display Engine 2.0" contains some clock controls in it. > > In order to add them as clock drivers, we need a device tree binding. > Add the binding here. > > Also add the device tree binding headers. > > Signed-off-by: Icenowy Zheng > Acked-by: Rob Herring Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v7 02/13] clk: sunxi-ng: add support for DE2 CCU
On Mon, May 15, 2017 at 12:30:34AM +0800, Icenowy Zheng wrote: > The "Display Engine 2.0" in Allwinner newer SoCs contains a clock > management unit for its subunits, like the DE CCU in A80. > > Add a sunxi-ng style driver for it. > > Signed-off-by: Icenowy Zheng Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH][RESEND] regulator: lp8755: fix spelling mistake "acceess" -> "access"
On 14/05/17 10:25, Mark Brown wrote: > On Wed, May 10, 2017 at 09:30:20AM +0100, Colin King wrote: >> From: Colin Ian King >> >> Trivial fix to spelling mistake in dev_err messages. > > If this is a resend why do I not seem to have a copy of this patch? > Probably because I goofed up. Doh. signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 2/2] dmaengine: dw: Remove AVR32 bits from the driver
On Sun, 2017-05-14 at 18:34 +0530, Vinod Koul wrote: > On Tue, May 09, 2017 at 07:18:37PM +0300, Andy Shevchenko wrote: > > AVR32 is gone. Now it's time to clean up the driver by removing > > leftovers that was used by AVR32 related code. > > Since the cover didn't mention any dependency, I went ahead and > applied this > now > Sorry, I forgot to mention that it's supposed to go via either tree, though together. Since first we remove users of non-standard DMA callbacks. -- Andy Shevchenko Intel Finland Oy
Re: [PATCH] drivers/staging: refactor dgnc tty registration.
On Sun, May 14, 2017 at 06:50:24PM +0300, Haim Daniel wrote:
> @@ -129,6 +113,41 @@ static void dgnc_tty_set_termios(struct tty_struct *tty,
>
> /* TTY Initialization/Cleanup Functions */
>
> +static struct tty_driver *__dgnc_tty_register(char *serial_name, uint
> maxports,
No need for double underscores.
> + int major, int minor)
> +{
> + int rc;
> + struct tty_driver *drv = tty_alloc_driver(maxports,
> + TTY_DRIVER_REAL_RAW |
> + TTY_DRIVER_DYNAMIC_DEV |
> + TTY_DRIVER_HARDWARE_BREAK);
> + if (IS_ERR(drv))
> + return drv;
Blank line between declaration and code. Do it like this:
struct tty_driver *drv;
int rc;
drv = tty_alloc_driver(maxports, TTY_DRIVER_REAL_RAW |
TTY_DRIVER_DYNAMIC_DEV |
TTY_DRIVER_HARDWARE_BREAK);
if (IS_ERR(drv))
return drv;
Also create a matching dgnc_tty_unregister function that does:
static void dgnc_tty_unregister(struct tty_driver *drv)
{
tty_unregister_driver(drv);
put_tty_driver(drv);
}
regards,
dan carpenter
