[PATCH v2 1/2] clk: at91: cleanup PMC header file for PCR register fields

June 17, 2015, 5:50 am

≫ Next: [PATCH v2 2/2] clk: at91: modify PMC peripheral clock to deal with newer register layout

≪ Previous: Re: [RESEND PATCH 1/2] pinctrl: change function behavior for per pin muxing controllers

Add _MASK and _OFFSET values and cleanup register fields layout.

Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/clk/at91/clk-peripheral.c | 8 ++++----
include/linux/clk/at91_pmc.h | 14 ++++++--------
2 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/at91/clk-peripheral.c b/drivers/clk/at91/clk-peripheral.c
index 597fed423d7d..61d0adda7088 100644
--- a/drivers/clk/at91/clk-peripheral.c
+++ b/drivers/clk/at91/clk-peripheral.c
@@ -165,7 +165,7 @@ static int clk_sam9x5_peripheral_enable(struct clk_hw *hw)
if (periph->id < PERIPHERAL_ID_MIN)
return 0;

- pmc_write(pmc, AT91_PMC_PCR, (periph->id & AT91_PMC_PCR_PID) |
+ pmc_write(pmc, AT91_PMC_PCR, (periph->id & AT91_PMC_PCR_PID_MASK) |
AT91_PMC_PCR_CMD |
AT91_PMC_PCR_DIV(periph->div) |
AT91_PMC_PCR_EN);
@@ -180,7 +180,7 @@ static void clk_sam9x5_peripheral_disable(struct clk_hw *hw)
if (periph->id < PERIPHERAL_ID_MIN)
return;

- pmc_write(pmc, AT91_PMC_PCR, (periph->id & AT91_PMC_PCR_PID) |
+ pmc_write(pmc, AT91_PMC_PCR, (periph->id & AT91_PMC_PCR_PID_MASK) |
AT91_PMC_PCR_CMD);
}

@@ -194,7 +194,7 @@ static int clk_sam9x5_peripheral_is_enabled(struct clk_hw *hw)
return 1;

pmc_lock(pmc);
- pmc_write(pmc, AT91_PMC_PCR, (periph->id & AT91_PMC_PCR_PID));
+ pmc_write(pmc, AT91_PMC_PCR, (periph->id & AT91_PMC_PCR_PID_MASK));
ret = !!(pmc_read(pmc, AT91_PMC_PCR) & AT91_PMC_PCR_EN);
pmc_unlock(pmc);

@@ -213,7 +213,7 @@ clk_sam9x5_peripheral_recalc_rate(struct clk_hw *hw,
return parent_rate;

pmc_lock(pmc);
- pmc_write(pmc, AT91_PMC_PCR, (periph->id & AT91_PMC_PCR_PID));
+ pmc_write(pmc, AT91_PMC_PCR, (periph->id & AT91_PMC_PCR_PID_MASK));
tmp = pmc_read(pmc, AT91_PMC_PCR);
pmc_unlock(pmc);

diff --git a/include/linux/clk/at91_pmc.h b/include/linux/clk/at91_pmc.h
index 7669f7618f39..dfc59e2b64fb 100644
--- a/include/linux/clk/at91_pmc.h
+++ b/include/linux/clk/at91_pmc.h
@@ -182,13 +182,11 @@ extern void __iomem *at91_pmc_base;
#define AT91_PMC_PCSR1 0x108 /* Peripheral Clock Enable Register 1 */

#define AT91_PMC_PCR 0x10c /* Peripheral Control Register [some SAM9 and SAMA5] */
-#define AT91_PMC_PCR_PID (0x3f << 0) /* Peripheral ID */
-#define AT91_PMC_PCR_CMD (0x1 << 12) /* Command (read=0, write=1) */
-#define AT91_PMC_PCR_DIV(n) ((n) << 16) /* Divisor Value */
-#define AT91_PMC_PCR_DIV0 0x0 /* Peripheral clock is MCK */
-#define AT91_PMC_PCR_DIV2 0x1 /* Peripheral clock is MCK/2 */
-#define AT91_PMC_PCR_DIV4 0x2 /* Peripheral clock is MCK/4 */
-#define AT91_PMC_PCR_DIV8 0x3 /* Peripheral clock is MCK/8 */
-#define AT91_PMC_PCR_EN (0x1 << 28) /* Enable */
+#define AT91_PMC_PCR_PID_MASK 0x3f
+#define AT91_PMC_PCR_CMD (0x1 << 12) /* Command (read=0, write=1) */
+#define AT91_PMC_PCR_DIV_OFFSET 16
+#define AT91_PMC_PCR_DIV_MASK (0x3 << AT91_PMC_PCR_DIV_OFFSET)
+#define AT91_PMC_PCR_DIV(n) ((n) << AT91_PMC_PCR_DIV_OFFSET) /* Divisor Value */
+#define AT91_PMC_PCR_EN (0x1 << 28) /* Enable */

#endif
--
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

[PATCH v2 2/2] clk: at91: modify PMC peripheral clock to deal with newer register layout

June 17, 2015, 5:50 am

≫ Next: Re: [PATCH RESEND] perf tools: Ignore .config-detected in .gitignore

≪ Previous: [PATCH v2 1/2] clk: at91: cleanup PMC header file for PCR register fields

As some more information is added to the PCR register, we'd better use
a copy of its content and modify just the peripheral-related bits.
Implement a read-modify-write for the enable() and disable() callbacks.

Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
v2: - modify header file beforehand so that we can use consistent field naming

drivers/clk/at91/clk-peripheral.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/at91/clk-peripheral.c b/drivers/clk/at91/clk-peripheral.c
index 61d0adda7088..1e7dcc57925a 100644
--- a/drivers/clk/at91/clk-peripheral.c
+++ b/drivers/clk/at91/clk-peripheral.c
@@ -161,14 +161,18 @@ static int clk_sam9x5_peripheral_enable(struct clk_hw *hw)
{
struct clk_sam9x5_peripheral *periph = to_clk_sam9x5_peripheral(hw);
struct at91_pmc *pmc = periph->pmc;
+ u32 tmp;

if (periph->id < PERIPHERAL_ID_MIN)
return 0;

- pmc_write(pmc, AT91_PMC_PCR, (periph->id & AT91_PMC_PCR_PID_MASK) |
- AT91_PMC_PCR_CMD |
- AT91_PMC_PCR_DIV(periph->div) |
- AT91_PMC_PCR_EN);
+ pmc_lock(pmc);
+ pmc_write(pmc, AT91_PMC_PCR, (periph->id & AT91_PMC_PCR_PID_MASK));
+ tmp = pmc_read(pmc, AT91_PMC_PCR) & ~AT91_PMC_PCR_DIV_MASK;
+ pmc_write(pmc, AT91_PMC_PCR, tmp | AT91_PMC_PCR_DIV(periph->div)
+ | AT91_PMC_PCR_CMD
+ | AT91_PMC_PCR_EN);
+ pmc_unlock(pmc);
return 0;
}

@@ -176,12 +180,16 @@ static void clk_sam9x5_peripheral_disable(struct clk_hw *hw)
{
struct clk_sam9x5_peripheral *periph = to_clk_sam9x5_peripheral(hw);
struct at91_pmc *pmc = periph->pmc;
+ u32 tmp;

if (periph->id < PERIPHERAL_ID_MIN)
return;

- pmc_write(pmc, AT91_PMC_PCR, (periph->id & AT91_PMC_PCR_PID_MASK) |
- AT91_PMC_PCR_CMD);
+ pmc_lock(pmc);
+ pmc_write(pmc, AT91_PMC_PCR, (periph->id & AT91_PMC_PCR_PID_MASK));
+ tmp = pmc_read(pmc, AT91_PMC_PCR) & ~AT91_PMC_PCR_EN;
+ pmc_write(pmc, AT91_PMC_PCR, tmp | AT91_PMC_PCR_CMD);
+ pmc_unlock(pmc);
}

static int clk_sam9x5_peripheral_is_enabled(struct clk_hw *hw)
--
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

Re: [PATCH RESEND] perf tools: Ignore .config-detected in .gitignore

June 17, 2015, 5:50 am

≫ Next: Re: [RESEND PATCH 2/2] pinctrl: introduce complex pin description

≪ Previous: [PATCH v2 2/2] clk: at91: modify PMC peripheral clock to deal with newer register layout

This patch has already acked-by Jiri Olsa on March, but I lost the original
email on my local mailbox, so send it again.

Thank you.

On 2015/6/17 19:59, Wang Nan wrote:
> Commit fcfd6611fbccdbf2593bd949097a5c0e45cd96da ("tools build: Add
> detected config support") dynamically creates .config-detected. Add it
> to .gitignore.
>
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
> ---
> tools/perf/.gitignore | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore
> index 812f904..09db62b 100644
> --- a/tools/perf/.gitignore
> +++ b/tools/perf/.gitignore
> @@ -28,3 +28,4 @@ config.mak.autogen
> *-flex.*
> *.pyc
> *.pyo
> +.config-detected

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

Re: [RESEND PATCH 2/2] pinctrl: introduce complex pin description

June 17, 2015, 5:50 am

≫ Next: 4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?

≪ Previous: Re: [PATCH RESEND] perf tools: Ignore .config-detected in .gitignore

On Mon, Jun 15, 2015 at 10:01:29AM -0600, Stephen Warren wrote:
> On 06/10/2015 09:04 AM, Ludovic Desroches wrote:
> >Using a string to describe a pin in the device tree can be not enough.
> >Some controllers may need extra information to fully describe a pin. It
> >concerns mainly controllers which have a per pin muxing approach which
> >don't fit well the notions of groups and functions.
> >Instead of using a pin name, a 32 bit value is used. The 16 least
> >significant bits are used for the pin number. Other 16 bits can be used to
> >store extra parameters.
>
> The driver for the pin controller is supposed to provide this information in
> a table. The whole point of having a driver, rather than a table/list of raw
> register values in the DT, is so the driver can provide this information at
> a semantic level. This information is fixed per SoC and so make sense to put
> into a driver, while the board-specific configuration varies wildly, and
> hence makes sense to put into DT.
>
>

I didn't think the controversery part would be about having this
information in a driver or in the device tree. I think there are pros
and cons for both cases.

We already have this description in our dt file with the previous at91
pin controller and I think it is a good thing to not have to update the
driver for each new SoC using the same pio controller. Tables could become
huge, embedding several one into a 'single zImage' is something I am not
confortable with. I know that some people could tell me that doing that
may increase the boot time.

We should debate about this patch later. If there is no acceptance for
the previous one, I have to clarify if I need it.

Regards

Ludovic
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?

June 17, 2015, 5:50 am

≫ Next: Re: [PATCH 4/8] ARCv2: perf: Support sampling events using overflow interrupts

≪ Previous: Re: [RESEND PATCH 2/2] pinctrl: introduce complex pin description

Hi!

Video is broken on thinkpad T40p after resume from suspend. (In X
only, text console still works.)

Maybe this is related?

[ 5430.193071] radeon 0000:01:00.0: putting AGP V2 device into 4x mode
[ 5430.193107] radeon 0000:01:00.0: GTT: 256M 0xD0000000 - 0xDFFFFFFF
[ 5430.214670] radeon 0000:01:00.0: WB disabled
[ 5430.214675] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x00000000d0000000 and cpu addr 0xf841a000
[ 5430.214721] [drm] radeon: ring at 0x00000000D0001000
[ 5430.370867] [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E8)=0xCAFEDEAD)
[ 5430.370869] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
[ 5430.370872] radeon 0000:01:00.0: failed initializing CP (-22).

Hibernation works well here, including X. (Which has small glitch with
mouse cursor being corrupted until it is changed by application).

Any ideas?

Pavel

[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 4.1.0-rc7+ (pavel@amd) (gcc version 4.9.2 (Debian 4.9.2-10) ) #89 SMP Wed Jun 17 10:27:56 CEST 2015
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000d2000-0x00000000000d3fff]
reserved
....
[ 5427.867556] PM: Syncing filesystems ... done.
[ 5428.043929] PM: Preparing system for mem sleep
[ 5428.044503] Freezing user space processes ... (elapsed 0.219 seconds) done.
[ 5428.264427] Freezing remaining freezable tasks ... (elapsed 0.007 seconds) done.
[ 5428.272397] PM: Entering mem sleep
[ 5428.272445] Suspending console(s) (use no_console_suspend to debug)
[ 5428.468800] wlan1: deauthenticating from 00:11:95:05:30:d7 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 5428.529996] parport_pc 00:07: disabled
[ 5428.530278] serial 00:06: disabled
[ 5428.530637] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 5428.530909] sd 0:0:0:0: [sda] Stopping disk
[ 5428.530986] cfg80211: Calling CRDA to update world regulatory domain
[ 5428.531296] serial 00:06: System wakeup disabled by ACPI
[ 5428.585816] pci 0000:00:1e.0: System wakeup enabled by ACPI
[ 5428.588374] radeon 0000:01:00.0: Refused to change power state, currently in D0
[ 5428.960707] PM: suspend of devices complete after 687.029 msecs
[ 5428.960711] PM: suspend devices took 0.688 seconds
[ 5428.963240] PM: late suspend of devices complete after 2.522 msecs
[ 5428.965743] pci0000:00: System wakeup enabled by ACPI
[ 5428.965965] uhci_hcd 0000:00:1d.1: System wakeup enabled by ACPI
[ 5429.044103] uhci_hcd 0000:00:1d.0: System wakeup enabled by ACPI
[ 5429.044148] PM: noirq suspend of devices complete after 80.904 msecs
[ 5429.044391] ACPI: Preparing to enter system sleep state S3
[ 5429.428156] ACPI : EC: EC stopped
[ 5429.428158] PM: Saving platform NVS memory
[ 5429.428203] Disabling non-boot CPUs ...
[ 5429.428203] ACPI: Low-level resume complete
[ 5429.428203] ACPI : EC: EC started
[ 5429.428203] PM: Restoring platform NVS memory
[ 5429.428357] ACPI: Waking up from system sleep state S3
[ 5430.188112] uhci_hcd 0000:00:1d.0: System wakeup disabled by ACPI
[ 5430.188223] uhci_hcd 0000:00:1d.1: System wakeup disabled by ACPI
[ 5430.188273] pci0000:00: System wakeup disabled by ACPI
[ 5430.188675] PM: noirq resume of devices complete after 80.536 msecs
[ 5430.192180] PM: early resume of devices complete after 2.138 msecs
[ 5430.192754] usb usb2: root hub lost power or was reset
[ 5430.192796] usb usb3: root hub lost power or was reset
[ 5430.192835] usb usb4: root hub lost power or was reset
[ 5430.192986] [drm] AGP mode requested: 4
[ 5430.192990] agpgart-intel 0000:00:00.0: AGP 2.0 bridge
[ 5430.193015] agpgart-intel 0000:00:00.0: putting AGP V2 device into 4x mode
[ 5430.193071] radeon 0000:01:00.0: putting AGP V2 device into 4x mode
[ 5430.193107] radeon 0000:01:00.0: GTT: 256M 0xD0000000 - 0xDFFFFFFF
[ 5430.214670] radeon 0000:01:00.0: WB disabled
[ 5430.214675] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x00000000d0000000 and cpu addr 0xf841a000
[ 5430.214721] [drm] radeon: ring at 0x00000000D0001000
[ 5430.370867] [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E8)=0xCAFEDEAD)
[ 5430.370869] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
[ 5430.370872] radeon 0000:01:00.0: failed initializing CP (-22).
[ 5430.858899] pci 0000:00:1e.0: System wakeup disabled by ACPI
[ 5430.865104] rtc_cmos 00:02: System wakeup disabled by ACPI
[ 5430.866275] serial 00:06: activated
[ 5430.867674] parport_pc 00:07: activated
[ 5430.871577] sd 0:0:0:0: [sda] Starting disk
[ 5431.032503] ata2.00: ACPI cmd ef/03:42:00:00:00:a0 (SET FEATURES) filtered out
[ 5431.032507] ata2.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered out
[ 5431.032712] ata2.00: ACPI cmd e3/00:1f:00:00:00:a0 (IDLE) succeeded
[ 5431.032913] ata2.00: ACPI cmd e3/00:02:00:00:00:a0 (IDLE) succeeded
[ 5431.056386] ata2.00: configured for UDMA/33
[ 5431.200097] usb 4-1: reset full-speed USB device number 2 using uhci_hcd
[ 5431.808764] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[ 5431.808768] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[ 5431.808772] ata1.00: ACPI cmd ef/03:45:00:00:00:a0 (SET FEATURES) filtered out
[ 5431.808775] ata1.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered out
[ 5431.824335] ata1.00: configured for UDMA/100
[ 5432.197993] PM: resume of devices complete after 2005.805 msecs
[ 5432.200591] PM: resume devices took 2.008 seconds
[ 5432.200718] PM: Finishing wakeup.
[ 5432.200722] Restarting tasks ... done.
[ 5434.742039] cfg80211: World regulatory domain updated:
[ 5434.742049] cfg80211: DFS Master region: unset
[ 5434.742053] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 5434.742061] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 5434.742066] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 5434.742071] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[ 5434.742076] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 5434.742082] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 5434.742087] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 5434.742092] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 5434.742096] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 5437.929693] wlan1: authenticate with 00:11:95:05:30:d7
[ 5438.016901] wlan1: send auth to 00:11:95:05:30:d7 (try 1/3)
[ 5438.018898] wlan1: authenticated
[ 5438.025830] ath5k 0000:02:02.0 wlan1: disabling HT as WMM/QoS is not supported by the AP
[ 5438.025842] ath5k 0000:02:02.0 wlan1: disabling VHT as WMM/QoS is not supported by the AP
[ 5438.025863] wlan1: associating with AP with corrupt beacon
[ 5438.028549] wlan1: associate with 00:11:95:05:30:d7 (try 1/3)
[ 5438.030604] wlan1: RX AssocResp from 00:11:95:05:30:d7 (capab=0x401 status=0 aid=9)
[ 5438.030759] wlan1: associated

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

Re: [PATCH 4/8] ARCv2: perf: Support sampling events using overflow interrupts

June 17, 2015, 5:50 am

≫ Next: Re: [PATCH v2 4/4] scsi: ufs: probe and init of variant driver from the platform device

≪ Previous: 4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?

On Wed, Jun 17, 2015 at 05:18:27PM +0530, Vineet Gupta wrote:
> Turns out that it is possible to implement NMI on ARCv2 in a pretty
> straightforward way.
>
> Our RTOS Guru, Chuck, told me off list, that instead of using CLRI / SETI, we can
> use SETI with different args which would keep the stat32.IE enabled all the times,
> but wiggle the stat32.E[ ] to change the intr prio level, effectively locking out
> only lower prio interrupts in any local_irq_save() / restore() region.

Nice.

> But isn't this defying the irq disable/enable semantics and could lead to
> potential breach of *some* critical section.

Well only if you then hand out interrupts for that priority level
without treating them as NMIs.

Note that NMIs do not nest, so if your hardware can raise multiple
interrupts for any one level it needs to mask the level in your
handler's entry code.

> Neverthless, doing this requires some more changes in ARCv2 support code - so for
> now we will go with the normal interrupts and later bolt on the NMI emulation.

Sure, smalls steps etc.. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

Re: [PATCH v2 4/4] scsi: ufs: probe and init of variant driver from the platform device

June 17, 2015, 5:50 am

≫ Next: Re: [PATCH] ARM: fix DEBUG_UART_PHYS/VIRT issue when modifying DEBUG_LL output

≪ Previous: Re: [PATCH 4/8] ARCv2: perf: Support sampling events using overflow interrupts

On Wed, Jun 17, 2015 at 2:42 AM, Dov Levenglick <dovl@codeaurora.org> wrote:
>> On Tue, Jun 9, 2015 at 12:53 AM, Dov Levenglick <dovl@codeaurora.org>
>> wrote:
>>>> On Sun, Jun 7, 2015 at 10:32 AM, <ygardi@codeaurora.org> wrote:
>>>>>> 2015-06-05 5:53 GMT+09:00 <ygardi@codeaurora.org>:
>>
>> [...]
>>
>>>>> If ufshcd-pltfrm driver is loaded before ufs-qcom, (what actually
>>>>> happens
>>>>> always), then the calling to of_platform_populate() which is added,
>>>>> guarantees that ufs-qcom probe will be called and finish, before
>>>>> ufshcd_pltfrm probe continues.
>>>>> so ufs_variant device is always there, and ready.
>>>>> I think it means we are safe - since either way, we make sure ufs-qcom
>>>>> probe will be called and finish before dealing with ufs_variant device
>>>>> in
>>>>> ufshcd_pltfrm probe.
>>>>
>>>> This is due to the fact that you have 2 platform drivers. You should
>>>> only have 1 (and 1 node). If you really think you need 2, then you
>>>> should do like many other common *HCIs do and make the base UFS driver
>>>> a set of library functions that drivers can use or call. Look at EHCI,
>>>> AHCI, SDHCI, etc. for inspiration.
>>>
>>> Hi Rob,
>>> We did look at SDHCI and decided to go with this design due to its
>>> simplicity and lack of library functions. Yaniv described the proper
>>> flow
>>> of probing and, as we understand things, it is guaranteed to work as
>>> designed.
>>>
>>> Furthermore, the design of having a subcore in the dts is used in the
>>> Linux kernel. Please have a look at drivers/usb/dwc3 where - as an
>>> example
>>> - both dwc3-msm and dwc3-exynox invoke the probing function in core.c
>>> (i.e. the shared underlying Synopsys USB dwc3 core) by calling
>>> of_platform_populate().
>>
>> That binding has the same problem. Please don't propagate that. There
>> is no point in a sub-node in this case.
>>
>>> Do you see a benefit in the SDHCi implementation?
>>
>> Yes, it does not let the kernel driver design dictate the hardware
>> description.
>>
>> Rob
>>
>
> Hi Rob,
> We appear to be having a philosophical disagreement on the practicality of
> designing the ufshcd variant's implementation - in other words, we
> disagree on the proper design pattern to follow here.
> If I understand correctly, you are concerned with a design pattern wherein
> a generic implementation is wrapped - at the device-tree level - in a
> variant implementation. The main reason for your concern is that you don't
> want the "kernel driver design dictate the hardware description".
>
> We considered this point when we suggested our implementation (both before
> and after you raised it) and reached the conclusion that - while an
> important consideration - it should not be the prevailing one. I believe
> that you will agree once you read the reasoning. What guided us was the
> following:
> 1. Keep our change minimal.
> 2. Keep our patch in line with known design patterns in the kernel.
> 3. Have our patch extend the existing solution rather than reinvent it.
>
> It is the 3rd point that is most important to this discussion, since UFS
> has already been deployed by various vendors and is used by OEM. Changing
> ufshcd to a set of library functions that would be called by variants
> would necessarily introduce a significant change to the code flow in many
> places and would pose a backward compatibility issue. By using the tried
> and tested pattern of subnodes in the dts we were able to keep the change
> simple, succinct, understandable, maintainable and backward compatible. In
> fact, the entire logic tying of the generic implementation to the variant
> takes ~20 lines of code - both short and elegant.

The DWC3 binding does this and nothing else that I'm aware of. This
hardly makes for a common pattern. If you really want to split this to
2 devices, you can create platform devices without having a DT node.

If you want to convince me this is the right approach for the binding
then you need to convince me the h/w is actually split this way and
there is functionality separate from the licensed IP.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

Re: [PATCH] ARM: fix DEBUG_UART_PHYS/VIRT issue when modifying DEBUG_LL output

June 17, 2015, 5:50 am

≫ Next: Re: 4.1-rc7, thinkpad X60: platform mode hibernation does very wrongthing

≪ Previous: Re: [PATCH v2 4/4] scsi: ufs: probe and init of variant driver from the platform device

Hello,

On Tue, 13 Jan 2015 11:37:48 +0100, Boris Brezillon wrote:
> The DEBUG_UART_PHYS/VIRT value can only be automatically set once
> (automatically means set from the DEBUG_<SOC_ID>_<UART_ID> option), which
> prevents re-configuring the earlyprintk output for another platform once
> the DEBUG_LL output has been selected.
>
> Add a new boolean option (DEBUG_CUSTOM_UART_ADDR) enabling custom phys and
> virt address setting (configured through DEBUG_CUSTOM_UART_PHYS/VIRT
> options), and make DEBUG_UART_PHYS/VIRT hidden so that they will always be
> set from one of the 'default' definitions, and thus will be overwritten
> each time you change the DEBUG_LL output.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>

What is the status of this patch? It would actually be quite useful
when switching back and forth between different DEBUG_LL configurations.

Russell, what do you think of the proposed approach?

Thanks,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

Re: 4.1-rc7, thinkpad X60: platform mode hibernation does very wrongthing

June 17, 2015, 5:50 am

≫ Next: Re: [PATCH 2/3] spi: mediatek: Add spi bus for Mediatek MT8173

≪ Previous: Re: [PATCH] ARM: fix DEBUG_UART_PHYS/VIRT issue when modifying DEBUG_LL output

On Wednesday, June 17, 2015 02:33:33 PM Pavel Machek wrote:
> Hi!
>
> > On Wednesday, June 17, 2015 08:19:37 PM linus wrote:
> > > there might be something wrong with driver, can you provide serial log with no_console_suspend? or using rtctrace
> > >
>
> Who are you?
>
> The hibernation image is stored successfully, that means drivers work ok.

Well, not entirely necessarily. We execute the ->poweroff callback for all
of them in the last step, maybe one of these hangs.

You can verify that by adding a reboot trigger after the dpm_suspend_end()
invocation in hibernation_platform_enter(). If it triggers 100% of the time,
drivers are OK.

> Serial console... might be fun to set up, but might help, right.
>
> > > Hi!
> > >
> > > On thinkpad X60, if I hibernate in platform mode, it does not power
> > > down, but I get black screen, moon icon blinking, and CPU fan running
> > > (CPU probably too).
> > >
> > > I can hold the power button down to force powerdown... if I notice
> > > what is going on before the battery is empty.
> > >
> > > Any ideas what could be wrong there?
> >
> > Not right away.
> >
> > Have you tried any previous 4.1-rc kernels?
>
> Yes, and it was broken there, too. It is possible that 4.0 is broken,
> too, I did not use hibernation for some time.
>
> 3.14 kernel works ok. I'm trying v3.19 now.

I see.

OK, it would be good to narrow down the time frame when it broke.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

Re: [PATCH 2/3] spi: mediatek: Add spi bus for Mediatek MT8173

June 17, 2015, 5:50 am

≫ Next: Re: 4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?

≪ Previous: Re: 4.1-rc7, thinkpad X60: platform mode hibernation does very wrongthing

On Wed, Jun 17, 2015 at 05:08:03PM +0800, Eddie Huang wrote:

> Here comes the problem, although total length of tx, rx is the same,
> each entry in rx and tx scatterlist may not be the same (in the case
> data buffer allocate from vmalloc). Other vendor have dmaengine driver
> to send entry-by-entry automatically, so it is ok due to total length is
> the same.But mediatek hw can only send tx and rx scatterlist entry one
> by on, which means in full duplex, mediatek SPI hardware need send each
> entry separately, will cause full duplex fail because tx/rx entry size
> or entry number may not be the same.

I don't see why this is a problem - your driver is going to have to do
more work to overcome the limitations of the hardware but surely it's
just a question of how you parse the scatterlists (or rewriting them if
that's appropriate)?

> The problem is not dma map discuss earlier, it is mediatek spi hardware
> limitation that can't support scatterlist dma transfer in full-duplex
> mode. We can only support both tx and rx has the same size continuous
> memory data in full-duplex mode. I don't know whether should modify
> spi.c to support mediatek spi, or we just return can_dma() false and do
> transfer one continuous data in transfer function.

> By the way, I think maybe it is better to change can_dma() to
> can_dma_sg().

Don't you just need to handle the scatterlists in page sized chunks
here? There's nothing about passing information about the memory that
was mapped around in a scatterlist that means you have to pass the whole
list to the hardware at once - at heart the scatterlist is just a
convenient structure for passing around where the data to be transferred
is.

↧

Re: 4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?

June 17, 2015, 6:00 am

≫ Next: Re: [RFC -v2] panic_on_oom_timeout

≪ Previous: Re: [PATCH 2/3] spi: mediatek: Add spi bus for Mediatek MT8173

On Wed 2015-06-17 14:43:47, Pavel Machek wrote:
> Hi!
>
> Video is broken on thinkpad T40p after resume from suspend. (In X
> only, text console still works.)
>
> Maybe this is related?
>
> [ 5430.193071] radeon 0000:01:00.0: putting AGP V2 device into 4x mode
> [ 5430.193107] radeon 0000:01:00.0: GTT: 256M 0xD0000000 - 0xDFFFFFFF
> [ 5430.214670] radeon 0000:01:00.0: WB disabled
> [ 5430.214675] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x00000000d0000000 and cpu addr 0xf841a000
> [ 5430.214721] [drm] radeon: ring at 0x00000000D0001000
> [ 5430.370867] [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E8)=0xCAFEDEAD)
> [ 5430.370869] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
> [ 5430.370872] radeon 0000:01:00.0: failed initializing CP (-22).
>
> Hibernation works well here, including X. (Which has small glitch with
> mouse cursor being corrupted until it is changed by application).
>

3.16.0-4-686-pae Debian 3.16.7-cktt11-1 kernel seems to have same
problem, with same scratch(0x15E8)=0xCAFEDEAD message... so this is
not "new" problem...

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

Re: [RFC -v2] panic_on_oom_timeout

June 17, 2015, 6:00 am

≫ Next: [PATCH] sound: hda_intel: fix warning if SND_HDA_I915=n

≪ Previous: Re: 4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?

On Wed 17-06-15 21:31:21, Tetsuo Handa wrote:
> Michal Hocko wrote:
[...]
> > I think we can rely on timers. A downside would be that we cannot dump
> > the full OOM report from the IRQ context because we rely on task_lock
> > which is not IRQ safe. But I do not think we really need it. An OOM
> > report will be in the log already most of the time and show_mem will
> > tell us the current memory situation.
> >
> > What do you think?
>
> We can rely on timers, but we can't rely on global timer.

Why not?

>
> > + if (sysctl_panic_on_oom_timeout) {
> > + if (sysctl_panic_on_oom > 1) {
> > + pr_warn("panic_on_oom_timeout is ignored for panic_on_oom=2\n");
> > + } else {
> > + /*
> > + * Only schedule the delayed panic_on_oom when this is
> > + * the first OOM triggered. oom_lock will protect us
> > + * from races
> > + */
> > + if (atomic_read(&oom_victims))
> > + return;
> > +
> > + mod_timer(&panic_on_oom_timer,
> > + jiffies + (sysctl_panic_on_oom_timeout * HZ));
> > + return;
> > + }
> > + }
>
> Since this version uses global panic_on_oom_timer, you cannot handle
> OOM race like below.
>
> (1) p1 in memcg1 calls out_of_memory().
> (2) 5 seconds of timeout is started by p1.
> (3) p1 takes 3 seconds for some reason.
> (4) p2 in memcg2 calls out_of_memory().
> (5) p1 calls unmark_oom_victim() but timer continues.
> (6) p2 takes 2 seconds for some reason.
> (7) 5 seconds of timeout expires despite individual delay was less than
> 5 seconds.

Yes it is not intended to handle such a race. Timeout is completely
ignored for panic_on_oom=2 and contrained oom context doesn't trigger
this path for panic_on_oom=1.

But you have a point that we could have
- constrained OOM which elevates oom_victims
- global OOM killer strikes but wouldn't start the timer

This is certainly possible and timer_pending(&panic_on_oom) replacing
oom_victims check should help here. I will think about this some more.
But this sounds like a minor detail.

The important thing is to decide what is the reasonable way forward. We
have two two implementations of panic based timeout. So we should decide
- Should be the timeout bound to panic_on_oom?
- Should we care about constrained OOM contexts?
- If yes should they use the same timeout?
- If yes should each memcg be able to define its own timeout?

My thinking is that it should be bound to panic_on_oom=1 only until we
hear from somebody actually asking for a constrained oom and even then
do not allow for too large configuration space (e.g. no per-memcg
timeout) or have separate mempolicy vs. memcg timeouts.

Let's start simple and make things more complicated later!

--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

[PATCH] sound: hda_intel: fix warning if SND_HDA_I915=n

June 17, 2015, 6:00 am

≫ Next: Rate limiting on part of the URL path

≪ Previous: Re: [RFC -v2] panic_on_oom_timeout

When building with CONFIG_SND_HDA_I915=n, I get the following warning:

sound/pci/hda/hda_intel.c: In function ‘azx_probe_continue’:
sound/pci/hda/hda_intel.c:1882:2: warning: label ‘skip_i915’ defined but not used [-Wunused-label]
skip_i915:
^

Fix this by using 'if (IS_ENABLED())' rather than #ifdef.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
sound/pci/hda/hda_intel.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index a244ba706317..d85a53ceab6d 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1856,8 +1856,8 @@ static int azx_probe_continue(struct azx *chip)
int err;

/* Request power well for Haswell HDA controller and codec */
- if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL) {
-#ifdef CONFIG_SND_HDA_I915
+ if (IS_ENABLED(CONFIG_SND_HDA_I915) &&
+ chip->driver_caps & AZX_DCAPS_I915_POWERWELL) {
err = hda_i915_init(hda);
if (err < 0) {
/* if the controller is bound only with HDMI/DP
@@ -1876,7 +1876,6 @@ static int azx_probe_continue(struct azx *chip)
"Cannot turn on display power on i915\n");
goto out_free;
}
-#endif
}

skip_i915:
--
2.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

Rate limiting on part of the URL path

June 17, 2015, 6:10 am

≫ Next: Re: Need help about ACLs settings

≪ Previous: [PATCH] sound: hda_intel: fix warning if SND_HDA_I915=n

Hello,

I'm using haproxy 1.5.12 and I'm trying to do rate limiting based on a part
of a URL requested.

Requests I want to track and limit have the following form:
https://host1.domain.tld/field1/field2/morestuff?query……
- field1 is a word like "user" or "data", there are 2 to 4 of them and
they're known to me.
- field2 is what I really want to track, it's formed of 3 letters that
never change and followed by several characters including lower and upper
case letters, numbers, dashes (-) and underscores (_). The field length is
not fixed however it will always be in second position in the path.
Examples for this field are abc_PT4gWk-42, abc1234 or abc-vb8WQ_2

My goal is have a table storing these with a counter for each, block if we
get more than 10 per second and return an error message like "too many
requests". I'd like to be able to query this table to have an idea of the
abusers, this should be trivial by parsing the output of "show table".

I have not been able to generate a config that does something similar and
am quite confused by the stick store-request which accept path but not
path_reg. Am I actually in the right direction ?

Any help would be greatly appreciated.

Thanks

--
Pierre

↧

Re: Need help about ACLs settings

June 17, 2015, 6:10 am

≫ Next: Re: [PATCH] i2c: mv64xxx: remove unreachable signal case handling

≪ Previous: Rate limiting on part of the URL path

On Fri, 12 Jun 2015 14:46:42 +0200
Thibault Labrut <thibault.labrut@enioka.com> wrote:

> Hi,
>
> Thx for your help.
>
> But now I’ve an other issue.
>
> When we put on a bottom in form, the url is :
> http://foo.domain.com:42/index.htm.
>
> I want rewrite url like this : http://foo.domain.com/index.htm
>
> For this operation, I use the function rspirep in backend (LB)
>
> rspirep ^Location:\ (.*):30200(.*) Location:\ \1\2
>
> But without success.

This configuration seems to be ok. Do you have more context ? A full
configuration file ?

Note that in your example you declares a port 42, and in your example,
the port 30200 is matched.

Thierry

>
> Cordialement,
> --
> Thibault Labrut
> enioka
> 24 galerie Saint-Marc
> 75002 Paris
> +33 615 700 935
> +33 144 618 314
>
> De : Thierry <thi@thierry.1s.fr>
> Date : jeudi 11 juin 2015 17:21
> À : Thibault Labrut <thibault.labrut@enioka.com>
> Cc : "haproxy@formilux.org" <haproxy@formilux.org>
> Objet : Re: Need help about ACLs settings
>
> On Thu, 11 Jun 2015 16:51:14 +0200
> Thibault Labrut <thibault.labrut@enioka.com> wrote:
>
> > Hi Thierry,
> >
> > If I understand your propsition, my settings shourld be like this :
>
>
> You must add "option forwardfor" in the RP frontend.
>
> Thierry
>
>
>
> > > RP settings (no change)
> >
> > # Frontend
> > frontend http_test
> > bind xx.xx.xx.xx:42
> > capture request header Host len 200
> >
> > # ACL
> > acl acl_test src 12.34.56.78 (IP client)
> > use_backend test if acl_test
> >
> > # Backend
> > backend test
> > server srv_ test test.maycompany.local:42 check
> >
> > > LB settings
> > # Frontend
> > frontend http_test
> > bind xx.xx.xx.xx:42
> > capture request header Host len 200
> >
> > # ACL (new acl setting)
> > acl acl_test fhdr(x-forwarded-for) -m ipv4 12.34.56.78
> > use_backend test if acl_test
> >
> > # Backend
> > backend test
> > balance roundrobin
> > server test01 xx.xx.xx.xx:42 check
> > server test02 xx.xx.xx.xx:42 check
> >
> > Thibault Labrut.
> >
> > De : Thierry FOURNIER <tfournier@haproxy.com>
> > Date : jeudi 11 juin 2015 11:56
> > À : Thibault Labrut <t.labrut@pickup-services.com>
> > Cc : "haproxy@formilux.org" <haproxy@formilux.org>
> > Objet : Re: Need help about ACLs settings
> >
> > On Thu, 11 Jun 2015 09:06:43 +0000
> > Thibault LABRUT <t.labrut@pickup-services.com> wrote:
> >
> >> > Hello,
> >> >
> >> > I¹m going to install HA Proxy.
> >> >
> >> > My architecture is as folows :
> >> > - 2 servers in DMZ => reverse proxy (RP)
> >> > - 2 servers in LAN => Load balancing (LB)
> >> >
> >> > Several applications contact RP with different IP adress but with always
> de
> >> > same port.
> >> >
> >> > With the settings as below the connection is up :
> >> >
> >> > RP settings
> >> >
> >> > # Frontend
> >> > frontend http_test
> >> > bind xx.xx.xx.xx:42
> >> > capture request header Host len 200
> >> > default_backend test
> >> >
> >> > # Backend
> >> > backend test
> >> > server srv_ test test.maycompany.local:42 check
> >> >
> >> > LB settings
> >> >
> >> > # Frontend
> >> > frontend http_test
> >> > bind xx.xx.xx.xx:42
> >> > capture request header Host len 200
> >> > default_backend test
> >> >
> >> > # Backend
> >> > backend test
> >> > balance roundrobin
> >> > server test01 xx.xx.xx.xx:42 check
> >> > server test02 xx.xx.xx.xx:42 check
> >> >
> >> > But in this case the connection is down :
> >> >
> >> > # Frontend
> >> > frontend http_test
> >> > bind xx.xx.xx.xx:42
> >> > capture request header Host len 200
> >> >
> >> > # ACL
> >> > acl acl_test src 12.34.56.78 (IP client)
> >> > use_backend test if acl_test
> >> >
> >> > # Backend
> >> > backend test
> >> > server srv_ test test.maycompany.local:42 check
> >> >
> >> > LB settings
> >> >
> >> > # Frontend
> >> > frontend http_test
> >> > bind xx.xx.xx.xx:42
> >> > capture request header Host len 200
> >> >
> >> > # ACL
> >> > acl acl_test src 12.34.56.78
> >> > use_backend test if acl_test
> >> >
> >> > # Backend
> >> > backend test
> >> > balance roundrobin
> >> > server test01 xx.xx.xx.xx:42 check
> >> > server test02 xx.xx.xx.xx:42 check
> >> >
> >> > Can you say me what is the problem with my settings?
> >> >
> >
> >
> > Hi,
> >
> > If I understand, you have two HAProxy chained, RP is in front and LB is
> > in back.
> >
> > In this case, the connexions received by the LB load balancer cannot
> > known the original IP source, because the connexions are established by
> > the LB load balancer with its own IP.
> >
> > You can use the header "x-forwarded-for" for string the original ip
> > source. The directive is "option forwardfor". On the LB HAProxy, you
> > can use a sample taht returns the content of the header
> > x-forwarded-for, like this:
> >
> > acl acl_test fhdr(x-forwarded-for) -m ipv4 12.34.56.78
> >
> > best regards
> > Thierry
> >
> >
> >> > Best Regards,
> >> >
> >> > Thibault Labrut.
> >
> >
> >
>
>
>

--
Thierry FOURNIER <thierry.fournier@arpalert.org>

↧

Re: [PATCH] i2c: mv64xxx: remove unreachable signal case handling

June 17, 2015, 6:10 am

≫ Next: Re: [PATCH v4 1/6] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

≪ Previous: Re: Need help about ACLs settings

On Thu, Jun 11, 2015 at 05:27:33PM +0200, Nicholas Mc Guire wrote:
> 'commit d295a86eab20 ("i2c: mv64xxx: work around signals causing I2C
> transactions to be aborted")' removed the wait_event_interruptible_timeout
> to prevent half/mixed i2c messages from being sent/received but forgot to
> drop the signal received cases in the return handling. This just removes
> this dead code and simplifies the error message as "time_left" only can be
> 0 here and thus it conveys no additional information.
>
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> ---
>
> Patch was compile tested with multi_v7_defconfig
> (implies CONFIG_I2C_MV64XXX=y)
>
> Patch is against 4.1-rc7 (localversion-next is -next-20150611)

Hmm, IMO this patch is too intrusive to be applied without actual
testing.

>
> drivers/i2c/busses/i2c-mv64xxx.c | 15 +++------------
> 1 file changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
> index 30059c1..a4f8ece 100644
> --- a/drivers/i2c/busses/i2c-mv64xxx.c
> +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> @@ -534,7 +534,6 @@ mv64xxx_i2c_wait_for_completion(struct mv64xxx_i2c_data *drv_data)
> {
> long time_left;
> unsigned long flags;
> - char abort = 0;
>
> time_left = wait_event_timeout(drv_data->waitq,
> !drv_data->block, drv_data->adapter.timeout);
> @@ -542,25 +541,17 @@ mv64xxx_i2c_wait_for_completion(struct mv64xxx_i2c_data *drv_data)
> spin_lock_irqsave(&drv_data->lock, flags);
> if (!time_left) { /* Timed out */
> drv_data->rc = -ETIMEDOUT;
> - abort = 1;
> - } else if (time_left < 0) { /* Interrupted/Error */
> - drv_data->rc = time_left; /* errno value */
> - abort = 1;
> - }
> -
> - if (abort && drv_data->block) {
> drv_data->aborting = 1;
> spin_unlock_irqrestore(&drv_data->lock, flags);
>
> time_left = wait_event_timeout(drv_data->waitq,
> !drv_data->block, drv_data->adapter.timeout);
>
> - if ((time_left <= 0) && drv_data->block) {

I am especially unsure about the drv_data->block removal. Did you double
check if we can do this?

> + if (time_left == 0) {
> drv_data->state = MV64XXX_I2C_STATE_IDLE;
> dev_err(&drv_data->adapter.dev,
> - "mv64xxx: I2C bus locked, block: %d, "
> - "time_left: %d\n", drv_data->block,
> - (int)time_left);
> + "mv64xxx: I2C bus locked, block: %d\n",
> + drv_data->block);

And if so, shouldn't that also be always 1 in the output here?

> mv64xxx_i2c_hw_init(drv_data);
> }
> } else

Maybe (not sure) it also helps to split the patch into everything
dealing with time_left as patch 1) and simplifying by drv_data->block
removal as patch2?

Thanks,

Wolfram

↧

Re: [PATCH v4 1/6] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

June 17, 2015, 6:10 am

≫ Next: Re: [Resend PATCH v8 0/4] sched: Rewrite runnable load and utilization average tracking

≪ Previous: Re: [PATCH] i2c: mv64xxx: remove unreachable signal case handling

On 2015-06-09 22:07, Sebastian Andrzej Siewior wrote:
> On 2015-06-03 17:05:16 [+0200], Stefan Agner wrote:
>> As Boris guessed correctly, the reason I used the raw variant was due to
>> performance improvements due to the barrier. However, I will use
>
> yeah, do you have any numbers by chance?
>

Just reevaluated the "performance optimizations". On a VF610 SoC (with
L2 cache) the improvements increase performance by 2.5% and below. On a
VF500 SoC (without L2 cache) it seems to have slightly more impact, up
to 4%. Overall, it seems to influence write more than read.

Back then, when I implemented the improvements it certainly had a bigger
impact. I don't have strong opinion on that...

=> VF610, with relaxed, optimized
[ 45.554246]
[ 45.555934] =================================================
[ 45.561762] mtd_speedtest: MTD device: 3
[ 45.576627] mtd_speedtest: MTD device size 104857600, eraseblock size
131072, page size 2048, count of eraseblocks 800, pages per eraseblock
64, OOB size 64
[ 45.595350] mtd_test: scanning for bad eraseblocks
[ 45.602177] mtd_test: scanned 800 eraseblocks, 0 are bad
[ 46.404682] mtd_speedtest: testing eraseblock write speed
[ 65.650704] mtd_speedtest: eraseblock write speed is 5344 KiB/s
[ 65.656738] mtd_speedtest: testing eraseblock read speed
[ 73.480687] mtd_speedtest: eraseblock read speed is 13118 KiB/s
[ 74.264593] mtd_speedtest: testing page write speed
[ 94.444190] mtd_speedtest: page write speed is 5087 KiB/s
[ 94.449674] mtd_speedtest: testing page read speed
[ 102.760387] mtd_speedtest: page read speed is 12343 KiB/s
[ 103.544838] mtd_speedtest: testing 2 page write speed
[ 123.257753] mtd_speedtest: 2 page write speed is 5199 KiB/s
[ 123.263440] mtd_speedtest: testing 2 page read speed
[ 131.171313] mtd_speedtest: 2 page read speed is 12963 KiB/s
[ 131.176981] mtd_speedtest: Testing erase speed
[ 131.968196] mtd_speedtest: erase speed is 130279 KiB/s
[ 131.973442] mtd_speedtest: Testing 2x multi-block erase speed
[ 132.153410] mtd_speedtest: 2x multi-block erase speed is 585142 KiB/s
[ 132.159924] mtd_speedtest: Testing 4x multi-block erase speed
[ 132.334864] mtd_speedtest: 4x multi-block erase speed is 609523 KiB/s
[ 132.341369] mtd_speedtest: Testing 8x multi-block erase speed
[ 132.516091] mtd_speedtest: 8x multi-block erase speed is 609523 KiB/s
[ 132.522602] mtd_speedtest: Testing 16x multi-block erase speed
[ 132.695800] mtd_speedtest: 16x multi-block erase speed is 613173
KiB/s
[ 132.702389] mtd_speedtest: Testing 32x multi-block erase speed
[ 132.874831] mtd_speedtest: 32x multi-block erase speed is 616867
KiB/s
[ 132.881445] mtd_speedtest: Testing 64x multi-block erase speed
[ 133.053647] mtd_speedtest: 64x multi-block erase speed is 616867
KiB/s
[ 133.060267] mtd_speedtest: finished
[ 133.063812] =================================================

=> VF610, without relaxed and using accessors
vf610_nfc_set/vf610_nfc_set_field and friends:
[ 60.015797]
[ 60.017481] =================================================
[ 60.023320] mtd_speedtest: MTD device: 3
[ 60.037232] mtd_speedtest: MTD device size 104857600, eraseblock size
131072, page size 2048, count of eraseblocks 800, pages per eraseblock
64, OOB size 64
[ 60.066359] mtd_test: scanning for bad eraseblocks
[ 60.074016] mtd_test: scanned 800 eraseblocks, 0 are bad
[ 60.286730] mtd_speedtest: testing eraseblock write speed
[ 79.679892] mtd_speedtest: eraseblock write speed is 5281 KiB/s
[ 79.685930] mtd_speedtest: testing eraseblock read speed
[ 87.563845] mtd_speedtest: eraseblock read speed is 13008 KiB/s
[ 88.353390] mtd_speedtest: testing page write speed
[ 108.984528] mtd_speedtest: page write speed is 4965 KiB/s
[ 108.990041] mtd_speedtest: testing page read speed
[ 117.012486] mtd_speedtest: page read speed is 12774 KiB/s
[ 117.801663] mtd_speedtest: testing 2 page write speed
[ 137.674009] mtd_speedtest: 2 page write speed is 5154 KiB/s
[ 137.679696] mtd_speedtest: testing 2 page read speed
[ 145.643303] mtd_speedtest: 2 page read speed is 12865 KiB/s
[ 145.648982] mtd_speedtest: Testing erase speed
[ 146.444423] mtd_speedtest: erase speed is 129456 KiB/s
[ 146.449669] mtd_speedtest: Testing 2x multi-block erase speed
[ 146.629634] mtd_speedtest: 2x multi-block erase speed is 588505 KiB/s
[ 146.636142] mtd_speedtest: Testing 4x multi-block erase speed
[ 146.813027] mtd_speedtest: 4x multi-block erase speed is 598830 KiB/s
[ 146.819577] mtd_speedtest: Testing 8x multi-block erase speed
[ 146.996654] mtd_speedtest: 8x multi-block erase speed is 595348 KiB/s
[ 147.003192] mtd_speedtest: Testing 16x multi-block erase speed
[ 147.178085] mtd_speedtest: 16x multi-block erase speed is 609523
KiB/s
[ 147.184703] mtd_speedtest: Testing 32x multi-block erase speed
[ 147.358306] mtd_speedtest: 32x multi-block erase speed is 613173
KiB/s
[ 147.364929] mtd_speedtest: Testing 64x multi-block erase speed
[ 147.540505] mtd_speedtest: 64x multi-block erase speed is 605917
KiB/s
[ 147.547106] mtd_speedtest: finished
[ 147.558336] =================================================

=> VF500, with relaxed, optimized
[ 42.878713]
[ 42.880775] =================================================
[ 42.886589] mtd_speedtest: MTD device: 3
[ 42.933491] mtd_speedtest: MTD device size 132120576, eraseblock size
131072, page size 2048, count of eraseblocks 1008, pages per eraseblock
64, OOB size 64
[ 42.981413] mtd_test: scanning for bad eraseblocks
[ 42.987505] mtd_test: block 142 is bad
[ 43.001342] mtd_test: block 1004 is bad
[ 43.024184] mtd_test: block 1005 is bad
[ 43.029184] mtd_test: block 1006 is bad
[ 43.045070] mtd_test: block 1007 is bad
[ 43.048975] mtd_test: scanned 1008 eraseblocks, 5 are bad
[ 43.854654] mtd_speedtest: testing eraseblock write speed
[ 68.873797] mtd_speedtest: eraseblock write speed is 5150 KiB/s
[ 68.879915] mtd_speedtest: testing eraseblock read speed
[ 80.409787] mtd_speedtest: eraseblock read speed is 11171 KiB/s
[ 81.053244] mtd_speedtest: testing page write speed
[ 109.851897] mtd_speedtest: page write speed is 4462 KiB/s
[ 109.857496] mtd_speedtest: testing page read speed
[ 121.964415] mtd_speedtest: page read speed is 10616 KiB/s
[ 122.603068] mtd_speedtest: testing 2 page write speed
[ 148.929905] mtd_speedtest: 2 page write speed is 4880 KiB/s
[ 148.935696] mtd_speedtest: testing 2 page read speed
[ 160.908554] mtd_speedtest: 2 page read speed is 10731 KiB/s
[ 160.914236] mtd_speedtest: Testing erase speed
[ 161.579429] mtd_speedtest: erase speed is 194226 KiB/s
[ 161.584680] mtd_speedtest: Testing 2x multi-block erase speed
[ 162.226599] mtd_speedtest: 2x multi-block erase speed is 201861 KiB/s
[ 162.233153] mtd_speedtest: Testing 4x multi-block erase speed
[ 162.870923] mtd_speedtest: 4x multi-block erase speed is 202818 KiB/s
[ 162.877591] mtd_speedtest: Testing 8x multi-block erase speed
[ 163.503176] mtd_speedtest: 8x multi-block erase speed is 207070 KiB/s
[ 163.509826] mtd_speedtest: Testing 16x multi-block erase speed
[ 164.138392] mtd_speedtest: 16x multi-block erase speed is 206405
KiB/s
[ 164.145128] mtd_speedtest: Testing 32x multi-block erase speed
[ 164.768705] mtd_speedtest: 32x multi-block erase speed is 207741
KiB/s
[ 164.775475] mtd_speedtest: Testing 64x multi-block erase speed
[ 165.394716] mtd_speedtest: 64x multi-block erase speed is 209094
KiB/s
[ 165.401347] mtd_speedtest: finished
[ 165.415581] =================================================

=> VF500, without relaxed and using accessors
[ 93.466642]
[ 93.468578] =================================================
[ 93.474563] mtd_speedtest: MTD device: 3
[ 93.510699] mtd_speedtest: MTD device size 132120576, eraseblock size
131072, page size 2048, count of eraseblocks 1008, pages per eraseblock
64, OOB size 64
[ 93.534490] mtd_test: scanning for bad eraseblocks
[ 93.553066] mtd_test: block 142 is bad
[ 93.586518] mtd_test: block 1004 is bad
[ 93.590559] mtd_test: block 1005 is bad
[ 93.595654] mtd_test: block 1006 is bad
[ 93.607090] mtd_test: block 1007 is bad
[ 93.630667] mtd_test: scanned 1008 eraseblocks, 5 are bad
[ 94.457510] mtd_speedtest: testing eraseblock write speed
[ 120.495695] mtd_speedtest: eraseblock write speed is 4932 KiB/s
[ 120.501726] mtd_speedtest: testing eraseblock read speed
[ 131.937006] mtd_speedtest: eraseblock read speed is 11233 KiB/s
[ 132.576468] mtd_speedtest: testing page write speed
[ 160.663012] mtd_speedtest: page write speed is 4572 KiB/s
[ 160.668608] mtd_speedtest: testing page read speed
[ 172.624020] mtd_speedtest: page read speed is 10743 KiB/s
[ 173.263221] mtd_speedtest: testing 2 page write speed
[ 199.811255] mtd_speedtest: 2 page write speed is 4837 KiB/s
[ 199.816933] mtd_speedtest: testing 2 page read speed
[ 211.558975] mtd_speedtest: 2 page read speed is 10939 KiB/s
[ 211.564657] mtd_speedtest: Testing erase speed
[ 212.227608] mtd_speedtest: erase speed is 194816 KiB/s
[ 212.232951] mtd_speedtest: Testing 2x multi-block erase speed
[ 212.875607] mtd_speedtest: 2x multi-block erase speed is 201544 KiB/s
[ 212.882254] mtd_speedtest: Testing 4x multi-block erase speed
[ 213.521870] mtd_speedtest: 4x multi-block erase speed is 202818 KiB/s
[ 213.528471] mtd_speedtest: Testing 8x multi-block erase speed
[ 214.154043] mtd_speedtest: 8x multi-block erase speed is 207070 KiB/s
[ 214.160690] mtd_speedtest: Testing 16x multi-block erase speed
[ 214.785910] mtd_speedtest: 16x multi-block erase speed is 207405
KiB/s
[ 214.792652] mtd_speedtest: Testing 32x multi-block erase speed
[ 215.418150] mtd_speedtest: 32x multi-block erase speed is 207405
KiB/s
[ 215.424883] mtd_speedtest: Testing 64x multi-block erase speed
[ 216.051367] mtd_speedtest: 64x multi-block erase speed is 206737
KiB/s
[ 216.058056] mtd_speedtest: finished
[ 216.069363] =================================================

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

Re: [Resend PATCH v8 0/4] sched: Rewrite runnable load and utilization average tracking

June 17, 2015, 6:10 am

≫ Next: Re: 4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?

≪ Previous: Re: [PATCH v4 1/6] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

Hi Yuyang,

On Wed, Jun 17, 2015 at 11:11:01AM +0800, Yuyang Du wrote:
> Hi,
>
> The sched_debug is informative, lets first give it some analysis.
>
> The workload is 12 CPU hogging tasks (always runnable) and 1 dbench
> task doing fs ops (70% runnable) running at the same time.
>
> Actually, these 13 tasks are in a task group /autogroup-9617, which
> has weight 1024.
>
> So the 13 tasks at most can contribute to an average of 79 (=1024/13)
>

[snip]

> So the problem is:
>
> 1) The tasks in the workload have too small weight (only 79), because
> they share a task group.
>
> 2) Probably some "high" weight task even runnable a small time
> contribute "big" to cfs_rq's load_avg.

Thank you for your analysis.

Some updates:

I created a task group /g and set /g/cpu.shares to 13312 (1024 * 13),
and then ran `stress --cpu 12` and `dbench 1` simultaneously in that
group. The situation is much better, only one CPU is not fully loaded,
and its utilization rate stays around 85%.

Regards,
Boqun

↧

Re: 4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?

June 17, 2015, 6:10 am

≫ Next: Re: [alsa-devel][PATCH v2] ASoC: wm8960: add dapm kcontrols to select left/right ADC input source

≪ Previous: Re: [Resend PATCH v8 0/4] sched: Rewrite runnable load and utilization average tracking

On 17.06.2015 14:49, Pavel Machek wrote:
> On Wed 2015-06-17 14:43:47, Pavel Machek wrote:
>> Hi!
>>
>> Video is broken on thinkpad T40p after resume from suspend. (In X
>> only, text console still works.)
>>
>> Maybe this is related?
>>
>> [ 5430.193071] radeon 0000:01:00.0: putting AGP V2 device into 4x mode
>> [ 5430.193107] radeon 0000:01:00.0: GTT: 256M 0xD0000000 - 0xDFFFFFFF
>> [ 5430.214670] radeon 0000:01:00.0: WB disabled
>> [ 5430.214675] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x00000000d0000000 and cpu addr 0xf841a000
>> [ 5430.214721] [drm] radeon: ring at 0x00000000D0001000
>> [ 5430.370867] [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E8)=0xCAFEDEAD)
>> [ 5430.370869] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
>> [ 5430.370872] radeon 0000:01:00.0: failed initializing CP (-22).
>>
>> Hibernation works well here, including X. (Which has small glitch with
>> mouse cursor being corrupted until it is changed by application).
>>
> 3.16.0-4-686-pae Debian 3.16.7-cktt11-1 kernel seems to have same
> problem, with same scratch(0x15E8)=0xCAFEDEAD message... so this is
> not "new" problem...
>
> Pavel
Looks like CP init doesn't work. Well is there any kernel where that did
worked?

If yes it might be a good idea to bisect to narrow down the problem.

Regards,
Christian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

Re: [alsa-devel][PATCH v2] ASoC: wm8960: add dapm kcontrols to select left/right ADC input source

June 17, 2015, 6:10 am

≫ Next: [PATCH 2/2] i2c-parport: start using pr_fmt

≪ Previous: Re: 4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?

On Wed, Jun 17, 2015 at 04:58:30PM +0800, Zidan Wang wrote:
> On Tue, Jun 16, 2015 at 01:18:39PM +0100, Charles Keepax wrote:
> > On Tue, Jun 16, 2015 at 02:23:19PM +0800, Zidan Wang wrote:
> > > Add dapm kcontrols to select left/right ADC input source, one to select
> > > the left ADC input source and one for the right ADC input source.
> > >
> > > In default, the left ADC will select the left input, and the right ADC will
> > > select the right input. When the left(right) ADC select the right(left) input,
> > > the left(right) input path will be powered down.
> > >
> > > Signed-off-by: Zidan Wang <zidan.wang@freescale.com>
> > > ---
> > > - { "Left ADC", NULL, "Left Input Mixer" },
> > > - { "Right ADC", NULL, "Right Input Mixer" },
> > > + { "ADCL Source", "Left", "Left Input Mixer" },
> > > + { "ADCL Source", "Right", "Right Input Mixer" },
> > > +
> > > + { "ADCR Source", "Left", "Left Input Mixer" },
> > > + { "ADCR Source", "Right", "Right Input Mixer" },
> > > +
> > > + { "Left ADC", NULL, "ADCL Source" },
> > > + { "Right ADC", NULL, "ADCR Source" },
> >
> > Are you sure this is correct? My reading is that those bits don't
> > affect routing at all, they mearly determine how the channel is
> > sent out on the AIF.
> >
> I have tested on my board, it can works, but it has something wrong.
>
> If set "ADCR Source" to "Left", RINPUT1(RINPUT2 and RINPUT3)->"Right Input Mixer" will
> be powered down, but "Right ADC" is still powered up. Do you have some best method to
> set the audio route?

I think your last patch that didn't touch DAPM for this was
closer to correct, I would revert back to something similar to
that but fixing up for the other comments on it.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

↧

Latest Images