Re: [PATCH] powerpc: Remove platforms/wsp and associated pieces
On Thu, 2014-05-29 at 19:32 +1000, Stephen Rothwell wrote: Hi Michael, On Thu, 29 May 2014 18:50:29 +1000 Michael Ellerman m...@ellerman.id.au wrote: __attribute__ ((unused)) Signed-off-by: Michael Ellerman m...@ellerman.id.au So this was the only use of CONFIG_PPC_A2 ... so more cleanup possible :-) I always appreciate negative work :-) Hmm, yeah, well spotted. I'll send another patch. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Remove platforms/wsp and associated pieces
On Thu, 2014-05-29 at 19:39 +1000, Stephen Rothwell wrote: Hi Michael, On Thu, 29 May 2014 19:32:52 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: On Thu, 29 May 2014 18:50:29 +1000 Michael Ellerman m...@ellerman.id.au wrote: __attribute__ ((unused)) Signed-off-by: Michael Ellerman m...@ellerman.id.au So this was the only use of CONFIG_PPC_A2 ... so more cleanup possible :-) And also seems to be the only thing that selects CONFIG_PPC_ICSWX. However, this is user selectable ... Yeah, that in theory works on Power7. I'm not sure it ever got used though. Will have to think about it a bit more. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
P1022 audio driver help!
@timur hi, Audio card (wm8776) cannot work in full duplex, CPU is FSL P1022. The PCB design about audio card reference FSL P1022 development board, and palying or recording is OK separately. My question is whether P1022 audio driver cannot support full duplex? The following is my test method. test script: #!/bin/sh echo start plarying aplay /nor-disk/audiosrv/Success.wav sleep 1 echo start recording arecord -d 5 -t wav -D plug:SLAVE='hw:0,1' -r 19886 test.wav when start record, aplay just suspend, and I cannot listen voice. when record is over, I found aplay still suspend. according to ps -aux: root 1499 0.2 0.1 4012 1500 pts/0 S 08:25 0:00 aplay /nor-disk/audiosrv/Success.wav But, I run this script in a PC linux, I can listen the voice, the audio card can record my voice simultaneous. Looking forward your response! Thanks! B.R. YXS___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/pseries: Use new defines when calling h_set_mode
On 29.05.14 23:52, Benjamin Herrenschmidt wrote: On Thu, 2014-05-29 at 23:27 +0200, Alexander Graf wrote: On 29.05.14 09:45, Michael Neuling wrote: +/* Values for 2nd argument to H_SET_MODE */ +#define H_SET_MODE_RESOURCE_SET_CIABR1 +#define H_SET_MODE_RESOURCE_SET_DAWR2 +#define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE3 +#define H_SET_MODE_RESOURCE_LE4 Much better, but I think you want to make use of these in non-kvm code too, no? At least the LE one is definitely already implemented as call :) Sure but that's a different patch below. Ben, how would you like to handle these 2 patches? If you give me an ack I can just put this patch into my kvm queue. Alternatively we could both carry a patch that adds the H_SET_MODE header bits only and whoever hits Linus' tree first wins ;). No biggie. Worst case it's a trivial conflict. Well, the way the patches are split right now it won't be a conflict, but a build failure on either side. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] powerpc/e6500: hw tablewalk: fix recursive tlb lock on cpu 0
-Original Message- From: Linuxppc-dev [mailto:linuxppc-dev- bounces+mihai.caraman=freescale@lists.ozlabs.org] On Behalf Of Scott Wood Sent: Friday, May 23, 2014 12:45 AM To: linuxppc-dev@lists.ozlabs.org Cc: Wood Scott-B07421 Subject: [PATCH 2/2] powerpc/e6500: hw tablewalk: fix recursive tlb lock on cpu 0 Commit 82d86de25b9c99db546e17c6f7ebf9a691da557e TLB lock recursive introduced a bug whereby cpu 0 uses the same value for lock held as is used to indicate that the lock is free. Isn't his what spin lock implementation solves by combines paca_index with lock_token? Can't we have a common approach? Add one to the CPU value to ensure we do not use zero as a lock held value. The CPU value is loaded in r10 from tlb_miss_common_e6500. TLB lock recursive commit also introduced this misleading comment: We are entered with: r10 = cpu number -Mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/pseries: Use new defines when calling h_set_mode
On Thu, 2014-05-29 at 17:45 +1000, Michael Neuling wrote:
+/* Values for 2nd argument to H_SET_MODE */
+#define H_SET_MODE_RESOURCE_SET_CIABR1
+#define H_SET_MODE_RESOURCE_SET_DAWR2
+#define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE3
+#define H_SET_MODE_RESOURCE_LE4
Much better, but I think you want to make use of these in non-kvm code too,
no? At least the LE one is definitely already implemented as call :)
powerpc/pseries: Use new defines when calling h_set_mode
Now that we define these in the KVM code, use these defines when we call
h_set_mode. No functional change.
Signed-off-by: Michael Neuling mi...@neuling.org
--
This depends on the KVM h_set_mode patches.
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h
b/arch/powerpc/include/asm/plpar_wrappers.h
index 12c32c5..67859ed 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -273,7 +273,7 @@ static inline long plpar_set_mode(unsigned long mflags,
unsigned long resource,
static inline long enable_reloc_on_exceptions(void)
{
/* mflags = 3: Exceptions at 0xC0004000 */
- return plpar_set_mode(3, 3, 0, 0);
+ return plpar_set_mode(3, H_SET_MODE_RESOURCE_ADDR_TRANS_MODE, 0, 0);
}
Which header are these coming from, and why aren't we including it? And is it
going to still build with CONFIG_KVM=n?
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/pseries: Use new defines when calling h_set_mode
On Fri, 2014-05-30 at 18:56 +1000, Michael Ellerman wrote:
On Thu, 2014-05-29 at 17:45 +1000, Michael Neuling wrote:
+/* Values for 2nd argument to H_SET_MODE */
+#define H_SET_MODE_RESOURCE_SET_CIABR1
+#define H_SET_MODE_RESOURCE_SET_DAWR2
+#define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE3
+#define H_SET_MODE_RESOURCE_LE4
Much better, but I think you want to make use of these in non-kvm code
too,
no? At least the LE one is definitely already implemented as call :)
powerpc/pseries: Use new defines when calling h_set_mode
Now that we define these in the KVM code, use these defines when we call
h_set_mode. No functional change.
Signed-off-by: Michael Neuling mi...@neuling.org
--
This depends on the KVM h_set_mode patches.
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h
b/arch/powerpc/include/asm/plpar_wrappers.h
index 12c32c5..67859ed 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -273,7 +273,7 @@ static inline long plpar_set_mode(unsigned long mflags,
unsigned long resource,
static inline long enable_reloc_on_exceptions(void)
{
/* mflags = 3: Exceptions at 0xC0004000 */
- return plpar_set_mode(3, 3, 0, 0);
+ return plpar_set_mode(3, H_SET_MODE_RESOURCE_ADDR_TRANS_MODE, 0, 0);
}
Which header are these coming from, and why aren't we including it? And is it
going to still build with CONFIG_KVM=n?
From include/asm/hvcall.h in the h_set_mode patch set I sent before.
And yes it compiles with CONFIG_KVM=n fine.
Mikey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/pseries: Use new defines when calling h_set_mode
On 30.05.14 11:10, Michael Neuling wrote:
On Fri, 2014-05-30 at 18:56 +1000, Michael Ellerman wrote:
On Thu, 2014-05-29 at 17:45 +1000, Michael Neuling wrote:
+/* Values for 2nd argument to H_SET_MODE */
+#define H_SET_MODE_RESOURCE_SET_CIABR1
+#define H_SET_MODE_RESOURCE_SET_DAWR2
+#define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE3
+#define H_SET_MODE_RESOURCE_LE4
Much better, but I think you want to make use of these in non-kvm code too,
no? At least the LE one is definitely already implemented as call :)
powerpc/pseries: Use new defines when calling h_set_mode
Now that we define these in the KVM code, use these defines when we call
h_set_mode. No functional change.
Signed-off-by: Michael Neuling mi...@neuling.org
--
This depends on the KVM h_set_mode patches.
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h
b/arch/powerpc/include/asm/plpar_wrappers.h
index 12c32c5..67859ed 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -273,7 +273,7 @@ static inline long plpar_set_mode(unsigned long mflags,
unsigned long resource,
static inline long enable_reloc_on_exceptions(void)
{
/* mflags = 3: Exceptions at 0xC0004000 */
- return plpar_set_mode(3, 3, 0, 0);
+ return plpar_set_mode(3, H_SET_MODE_RESOURCE_ADDR_TRANS_MODE, 0, 0);
}
Which header are these coming from, and why aren't we including it? And is it
going to still build with CONFIG_KVM=n?
From include/asm/hvcall.h in the h_set_mode patch set I sent before.
And yes it compiles with CONFIG_KVM=n fine.
Please split that patch into one that adds the definitions and one that
changes the KVM code to use those definitions. Both Ben and me can then
apply the definition patch and our respective tree patch.
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/pseries: Use new defines when calling h_set_mode
On 30.05.14 11:44, Michael Neuling wrote: Which header are these coming from, and why aren't we including it? And is it going to still build with CONFIG_KVM=n? From include/asm/hvcall.h in the h_set_mode patch set I sent before. And yes it compiles with CONFIG_KVM=n fine. Please split that patch into one that adds the definitions and one that changes the KVM code to use those definitions. Both Ben and me can then apply the definition patch and our respective tree patch. Why don't you just take the original h_set_mode patch and I'll repost this cleanup later to ben when yours is upstream. This cleanup patch is not critical to anything and it avoid more churn. That works too, but please keep in mind that my path to upstream is much longer than what you're used to ;). Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/pseries: Use new defines when calling h_set_mode
Which header are these coming from, and why aren't we including it? And is it going to still build with CONFIG_KVM=n? From include/asm/hvcall.h in the h_set_mode patch set I sent before. And yes it compiles with CONFIG_KVM=n fine. Please split that patch into one that adds the definitions and one that changes the KVM code to use those definitions. Both Ben and me can then apply the definition patch and our respective tree patch. Why don't you just take the original h_set_mode patch and I'll repost this cleanup later to ben when yours is upstream. This cleanup patch is not critical to anything and it avoid more churn. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2] backlight: remove trivial get_brightness implementations
This patchset makes get_brightness callback optional and removes trivial implementations. Driver changes are quite obvious so I have put them into single patch. The patchset is based on the current linux-next branch. Regards Andrzej Andrzej Hajda (2): backlight: show brightness even if get_brightness is not implemented backlight: remove trivial get_brightness implementations drivers/macintosh/via-pmu-backlight.c | 6 -- drivers/platform/x86/samsung-q10.c | 6 -- drivers/video/backlight/aat2870_bl.c | 6 -- drivers/video/backlight/ams369fg06.c | 6 -- drivers/video/backlight/backlight.c| 2 ++ drivers/video/backlight/bd6107.c | 6 -- drivers/video/backlight/gpio_backlight.c | 6 -- drivers/video/backlight/ld9040.c | 6 -- drivers/video/backlight/lp855x_bl.c| 6 -- drivers/video/backlight/lp8788_bl.c| 6 -- drivers/video/backlight/lv5207lp.c | 6 -- drivers/video/backlight/pandora_bl.c | 6 -- drivers/video/backlight/pwm_bl.c | 6 -- drivers/video/backlight/s6e63m0.c | 6 -- drivers/video/backlight/tps65217_bl.c | 6 -- drivers/video/fbdev/aty/aty128fb.c | 6 -- drivers/video/fbdev/aty/atyfb_base.c | 6 -- drivers/video/fbdev/aty/radeon_backlight.c | 6 -- drivers/video/fbdev/exynos/s6e8ax0.c | 6 -- drivers/video/fbdev/nvidia/nv_backlight.c | 6 -- drivers/video/fbdev/riva/fbdev.c | 6 -- 21 files changed, 2 insertions(+), 120 deletions(-) -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] backlight: show brightness even if get_brightness is not implemented
Many implementations of get_brightness operation returns only value of props.brightness field. This change makes such implementations unnecessary. Signed-off-by: Andrzej Hajda a.ha...@samsung.com --- drivers/video/backlight/backlight.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c index 19b170d..0ce8823 100644 --- a/drivers/video/backlight/backlight.c +++ b/drivers/video/backlight/backlight.c @@ -221,6 +221,8 @@ static ssize_t actual_brightness_show(struct device *dev, mutex_lock(bd-ops_lock); if (bd-ops bd-ops-get_brightness) rc = sprintf(buf, %d\n, bd-ops-get_brightness(bd)); + else + rc = sprintf(buf, %d\n, bd-props.brightness); mutex_unlock(bd-ops_lock); return rc; -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] backlight: remove trivial get_brightness implementations
Since backlight core returns props.brightness in case get_brightness
is not implemented trivial implementations are not needed anymore.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/macintosh/via-pmu-backlight.c | 6 --
drivers/platform/x86/samsung-q10.c | 6 --
drivers/video/backlight/aat2870_bl.c | 6 --
drivers/video/backlight/ams369fg06.c | 6 --
drivers/video/backlight/bd6107.c | 6 --
drivers/video/backlight/gpio_backlight.c | 6 --
drivers/video/backlight/ld9040.c | 6 --
drivers/video/backlight/lp855x_bl.c| 6 --
drivers/video/backlight/lp8788_bl.c| 6 --
drivers/video/backlight/lv5207lp.c | 6 --
drivers/video/backlight/pandora_bl.c | 6 --
drivers/video/backlight/pwm_bl.c | 6 --
drivers/video/backlight/s6e63m0.c | 6 --
drivers/video/backlight/tps65217_bl.c | 6 --
drivers/video/fbdev/aty/aty128fb.c | 6 --
drivers/video/fbdev/aty/atyfb_base.c | 6 --
drivers/video/fbdev/aty/radeon_backlight.c | 6 --
drivers/video/fbdev/exynos/s6e8ax0.c | 6 --
drivers/video/fbdev/nvidia/nv_backlight.c | 6 --
drivers/video/fbdev/riva/fbdev.c | 6 --
20 files changed, 120 deletions(-)
diff --git a/drivers/macintosh/via-pmu-backlight.c
b/drivers/macintosh/via-pmu-backlight.c
index b1d9117..6f68537 100644
--- a/drivers/macintosh/via-pmu-backlight.c
+++ b/drivers/macintosh/via-pmu-backlight.c
@@ -110,13 +110,7 @@ static int pmu_backlight_update_status(struct
backlight_device *bd)
}
-static int pmu_backlight_get_brightness(struct backlight_device *bd)
-{
- return bd-props.brightness;
-}
-
static const struct backlight_ops pmu_backlight_data = {
- .get_brightness = pmu_backlight_get_brightness,
.update_status = pmu_backlight_update_status,
};
diff --git a/drivers/platform/x86/samsung-q10.c
b/drivers/platform/x86/samsung-q10.c
index 5413f62..28d12bd 100644
--- a/drivers/platform/x86/samsung-q10.c
+++ b/drivers/platform/x86/samsung-q10.c
@@ -46,13 +46,7 @@ static int samsungq10_bl_set_intensity(struct
backlight_device *bd)
return 0;
}
-static int samsungq10_bl_get_intensity(struct backlight_device *bd)
-{
- return bd-props.brightness;
-}
-
static const struct backlight_ops samsungq10_bl_ops = {
- .get_brightness = samsungq10_bl_get_intensity,
.update_status = samsungq10_bl_set_intensity,
};
diff --git a/drivers/video/backlight/aat2870_bl.c
b/drivers/video/backlight/aat2870_bl.c
index ec5350f..86234c3 100644
--- a/drivers/video/backlight/aat2870_bl.c
+++ b/drivers/video/backlight/aat2870_bl.c
@@ -67,11 +67,6 @@ static inline int aat2870_bl_disable(struct
aat2870_bl_driver_data *aat2870_bl)
return aat2870-write(aat2870, AAT2870_BL_CH_EN, 0x0);
}
-static int aat2870_bl_get_brightness(struct backlight_device *bd)
-{
- return bd-props.brightness;
-}
-
static int aat2870_bl_update_status(struct backlight_device *bd)
{
struct aat2870_bl_driver_data *aat2870_bl = bl_get_data(bd);
@@ -120,7 +115,6 @@ static int aat2870_bl_check_fb(struct backlight_device *bd,
struct fb_info *fi)
static const struct backlight_ops aat2870_bl_ops = {
.options = BL_CORE_SUSPENDRESUME,
- .get_brightness = aat2870_bl_get_brightness,
.update_status = aat2870_bl_update_status,
.check_fb = aat2870_bl_check_fb,
};
diff --git a/drivers/video/backlight/ams369fg06.c
b/drivers/video/backlight/ams369fg06.c
index d8952c4..4726c8b 100644
--- a/drivers/video/backlight/ams369fg06.c
+++ b/drivers/video/backlight/ams369fg06.c
@@ -410,11 +410,6 @@ static int ams369fg06_set_power(struct lcd_device *ld, int
power)
return ams369fg06_power(lcd, power);
}
-static int ams369fg06_get_brightness(struct backlight_device *bd)
-{
- return bd-props.brightness;
-}
-
static int ams369fg06_set_brightness(struct backlight_device *bd)
{
int ret = 0;
@@ -443,7 +438,6 @@ static struct lcd_ops ams369fg06_lcd_ops = {
};
static const struct backlight_ops ams369fg06_backlight_ops = {
- .get_brightness = ams369fg06_get_brightness,
.update_status = ams369fg06_set_brightness,
};
diff --git a/drivers/video/backlight/bd6107.c b/drivers/video/backlight/bd6107.c
index 16dd9bc..fdb2f7e 100644
--- a/drivers/video/backlight/bd6107.c
+++ b/drivers/video/backlight/bd6107.c
@@ -105,11 +105,6 @@ static int bd6107_backlight_update_status(struct
backlight_device *backlight)
return 0;
}
-static int bd6107_backlight_get_brightness(struct backlight_device *backlight)
-{
- return backlight-props.brightness;
-}
-
static int bd6107_backlight_check_fb(struct backlight_device *backlight,
struct fb_info *info)
{
@@ -121,7 +116,6 @@ static int bd6107_backlight_check_fb(struct
backlight_device *backlight,
static const struct backlight_ops
[PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void
This avoids handling gpiochip remove error in device
remove handler.
Signed-off-by: abdoulaye berthe berthe...@gmail.com
---
drivers/gpio/gpiolib.c | 24 +++-
include/linux/gpio/driver.h | 2 +-
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index f48817d..022543f 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1263,10 +1263,9 @@ static void gpiochip_irqchip_remove(struct gpio_chip
*gpiochip);
*
* A gpio_chip with any GPIOs still requested may not be removed.
*/
-int gpiochip_remove(struct gpio_chip *chip)
+void gpiochip_remove(struct gpio_chip *chip)
{
unsigned long flags;
- int status = 0;
unsignedid;
acpi_gpiochip_remove(chip);
@@ -1278,24 +1277,15 @@ int gpiochip_remove(struct gpio_chip *chip)
of_gpiochip_remove(chip);
for (id = 0; id chip-ngpio; id++) {
- if (test_bit(FLAG_REQUESTED, chip-desc[id].flags)) {
- status = -EBUSY;
- break;
- }
- }
- if (status == 0) {
- for (id = 0; id chip-ngpio; id++)
- chip-desc[id].chip = NULL;
-
- list_del(chip-list);
+ if (test_bit(FLAG_REQUESTED, chip-desc[id].flags))
+ panic(gpio: removing gpiochip with gpios still
requested\n);
}
+ for (id = 0; id chip-ngpio; id++)
+ chip-desc[id].chip = NULL;
+ list_del(chip-list);
spin_unlock_irqrestore(gpio_lock, flags);
-
- if (status == 0)
- gpiochip_unexport(chip);
-
- return status;
+ gpiochip_unexport(chip);
}
EXPORT_SYMBOL_GPL(gpiochip_remove);
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 1827b43..72ed256 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -138,7 +138,7 @@ extern const char *gpiochip_is_requested(struct gpio_chip
*chip,
/* add/remove chips */
extern int gpiochip_add(struct gpio_chip *chip);
-extern int __must_check gpiochip_remove(struct gpio_chip *chip);
+void gpiochip_remove(struct gpio_chip *chip);
extern struct gpio_chip *gpiochip_find(void *data,
int (*match)(struct gpio_chip *chip, void *data));
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void
On Fri, May 30, 2014 at 1:30 PM, abdoulaye berthe berthe...@gmail.com wrote:
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1263,10 +1263,9 @@ static void gpiochip_irqchip_remove(struct gpio_chip
*gpiochip);
*
* A gpio_chip with any GPIOs still requested may not be removed.
*/
-int gpiochip_remove(struct gpio_chip *chip)
+void gpiochip_remove(struct gpio_chip *chip)
{
unsigned long flags;
- int status = 0;
unsignedid;
acpi_gpiochip_remove(chip);
@@ -1278,24 +1277,15 @@ int gpiochip_remove(struct gpio_chip *chip)
of_gpiochip_remove(chip);
for (id = 0; id chip-ngpio; id++) {
- if (test_bit(FLAG_REQUESTED, chip-desc[id].flags)) {
- status = -EBUSY;
- break;
- }
- }
- if (status == 0) {
- for (id = 0; id chip-ngpio; id++)
- chip-desc[id].chip = NULL;
-
- list_del(chip-list);
+ if (test_bit(FLAG_REQUESTED, chip-desc[id].flags))
+ panic(gpio: removing gpiochip with gpios still
requested\n);
panic?
Is this likely to happen?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc, xmon: Enable hardware instruction breakpoint support on POWER8
This patch enables support for hardware instruction breakpoints on POWER8 with
the help of a new register called CIABR (Completed Instruction Address
Breakpoint
Register). With this patch, single hardware instruction breakpoint can be added
and cleared during any active xmon debug session. This hardware based
instruction
breakpoint mechanism works correctly along with the existing TRAP based
instruction
breakpoints available on xmon. Example usage as follows.
(A) Start xmon:
$echo x /proc/sysrq-trigger
SysRq : Entering xmon
cpu 0x0: Vector: 0 at [c01f6c67f960]
pc: c0072078: .sysrq_handle_xmon+0x58/0x60
lr: c0072078: .sysrq_handle_xmon+0x58/0x60
sp: c01f6c67fac0
msr: 90009032
current = 0xc01f6e709ac0
paca= 0xcfffa000 softe: 0irq_happened: 0x00
pid = 3250, comm = bash
enter ? for help
0:mon b
typeaddress
(B) Set the breakpoint:
0:mon ls .power_pmu_add
.power_pmu_add: c0078f50
0:mon bi c0078f50
0:mon b
typeaddress
1 inst c0078f50 .power_pmu_add+0x0/0x2e0
0:mon ls .perf_event_interrupt
.perf_event_interrupt: c007aee0
0:mon bi c007aee0
One instruction breakpoint possible with CIABR
0:mon x
(C) Run the workload (with the breakpoint):
$./perf record ls
cpu 0x2: Vector: d00 (Single Step) at [c01f718133a0]
pc: c0078f54: .power_pmu_add+0x4/0x2e0
lr: c0155be0: .event_sched_in+0x90/0x1d0
sp: c01f71813620
msr: 900040109032
current = 0xc01f6ce3
paca= 0xcfffa600 softe: 0irq_happened: 0x01
pid = 3270, comm = ls
std r22,-80(r1)
enter ? for help
(D) Clear the breakpoint:
2:mon bc
All breakpoints cleared
2:mon x
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.002 MB perf.data (~66 samples) ]
(E) Run the workload again (without any breakpoints):
$./perf record ls
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.001 MB perf.data (~61 samples) ]
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/xmon/xmon.c | 62
1 file changed, 58 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 3fd1d9a..f74ec83 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -48,6 +48,7 @@
#ifdef CONFIG_PPC64
#include asm/hvcall.h
#include asm/paca.h
+#include asm/plpar_wrappers.h
#endif
#include nonstdio.h
@@ -89,6 +90,7 @@ struct bpt {
/* Bits in bpt.enabled */
#define BP_IABR_TE 1 /* IABR translation enabled */
#define BP_IABR2
+#define BP_CIABR 4
#define BP_TRAP8
#define BP_DABR0x10
@@ -97,6 +99,7 @@ static struct bpt bpts[NBPTS];
static struct bpt dabr;
static struct bpt *iabr;
static unsigned bpinstr = 0x7fe8; /* trap */
+static bool ciabr_used = false;/* CIABR instruction breakpoint
*/
#define BP_NUM(bp) ((bp) - bpts + 1)
@@ -269,6 +272,34 @@ static inline void cinval(void *p)
asm volatile (dcbi 0,%0; icbi 0,%0 : : r (p));
}
+static void write_ciabr(unsigned long ciabr)
+{
+ if (cpu_has_feature(CPU_FTR_HVMODE)) {
+ mtspr(SPRN_CIABR, ciabr);
+ return;
+ }
+
+#ifdef CONFIG_PPC64
+ plapr_set_ciabr(ciabr);
+#endif
+}
+
+static void set_ciabr(unsigned long addr)
+{
+ addr = ~CIABR_PRIV;
+ if (cpu_has_feature(CPU_FTR_HVMODE))
+ addr |= CIABR_PRIV_HYPER;
+ else
+ addr |= CIABR_PRIV_SUPER;
+ write_ciabr(addr);
+}
+
+static void clear_ciabr(void)
+{
+ if (cpu_has_feature(CPU_FTR_ARCH_207S))
+ write_ciabr(0);
+}
+
/*
* Disable surveillance (the service processor watchdog function)
* while we are in xmon.
@@ -764,6 +795,9 @@ static void insert_cpu_bpts(void)
if (iabr cpu_has_feature(CPU_FTR_IABR))
mtspr(SPRN_IABR, iabr-address
| (iabr-enabled (BP_IABR|BP_IABR_TE)));
+
+ if (iabr cpu_has_feature(CPU_FTR_ARCH_207S))
+ set_ciabr(iabr-address);
}
static void remove_bpts(void)
@@ -791,6 +825,7 @@ static void remove_cpu_bpts(void)
hw_breakpoint_disable();
if (cpu_has_feature(CPU_FTR_IABR))
mtspr(SPRN_IABR, 0);
+ clear_ciabr();
}
/* Command interpreting routine */
@@ -1124,7 +1159,7 @@ static char *breakpoint_help_string =
b addr [cnt] set breakpoint at given instr addr\n
bc clear all breakpoints\n
bc n/addr clear breakpoint number n or at addr\n
-bi addr [cnt] set hardware instr breakpoint (POWER3/RS64 only)\n
+bi addr [cnt] set hardware instr breakpoint (POWER3/RS64/POWER8
only)\n
bd addr [cnt] set hardware data breakpoint\n
;
@@ -1163,11 +1198,20 @@ bpt_cmds(void)
Re: [PATCH] powerpc, xmon: Enable hardware instruction breakpoint support on POWER8
Anshuman Khandual khand...@linux.vnet.ibm.com writes:
This patch enables support for hardware instruction breakpoints on POWER8 with
the help of a new register called CIABR (Completed Instruction Address
Breakpoint
Register). With this patch, single hardware instruction breakpoint can be
added
and cleared during any active xmon debug session. This hardware based
instruction
breakpoint mechanism works correctly along with the existing TRAP based
instruction
breakpoints available on xmon. Example usage as follows.
(A) Start xmon:
$echo x /proc/sysrq-trigger
SysRq : Entering xmon
cpu 0x0: Vector: 0 at [c01f6c67f960]
pc: c0072078: .sysrq_handle_xmon+0x58/0x60
lr: c0072078: .sysrq_handle_xmon+0x58/0x60
sp: c01f6c67fac0
msr: 90009032
current = 0xc01f6e709ac0
paca= 0xcfffa000 softe: 0irq_happened: 0x00
pid = 3250, comm = bash
enter ? for help
0:mon b
typeaddress
(B) Set the breakpoint:
0:mon ls .power_pmu_add
.power_pmu_add: c0078f50
0:mon bi c0078f50
0:mon b
typeaddress
1 inst c0078f50 .power_pmu_add+0x0/0x2e0
0:mon ls .perf_event_interrupt
.perf_event_interrupt: c007aee0
0:mon bi c007aee0
One instruction breakpoint possible with CIABR
0:mon x
(C) Run the workload (with the breakpoint):
$./perf record ls
cpu 0x2: Vector: d00 (Single Step) at [c01f718133a0]
pc: c0078f54: .power_pmu_add+0x4/0x2e0
lr: c0155be0: .event_sched_in+0x90/0x1d0
sp: c01f71813620
msr: 900040109032
current = 0xc01f6ce3
paca= 0xcfffa600 softe: 0irq_happened: 0x01
pid = 3270, comm = ls
std r22,-80(r1)
enter ? for help
(D) Clear the breakpoint:
2:mon bc
All breakpoints cleared
2:mon x
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.002 MB perf.data (~66 samples) ]
(E) Run the workload again (without any breakpoints):
$./perf record ls
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.001 MB perf.data (~61 samples) ]
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/xmon/xmon.c | 62
1 file changed, 58 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 3fd1d9a..f74ec83 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -48,6 +48,7 @@
#ifdef CONFIG_PPC64
#include asm/hvcall.h
#include asm/paca.h
+#include asm/plpar_wrappers.h
#endif
#include nonstdio.h
@@ -89,6 +90,7 @@ struct bpt {
/* Bits in bpt.enabled */
#define BP_IABR_TE 1 /* IABR translation enabled */
#define BP_IABR 2
+#define BP_CIABR 4
#define BP_TRAP 8
#define BP_DABR 0x10
@@ -97,6 +99,7 @@ static struct bpt bpts[NBPTS];
static struct bpt dabr;
static struct bpt *iabr;
static unsigned bpinstr = 0x7fe8;/* trap */
+static bool ciabr_used = false; /* CIABR instruction breakpoint
*/
#define BP_NUM(bp) ((bp) - bpts + 1)
@@ -269,6 +272,34 @@ static inline void cinval(void *p)
asm volatile (dcbi 0,%0; icbi 0,%0 : : r (p));
}
+static void write_ciabr(unsigned long ciabr)
+{
+ if (cpu_has_feature(CPU_FTR_HVMODE)) {
+ mtspr(SPRN_CIABR, ciabr);
+ return;
+ }
+
+#ifdef CONFIG_PPC64
+ plapr_set_ciabr(ciabr);
+#endif
+}
+
+static void set_ciabr(unsigned long addr)
+{
+ addr = ~CIABR_PRIV;
+ if (cpu_has_feature(CPU_FTR_HVMODE))
+ addr |= CIABR_PRIV_HYPER;
+ else
+ addr |= CIABR_PRIV_SUPER;
+ write_ciabr(addr);
+}
+
+static void clear_ciabr(void)
+{
+ if (cpu_has_feature(CPU_FTR_ARCH_207S))
+ write_ciabr(0);
+}
+
/*
* Disable surveillance (the service processor watchdog function)
* while we are in xmon.
@@ -764,6 +795,9 @@ static void insert_cpu_bpts(void)
if (iabr cpu_has_feature(CPU_FTR_IABR))
mtspr(SPRN_IABR, iabr-address
| (iabr-enabled (BP_IABR|BP_IABR_TE)));
+
+ if (iabr cpu_has_feature(CPU_FTR_ARCH_207S))
+ set_ciabr(iabr-address);
}
static void remove_bpts(void)
@@ -791,6 +825,7 @@ static void remove_cpu_bpts(void)
hw_breakpoint_disable();
if (cpu_has_feature(CPU_FTR_IABR))
mtspr(SPRN_IABR, 0);
+ clear_ciabr();
}
/* Command interpreting routine */
@@ -1124,7 +1159,7 @@ static char *breakpoint_help_string =
b addr [cnt] set breakpoint at given instr addr\n
bc clear all breakpoints\n
bc n/addr clear breakpoint number n or at addr\n
-bi addr [cnt] set hardware instr breakpoint (POWER3/RS64 only)\n
+bi addr [cnt] set
Re: [PATCH v2] powerpc/powernv: hwmon driver for power values, fan rpm and temperature
On 05/28/2014 01:11 PM, Benjamin Herrenschmidt wrote: On Wed, 2014-05-28 at 00:23 -0700, Guenter Roeck wrote: Consider using of_property_read_u32(). + sdata[count].id = *sensor_id; + sdata[count].type = type; Especially since this is broken for Little Endian ! Neelesh, please make sure you test your patch on LE. Cheers, Ben. Fixing it and will surely test on LE as well before posting. - Neelesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void
On Fri, May 30, 2014 at 01:39:15PM +0200, Geert Uytterhoeven wrote: + if (test_bit(FLAG_REQUESTED, chip-desc[id].flags)) + panic(gpio: removing gpiochip with gpios still requested\n); panic? Is this likely to happen? And while we're at it - panic() is going to add a \n itself so don't pass a string ending in \n to panic(). Ralf ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: P1022 audio driver help!
On 05/30/2014 01:03 AM, eshe168 wrote: @timur hi, Audio card (wm8776) cannot work in full duplex, CPU is FSL P1022. The PCB design about audio card reference FSL P1022 development board, and palying or recording is OK separately. My question is whether P1022 audio driver cannot support full duplex? I was never able to get the P1022ds audio to work in full duplex. After trying for a few weeks, I just gave up. If you look inside fsl_ssi.c (the main driver) you'll see this comment I wrote: /* * FIXME: The documentation says that SxCCR[WL] should not be * modified while the SSI is enabled. The only time this can * happen is if we're trying to do simultaneous playback and * capture in asynchronous mode. Unfortunately, I have been enable * to get that to work at all on the P1022DS. Therefore, we don't * bother to disable/enable the SSI when setting SxCCR[WL], because * the SSI will stop anyway. Maybe one day, this will get fixed. */ (it should say I have been unable instead of I have been enable) Full duplex works fine on the MPC8610, which has the same audio controller as the P1022, so I know the controller is physically capable of it. I just don't know why it doesn't work on the P1022DS. I also don't know if it's a problem with the P1022DS board or with the P1022 SOC itself. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/e6500: hw tablewalk: fix recursive tlb lock on cpu 0
On Fri, 2014-05-30 at 02:59 -0500, Caraman Mihai Claudiu-B02008 wrote: -Original Message- From: Linuxppc-dev [mailto:linuxppc-dev- bounces+mihai.caraman=freescale@lists.ozlabs.org] On Behalf Of Scott Wood Sent: Friday, May 23, 2014 12:45 AM To: linuxppc-dev@lists.ozlabs.org Cc: Wood Scott-B07421 Subject: [PATCH 2/2] powerpc/e6500: hw tablewalk: fix recursive tlb lock on cpu 0 Commit 82d86de25b9c99db546e17c6f7ebf9a691da557e TLB lock recursive introduced a bug whereby cpu 0 uses the same value for lock held as is used to indicate that the lock is free. Isn't his what spin lock implementation solves by combines paca_index with lock_token? Can't we have a common approach? That would require expanding the lock to 32 bits, is a more intrusive fix than needed, and invites breakage in the TLB code if the lock_token mechanism were to change. Add one to the CPU value to ensure we do not use zero as a lock held value. The CPU value is loaded in r10 from tlb_miss_common_e6500. TLB lock recursive commit also introduced this misleading comment: We are entered with: r10 = cpu number I addressed this in v2 that I posted yesterday. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void
On 05/30/2014 04:39 AM, Geert Uytterhoeven wrote:
On Fri, May 30, 2014 at 1:30 PM, abdoulaye berthe berthe...@gmail.com wrote:
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1263,10 +1263,9 @@ static void gpiochip_irqchip_remove(struct gpio_chip
*gpiochip);
*
* A gpio_chip with any GPIOs still requested may not be removed.
*/
-int gpiochip_remove(struct gpio_chip *chip)
+void gpiochip_remove(struct gpio_chip *chip)
{
unsigned long flags;
- int status = 0;
unsignedid;
acpi_gpiochip_remove(chip);
@@ -1278,24 +1277,15 @@ int gpiochip_remove(struct gpio_chip *chip)
of_gpiochip_remove(chip);
for (id = 0; id chip-ngpio; id++) {
- if (test_bit(FLAG_REQUESTED, chip-desc[id].flags)) {
- status = -EBUSY;
- break;
- }
- }
- if (status == 0) {
- for (id = 0; id chip-ngpio; id++)
- chip-desc[id].chip = NULL;
-
- list_del(chip-list);
+ if (test_bit(FLAG_REQUESTED, chip-desc[id].flags))
+ panic(gpio: removing gpiochip with gpios still
requested\n);
panic?
NACK to the patch for this reason. The strongest thing you should do
here is WARN.
That said, I am not sure why we need this whole patch set in the first
place.
David Daney
Is this likely to happen?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void
On 05/30/2014 07:33 PM, David Daney wrote:
On 05/30/2014 04:39 AM, Geert Uytterhoeven wrote:
On Fri, May 30, 2014 at 1:30 PM, abdoulaye berthe berthe...@gmail.com
wrote:
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1263,10 +1263,9 @@ static void gpiochip_irqchip_remove(struct
gpio_chip *gpiochip);
*
* A gpio_chip with any GPIOs still requested may not be removed.
*/
-int gpiochip_remove(struct gpio_chip *chip)
+void gpiochip_remove(struct gpio_chip *chip)
{
unsigned long flags;
- int status = 0;
unsignedid;
acpi_gpiochip_remove(chip);
@@ -1278,24 +1277,15 @@ int gpiochip_remove(struct gpio_chip *chip)
of_gpiochip_remove(chip);
for (id = 0; id chip-ngpio; id++) {
- if (test_bit(FLAG_REQUESTED, chip-desc[id].flags)) {
- status = -EBUSY;
- break;
- }
- }
- if (status == 0) {
- for (id = 0; id chip-ngpio; id++)
- chip-desc[id].chip = NULL;
-
- list_del(chip-list);
+ if (test_bit(FLAG_REQUESTED, chip-desc[id].flags))
+ panic(gpio: removing gpiochip with gpios still
requested\n);
panic?
NACK to the patch for this reason. The strongest thing you should do here
is WARN.
That said, I am not sure why we need this whole patch set in the first place.
Well, what currently happens when you remove a device that is a provider of
a gpio_chip which is still in use, is that the kernel crashes. Probably with
a rather cryptic error message. So this patch doesn't really change the
behavior, but makes it more explicit what is actually wrong. And even if you
replace the panic() by a WARN() it will again just crash slightly later.
This is a design flaw in the GPIO subsystem that needs to be fixed.
- Lars
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/booke64: wrap tlb lock and search in htw miss with FTR_SMT
On Fri, 2014-05-30 at 17:59 +0300, Laurentiu Tudor wrote: Virtualized environments expose a e6500 dual-threaded core as two single-threaded e6500 cores. s/expose/may expose/ I'll fix when applying. Take advantage of this and get rid of the tlb lock and the trap-causing tlbsx in the htw miss handler by guarding with CPU_FTR_SMT, as it's already being done in the bolted tlb1 miss handler. It's also possible that some non-virtualized workloads may also benefit from getting rid of the lock more than they benefit from enabling SMT (or perform better without SMT for other reasons). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3 v2] powerpc/fsl-booke: Add support for T2080/T2081 SoC
On Fri, 2014-05-23 at 16:27 +0800, Shengzhou Liu wrote:
+ iommu@2 {
+ compatible = fsl,pamu-v1.0, fsl,pamu;
+ reg = 0x2 0x6000;
+ interrupts =
+ 24 2 0 0
+ 16 2 1 30;
+ };
Please add fsl,portid-mapping here and on the CPU nodes.
+ clockgen: global-utilities@e1000 {
+ compatible = fsl,t2080-clockgen, fsl,qoriq-clockgen-2.0,
+fixed-clock;
+ reg = 0xe1000 0x1000;
+ clock-output-names = sysclk;
+ #clock-cells = 0;
Please update this based on
Documentation/devicetree/bindings/clock/qoriq-clock.txt.
In particular, sysclk needs to go in a subnode rather than in the
global-utilities node.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/t2080rdb: Add T2080RDB board support
On Fri, 2014-05-23 at 16:27 +0800, Shengzhou Liu wrote: diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index e3578b7..a8a0f2f 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -259,7 +259,7 @@ config CORENET_GENERIC For 32bit kernel, the following boards are supported: P2041 RDB, P3041 DS and P4080 DS For 64bit kernel, the following boards are supported: - T208x QDS, T4240 QDS and B4 QDS + T208x QDS/RDB, T4240 QDS and B4 QDS Apparently you meant for this to be applied after the QDS patch -- please ensure patches within a set are numbered. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] t4240/dts: Enable third elo3 DMA engine support
On Wed, 2014-05-28 at 16:47 +0800, Chunhe Lan wrote: T4240QDS and T4240RDB have the third DMA engine controller. So add corresponding DMA node into dts file. s/T4240QDS and T4240RDB have/T4240 has/ -- the board is irrelevant. I'll fix when applying. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Add T4240RDB board support
On Wed, 2014-05-28 at 16:11 +0800, Chunhe Lan wrote:
@@ -125,6 +127,9 @@ CONFIG_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_EDAC=y
CONFIG_EDAC_MM_EDAC=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_DS1374=y
+CONFIG_RTC_DRV_CMOS=y
CONFIG_DMADEVICES=y
CONFIG_FSL_DMA=y
CONFIG_EXT2_FS=y
This conflicts with http://patchwork.ozlabs.org/patch/353243/ and you
shouldn't need CONFIG_RTC_DRV_CMOS.
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index c17aae8..6f279ce 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -265,7 +265,7 @@ config CORENET_GENERIC
For 32bit kernel, the following boards are supported:
P2041 RDB, P3041 DS and P4080 DS
For 64bit kernel, the following boards are supported:
- T4240 QDS and B4 QDS
+ T4240 QDS, T4240 RDB and B4 QDS
T4240QDS/RDB
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerpc/platforms/85xx/corenet_generic.c
index 8e4b1e1..2f50526 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -119,6 +119,7 @@ static const char * const boards[] __initconst = {
fsl,P5020DS,
fsl,P5040DS,
fsl,T4240QDS,
+ fsl,T4240RDB,
fsl,B4860QDS,
fsl,B4420QDS,
fsl,B4220QDS,
What about hv_boards?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Patch not showing up in patchwork (was Re: [PATCH] powerpc/booke64: wrap tlb lock and search in htw miss with FTR_SMT)
On Fri, 2014-05-30 at 17:59 +0300, Laurentiu Tudor wrote: Virtualized environments expose a e6500 dual-threaded core as two single-threaded e6500 cores. Take advantage of this and get rid of the tlb lock and the trap-causing tlbsx in the htw miss handler by guarding with CPU_FTR_SMT, as it's already being done in the bolted tlb1 miss handler. As seen in the results below, measurements done with lmbench random memory access latency test running under Freescale's Embedded Hypervisor, there is a ~34% improvement. Memory latencies in nanoseconds - smaller is better (WARNING - may not be correct, check graphs) Host Mhz L1 $ L2 $Main memRand mem - --- smt 1665 1.8020 13.283.0 1149.7 nosmt 1665 1.8020 13.283.0 758.1 Signed-off-by: Laurentiu Tudor laurentiu.tu...@freescale.com Cc: Scott Wood scottw...@freescale.com --- arch/powerpc/mm/tlb_low_64e.S | 4 1 file changed, 4 insertions(+) Any idea why this patch isn't showing up on the mailing list? I see my reply in the archives, but not the original patch. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/booke64: wrap tlb lock and search in htw miss with FTR_SMT
From: Laurentiu Tudor laurentiu.tu...@freescale.com Virtualized environments may expose a e6500 dual-threaded core as two single-threaded e6500 cores. Take advantage of this and get rid of the tlb lock and the trap-causing tlbsx in the htw miss handler by guarding with CPU_FTR_SMT, as it's already being done in the bolted tlb1 miss handler. As seen in the results below, measurements done with lmbench random memory access latency test running under Freescale's Embedded Hypervisor, there is a ~34% improvement. Memory latencies in nanoseconds - smaller is better (WARNING - may not be correct, check graphs) Host Mhz L1 $ L2 $Main memRand mem - --- smt 1665 1.8020 13.283.0 1149.7 nosmt 1665 1.8020 13.283.0 758.1 Signed-off-by: Laurentiu Tudor laurentiu.tu...@freescale.com Cc: Scott Wood scottw...@freescale.com [scottw...@freescale.com: commit message tweak] Signed-off-by: Scott Wood scottw...@freescale.com --- v2: - s/expose/may expose/ in commit message - rebased onto my patch queue to resolve conflict - resent since the original didn't make it to the list archives or patchwork. arch/powerpc/mm/tlb_low_64e.S | 4 1 file changed, 4 insertions(+) diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S index 131f1f4..57c4d66 100644 --- a/arch/powerpc/mm/tlb_low_64e.S +++ b/arch/powerpc/mm/tlb_low_64e.S @@ -299,6 +299,7 @@ itlb_miss_fault_bolted: * r10 = crap (free to use) */ tlb_miss_common_e6500: +BEGIN_FTR_SECTION /* * Search if we already have an indirect entry for that virtual * address, and if we do, bail out. @@ -333,6 +334,7 @@ tlb_miss_common_e6500: andis. r10,r10,MAS1_VALID@h bne tlb_miss_done_e6500 +END_FTR_SECTION_IFSET(CPU_FTR_SMT) /* Now, we need to walk the page tables. First check if we are in * range. @@ -393,11 +395,13 @@ tlb_miss_common_e6500: tlb_miss_done_e6500: .macro tlb_unlock_e6500 +BEGIN_FTR_SECTION beq cr1,1f /* no unlock if lock was recursively grabbed */ li r15,0 isync stb r15,0(r11) 1: +END_FTR_SECTION_IFSET(CPU_FTR_SMT) .endm tlb_unlock_e6500 -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] MAINTAINERS: Update Linux for Freescale PowerPC
About a year ago I began taking patches, technically as Kumar's assistant -- but since then all of the pull requests for this area have come from me, and I've been doing most of the reviews. Update MAINTAINERS to reflect this. Signed-off-by: Scott Wood scottw...@freescale.com Cc: Kumar Gala ga...@kernel.crashing.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 049214e..5509f3f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5341,9 +5341,11 @@ S: Maintained F: arch/powerpc/platforms/8xx/ LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX +M: Scott Wood scottw...@freescale.com M: Kumar Gala ga...@kernel.crashing.org W: http://www.penguinppc.org/ L: linuxppc-dev@lists.ozlabs.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git S: Maintained F: arch/powerpc/platforms/83xx/ F: arch/powerpc/platforms/85xx/ -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void
On Fri, May 30, 2014 at 08:16:59PM +0200, Lars-Peter Clausen wrote:
On 05/30/2014 07:33 PM, David Daney wrote:
On 05/30/2014 04:39 AM, Geert Uytterhoeven wrote:
On Fri, May 30, 2014 at 1:30 PM, abdoulaye berthe berthe...@gmail.com
wrote:
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1263,10 +1263,9 @@ static void gpiochip_irqchip_remove(struct
gpio_chip *gpiochip);
*
* A gpio_chip with any GPIOs still requested may not be removed.
*/
-int gpiochip_remove(struct gpio_chip *chip)
+void gpiochip_remove(struct gpio_chip *chip)
{
unsigned long flags;
- int status = 0;
unsignedid;
acpi_gpiochip_remove(chip);
@@ -1278,24 +1277,15 @@ int gpiochip_remove(struct gpio_chip *chip)
of_gpiochip_remove(chip);
for (id = 0; id chip-ngpio; id++) {
- if (test_bit(FLAG_REQUESTED, chip-desc[id].flags)) {
- status = -EBUSY;
- break;
- }
- }
- if (status == 0) {
- for (id = 0; id chip-ngpio; id++)
- chip-desc[id].chip = NULL;
-
- list_del(chip-list);
+ if (test_bit(FLAG_REQUESTED, chip-desc[id].flags))
+ panic(gpio: removing gpiochip with gpios still
requested\n);
panic?
NACK to the patch for this reason. The strongest thing you should do here
is WARN.
That said, I am not sure why we need this whole patch set in the first place.
Well, what currently happens when you remove a device that is a provider of
a gpio_chip which is still in use, is that the kernel crashes. Probably with
a rather cryptic error message. So this patch doesn't really change the
behavior, but makes it more explicit what is actually wrong. And even if you
replace the panic() by a WARN() it will again just crash slightly later.
This is a design flaw in the GPIO subsystem that needs to be fixed.
Then fix the GPIO code properly, don't add a new panic() to the kernel.
greg k-h
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
