Re: [PATCH 3/3] powerpc: allow 256kB pages with SHMEM
On Thu, 9 Apr 2009, Andrew Morton wrote: > On Mon, 6 Apr 2009 22:01:15 +0100 (BST) > Hugh Dickins wrote: > > > Now that shmem's divisions by zero and SHMEM_MAX_BYTES are fixed, > > let powerpc 256kB pages coexist with CONFIG_SHMEM again. > > > > Signed-off-by: Hugh Dickins > > --- > > Added linuxppc-dev and some other Cc's for this 3/3: sorry > > if you didn't see 1/3 and 2/3, they were just in mm/shmem.c. > > Do we think these patches should be in 2.6.30? I think so - 2.6.30 will have the rest of Yuri's 256kB page support. But it would be nice to have an Ack from Yuri before sending these on through. 2/3 is a bugfix justified even without 256kB pages - I should have inverted the ordering. Hugh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
On Thu, 9 Apr 2009 14:19:45 +0200, Jean Delvare wrote:
> From: Jean Delvare
> Subject: AOA: Convert onyx and tas codecs to new-style i2c drivers
>
> The legacy i2c binding model is going away soon, so convert the AOA
> codec drivers to the new model or they'll break.
>
> Signed-off-by: Jean Delvare
> Cc: Johannes Berg
> Cc: Benjamin Herrenschmidt
> ---
> sound/aoa/codecs/onyx.c | 71
> +--
> sound/aoa/codecs/tas.c | 63 +
> 2 files changed, 84 insertions(+), 50 deletions(-)
Note to potential testers of this patch: you need to apply this i2c
patch first:
ftp://ftp.kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/i2c-loosen-driver-check.patch
>
> --- linux-2.6.30-rc1.orig/sound/aoa/codecs/onyx.c 2009-04-09
> 11:53:11.0 +0200
> +++ linux-2.6.30-rc1/sound/aoa/codecs/onyx.c 2009-04-09 13:58:44.0
> +0200
> @@ -47,7 +47,7 @@ MODULE_DESCRIPTION("pcm3052 (onyx) codec
> struct onyx {
> /* cache registers 65 to 80, they are write-only! */
> u8 cache[16];
> - struct i2c_client i2c;
> + struct i2c_client *i2c;
> struct aoa_codeccodec;
> u32 initialised:1,
> spdif_locked:1,
> @@ -72,7 +72,7 @@ static int onyx_read_register(struct ony
> *value = onyx->cache[reg-FIRSTREGISTER];
> return 0;
> }
> - v = i2c_smbus_read_byte_data(&onyx->i2c, reg);
> + v = i2c_smbus_read_byte_data(onyx->i2c, reg);
> if (v < 0)
> return -1;
> *value = (u8)v;
> @@ -84,7 +84,7 @@ static int onyx_write_register(struct on
> {
> int result;
>
> - result = i2c_smbus_write_byte_data(&onyx->i2c, reg, value);
> + result = i2c_smbus_write_byte_data(onyx->i2c, reg, value);
> if (!result)
> onyx->cache[reg-FIRSTREGISTER] = value;
> return result;
> @@ -996,12 +996,38 @@ static void onyx_exit_codec(struct aoa_c
> onyx->codec.soundbus_dev->detach_codec(onyx->codec.soundbus_dev, onyx);
> }
>
> -static struct i2c_driver onyx_driver;
> -
> static int onyx_create(struct i2c_adapter *adapter,
> struct device_node *node,
> int addr)
> {
> + struct i2c_board_info info;
> + struct i2c_client *client;
> +
> + memset(&info, 0, sizeof(struct i2c_board_info));
> + strlcpy(info.type, "aoa_codec_onyx", I2C_NAME_SIZE);
> + if (node) {
> + info.addr = addr;
> + info.platform_data = node;
> + client = i2c_new_device(adapter, &info);
> + } else {
> + /* probe both possible addresses for the onyx chip */
> + unsigned short probe_onyx[] = {
> + 0x46, 0x47, I2C_CLIENT_END
> + };
> +
> + client = i2c_new_probed_device(adapter, &info, probe_onyx);
> + }
> + if (!client)
> + return -ENODEV;
> +
> + list_add_tail(&client->detected, &client->driver->clients);
> + return 0;
> +}
> +
> +static int onyx_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device_node *node = client->dev.platform_data;
> struct onyx *onyx;
> u8 dummy;
>
> @@ -1011,20 +1037,12 @@ static int onyx_create(struct i2c_adapte
> return -ENOMEM;
>
> mutex_init(&onyx->mutex);
> - onyx->i2c.driver = &onyx_driver;
> - onyx->i2c.adapter = adapter;
> - onyx->i2c.addr = addr & 0x7f;
> - strlcpy(onyx->i2c.name, "onyx audio codec", I2C_NAME_SIZE);
> -
> - if (i2c_attach_client(&onyx->i2c)) {
> - printk(KERN_ERR PFX "failed to attach to i2c\n");
> - goto fail;
> - }
> + onyx->i2c = client;
> + i2c_set_clientdata(client, onyx);
>
> /* we try to read from register ONYX_REG_CONTROL
>* to check if the codec is present */
> if (onyx_read_register(onyx, ONYX_REG_CONTROL, &dummy) != 0) {
> - i2c_detach_client(&onyx->i2c);
> printk(KERN_ERR PFX "failed to read control register\n");
> goto fail;
> }
> @@ -1036,7 +1054,6 @@ static int onyx_create(struct i2c_adapte
> onyx->codec.node = of_node_get(node);
>
> if (aoa_codec_register(&onyx->codec)) {
> - i2c_detach_client(&onyx->i2c);
> goto fail;
> }
> printk(KERN_DEBUG PFX "created and attached onyx instance\n");
> @@ -1074,19 +1091,13 @@ static int onyx_i2c_attach(struct i2c_ad
> return -ENODEV;
>
> printk(KERN_DEBUG PFX "found k2-i2c, checking if onyx chip is on it\n");
> - /* probe both possible addresses for the onyx chip */
> - if (onyx_create(adapter, NULL, 0x46) == 0)
> - return 0;
> - return onyx_create(adapter, NULL, 0x47);
> + return onyx_create(adapter, NULL, 0);
> }
>
> -stati
[PATCH 1/2] keywest: Convert to new-style i2c driver
The legacy i2c binding model is going away soon, so convert the ppc
keywest sound driver to the new model or it will break.
Signed-off-by: Jean Delvare
Cc: Benjamin Herrenschmidt
---
sound/ppc/keywest.c | 81 +--
1 file changed, 40 insertions(+), 41 deletions(-)
--- linux-2.6.30-rc1.orig/sound/ppc/keywest.c 2009-04-10 15:22:18.0
+0200
+++ linux-2.6.30-rc1/sound/ppc/keywest.c2009-04-10 16:41:36.0
+0200
@@ -33,26 +33,25 @@
static struct pmac_keywest *keywest_ctx;
-static int keywest_attach_adapter(struct i2c_adapter *adapter);
-static int keywest_detach_client(struct i2c_client *client);
-
-struct i2c_driver keywest_driver = {
- .driver = {
- .name = "PMac Keywest Audio",
- },
- .attach_adapter = &keywest_attach_adapter,
- .detach_client = &keywest_detach_client,
-};
-
-
#ifndef i2c_device_name
#define i2c_device_name(x) ((x)->name)
#endif
+static int keywest_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+ i2c_set_clientdata(client, keywest_ctx);
+ return 0;
+}
+
+/*
+ * This is kind of a hack, best would be to turn powermac to fixed i2c
+ * bus numbers and declare the sound device as part of platform
+ * initialization
+ */
static int keywest_attach_adapter(struct i2c_adapter *adapter)
{
- int err;
- struct i2c_client *new_client;
+ struct i2c_board_info info;
if (! keywest_ctx)
return -EINVAL;
@@ -60,46 +59,46 @@ static int keywest_attach_adapter(struct
if (strncmp(i2c_device_name(adapter), "mac-io", 6))
return 0; /* ignored */
- new_client = kzalloc(sizeof(struct i2c_client), GFP_KERNEL);
- if (! new_client)
- return -ENOMEM;
-
- new_client->addr = keywest_ctx->addr;
- i2c_set_clientdata(new_client, keywest_ctx);
- new_client->adapter = adapter;
- new_client->driver = &keywest_driver;
- new_client->flags = 0;
-
- strcpy(i2c_device_name(new_client), keywest_ctx->name);
- keywest_ctx->client = new_client;
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, "keywest", I2C_NAME_SIZE);
+ info.addr = keywest_ctx->addr;
+ keywest_ctx->client = i2c_new_device(adapter, &info);
- /* Tell the i2c layer a new client has arrived */
- if (i2c_attach_client(new_client)) {
- snd_printk(KERN_ERR "tumbler: cannot attach i2c client\n");
- err = -ENODEV;
- goto __err;
- }
-
+ /*
+* Let i2c-core delete that device on driver removal.
+* This is safe because i2c-core holds the core_lock mutex for us.
+*/
+ list_add_tail(&keywest_ctx->client->detected,
+ &keywest_ctx->client->driver->clients);
return 0;
-
- __err:
- kfree(new_client);
- keywest_ctx->client = NULL;
- return err;
}
-static int keywest_detach_client(struct i2c_client *client)
+static int keywest_remove(struct i2c_client *client)
{
if (! keywest_ctx)
return 0;
if (client == keywest_ctx->client)
keywest_ctx->client = NULL;
- i2c_detach_client(client);
- kfree(client);
return 0;
}
+
+static const struct i2c_device_id keywest_i2c_id[] = {
+ { "keywest", 0 },
+ { }
+};
+
+struct i2c_driver keywest_driver = {
+ .driver = {
+ .name = "PMac Keywest Audio",
+ },
+ .attach_adapter = keywest_attach_adapter,
+ .probe = keywest_probe,
+ .remove = keywest_remove,
+ .id_table = keywest_i2c_id,
+};
+
/* exported */
void snd_pmac_keywest_cleanup(struct pmac_keywest *i2c)
{
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] keywest: Get rid of useless i2c_device_name macro
The i2c_device_name macro doesn't have much value, get rid of it.
Signed-off-by: Jean Delvare
Cc: Benjamin Herrenschmidt
---
sound/ppc/keywest.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
--- linux-2.6.30-rc1.orig/sound/ppc/keywest.c 2009-04-10 16:22:08.0
+0200
+++ linux-2.6.30-rc1/sound/ppc/keywest.c2009-04-10 16:25:16.0
+0200
@@ -33,10 +33,6 @@
static struct pmac_keywest *keywest_ctx;
-#ifndef i2c_device_name
-#define i2c_device_name(x) ((x)->name)
-#endif
-
static int keywest_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -56,7 +52,7 @@ static int keywest_attach_adapter(struct
if (! keywest_ctx)
return -EINVAL;
- if (strncmp(i2c_device_name(adapter), "mac-io", 6))
+ if (strncmp(adapter->name, "mac-io", 6))
return 0; /* ignored */
memset(&info, 0, sizeof(struct i2c_board_info));
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] keywest: Convert to new-style i2c driver
On Fri, 10 Apr 2009 17:07:26 +0200, Jean Delvare wrote:
> The legacy i2c binding model is going away soon, so convert the ppc
> keywest sound driver to the new model or it will break.
>
> Signed-off-by: Jean Delvare
> Cc: Benjamin Herrenschmidt
> ---
> sound/ppc/keywest.c | 81
> +--
> 1 file changed, 40 insertions(+), 41 deletions(-)
Ah, I forgot. You need the following patch applied before testing:
ftp://ftp.kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/i2c-loosen-driver-check.patch
>
> --- linux-2.6.30-rc1.orig/sound/ppc/keywest.c 2009-04-10 15:22:18.0
> +0200
> +++ linux-2.6.30-rc1/sound/ppc/keywest.c 2009-04-10 16:41:36.0
> +0200
> @@ -33,26 +33,25 @@
> static struct pmac_keywest *keywest_ctx;
>
>
> -static int keywest_attach_adapter(struct i2c_adapter *adapter);
> -static int keywest_detach_client(struct i2c_client *client);
> -
> -struct i2c_driver keywest_driver = {
> - .driver = {
> - .name = "PMac Keywest Audio",
> - },
> - .attach_adapter = &keywest_attach_adapter,
> - .detach_client = &keywest_detach_client,
> -};
> -
> -
> #ifndef i2c_device_name
> #define i2c_device_name(x) ((x)->name)
> #endif
>
> +static int keywest_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + i2c_set_clientdata(client, keywest_ctx);
> + return 0;
> +}
> +
> +/*
> + * This is kind of a hack, best would be to turn powermac to fixed i2c
> + * bus numbers and declare the sound device as part of platform
> + * initialization
> + */
> static int keywest_attach_adapter(struct i2c_adapter *adapter)
> {
> - int err;
> - struct i2c_client *new_client;
> + struct i2c_board_info info;
>
> if (! keywest_ctx)
> return -EINVAL;
> @@ -60,46 +59,46 @@ static int keywest_attach_adapter(struct
> if (strncmp(i2c_device_name(adapter), "mac-io", 6))
> return 0; /* ignored */
>
> - new_client = kzalloc(sizeof(struct i2c_client), GFP_KERNEL);
> - if (! new_client)
> - return -ENOMEM;
> -
> - new_client->addr = keywest_ctx->addr;
> - i2c_set_clientdata(new_client, keywest_ctx);
> - new_client->adapter = adapter;
> - new_client->driver = &keywest_driver;
> - new_client->flags = 0;
> -
> - strcpy(i2c_device_name(new_client), keywest_ctx->name);
> - keywest_ctx->client = new_client;
> + memset(&info, 0, sizeof(struct i2c_board_info));
> + strlcpy(info.type, "keywest", I2C_NAME_SIZE);
> + info.addr = keywest_ctx->addr;
> + keywest_ctx->client = i2c_new_device(adapter, &info);
>
> - /* Tell the i2c layer a new client has arrived */
> - if (i2c_attach_client(new_client)) {
> - snd_printk(KERN_ERR "tumbler: cannot attach i2c client\n");
> - err = -ENODEV;
> - goto __err;
> - }
> -
> + /*
> + * Let i2c-core delete that device on driver removal.
> + * This is safe because i2c-core holds the core_lock mutex for us.
> + */
> + list_add_tail(&keywest_ctx->client->detected,
> + &keywest_ctx->client->driver->clients);
> return 0;
> -
> - __err:
> - kfree(new_client);
> - keywest_ctx->client = NULL;
> - return err;
> }
>
> -static int keywest_detach_client(struct i2c_client *client)
> +static int keywest_remove(struct i2c_client *client)
> {
> if (! keywest_ctx)
> return 0;
> if (client == keywest_ctx->client)
> keywest_ctx->client = NULL;
>
> - i2c_detach_client(client);
> - kfree(client);
> return 0;
> }
>
> +
> +static const struct i2c_device_id keywest_i2c_id[] = {
> + { "keywest", 0 },
> + { }
> +};
> +
> +struct i2c_driver keywest_driver = {
> + .driver = {
> + .name = "PMac Keywest Audio",
> + },
> + .attach_adapter = keywest_attach_adapter,
> + .probe = keywest_probe,
> + .remove = keywest_remove,
> + .id_table = keywest_i2c_id,
> +};
> +
> /* exported */
> void snd_pmac_keywest_cleanup(struct pmac_keywest *i2c)
> {
>
>
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
/scratch/tony/working/arch/powerpc/kernel/cacheinfo.c: In function 'associativity_show': /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c:562: warning: 'associativity' may be used uninitialized in this function /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c: In function 'size_show': /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c:513: warning: 'size_kb' may be used uninitialized in this function Thanks. So I think I've convinced myself that the warnings are incorrect and that uninitialized use is not possible. Strictly speaking the warnings aren't incorrect: the variables "may be used uninitialized", they just never are. I agree this isn't very helpful. But I find it odd that gcc gives warnings for these sites but not others in the file that use the same idiom (e.g. line_size_show, nr_sets_show). Yeah. I'd guess that inlining is implicated somehow. Would I be justified in worrying that this version of gcc is generating incorrect code? Not really. Sub-optimal code perhaps, but not incorrect. If not, then I'm fine with the uninitialized_var() changes, but do please include the warnings and the compiler version in the changelog. If this happens with a non-ancient GCC version, can we have a bugreport please? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
Segher Boessenkool wrote:
Unfortunately -Wno-uninitialized also suppresses the warnings that point
to real bugs.
It's a double-edged sword, yes. Warnings are always like that:
if the compiler could know that something _is_ wrong for certain,
it wouldn't need a warning (it would use an error, instead -- and
it does do this in certain cases); if it would know something is
not really wrong, it would just shut up.
The problem is that GCC does not give an error (only a warning) even for
things like this where it should be trivial to detect that the usage
*is* uninitialized, not just might be:
int foo(void)
{
int a;
return a;
}
And further, there is no separation of warning classes into
might-be-uninitialized and is-uninitialized-compiler-can-tell-for-sure.
In other words, there should be a way to tell the compiler to err on the
side of not complaining if it's unsure, but still report the obvious
ones (or make the latter an error but the former a warning). That's not
ESP or DWIM.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
Scott Wood writes:
> The problem is that GCC does not give an error (only a warning) even for
> things like this where it should be trivial to detect that the usage *is*
> uninitialized, not just might be:
>
> int foo(void)
> {
>int a;
>
>return a;
> }
The compiler must not reject this code, because the undefined behavior
only occurs if executed. There is no constraint violated.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
Andreas Schwab wrote:
Scott Wood writes:
The problem is that GCC does not give an error (only a warning) even for
things like this where it should be trivial to detect that the usage *is*
uninitialized, not just might be:
int foo(void)
{
int a;
return a;
}
The compiler must not reject this code, because the undefined behavior
only occurs if executed. There is no constraint violated.
Fine (though GCC could have something similar to -Werror but more
limited in scope to the really serious stuff that *should* be illegal
even if it isn't), but it should at least be a separate warning class.
My point was to counter Segher's assertion that the compiler currently
gives an error on the obvious stuff.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Regarding Level/Edge of Interrupt sense values
On Mon, Feb 23, 2009 at 05:27:53PM +0530, Vijay Nikam wrote: > Hello, Sorry for the late reply; I just noticed this sitting in my inbox. > I created a device node for gpio-controller for evaluation board > mpc83313erdb. I created the dtb and loaded on target and the interrupt > is generated successfully. > > But in dts at interrupts = <74 0x2> I set sense as Edge (sense== 2: > Edge, high-to-low change), when I load the driver module and checked > the entry in /proc/interrupts it shows the sense as Level i.e. 8 > (sense == 8: Level, low assertion) as follows; > > 74: 1 IPIC Level gpio Internal interrupts are inherently level-triggered. The sense/trigger of the gpio interrupt itself (as configured in the IPIC) has nothing to do with the sense/trigger of the gpio *pin* (as configured in the GPIO block). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Set error_state to pci_channel_io_normal in eeh_report_reset()
While adding native EEH support to Emulex and Qlogic drivers, it was discovered that dev->error_state was set to pci_io_channel_normal too late in the recovery process. These drivers rely on error_state to determine if they can access the device in their slot_reset callback, thus error_state needs to be set to pci_io_channel_norm in eeh_report_reset(). Below is a detailed explanation (courtesy of Richard Lary) as to why this is necessary. Background: PCI MMIO or DMA accesses to a frozen slot generate additional EEH errors. If the number of additional EEH errors exceeds EEH_MAX_FAILS the adapter will be shutdown. To avoid triggering excessive EEH errors and an undesirable adapter shutdown, some drivers use the pci_channel_offline(dev) wrapper function to return a Boolean value based on the value of pci_dev->error_state to determine if PCI MMIO or DMA accesses are safe. If the wrapper returns TRUE, drivers must not make PCI MMIO or DMA access to their hardware. The pci_dev structure member error_state reflects one of three values, 1) pci_channel_io_normal, 2) pci_channel_io_frozen, 3) pci_channel_io_perm_failure. Function pci_channel_offline(dev) returns TRUE if error_state is pci_channel_io_frozen or pci_channel_io_perm_failure. The EEH driver sets pci_dev->error_state to pci_channel_io_frozen at the point where the PCI slot is frozen. Currently, the EEH driver restores dev->error_state to pci_channel_io_normal in eeh_report_resume() before calling the driver's resume callback. However, when the EEH driver calls the driver's slot_reset callback() from eeh_report_reset(), it incorrectly indicates the error state is still pci_channel_io_frozen. Waiting until eeh_report_resume() to restore dev->error_state to pci_channel_io_normal is too late for Emulex and QLogic FC drivers and any other drivers which are designed to use common code paths in these two cases: i) those called after the driver's slot_reset callback() and ii) those called after the PCI slot is frozen but before the driver's slot_reset callback is called. Case i) all driver paths executed to reinitialize the hardware after a reset and case ii) all code paths executed by driver kernel threads that run asynchronous to the main driver thread, such as interrupt handlers and worker threads to process driver work queues. Emulex and QLogic FC drivers are designed with common code paths which require that pci_channel_offline(dev) reflect the true state of the hardware. The state transitions that the hardware takes from Normal Operations to Slot Frozen to Reset to Normal Operations are documented in the Power Architecture™ Platform Requirements+ (PAPR+) in Table 75. PE State Control. PAPR defines the following 3 states: 0 -- Not reset, Not EEH stopped, MMIO load/store allowed, DMA allowed (Normal Operations) 1 -- Reset, Not EEH stopped, MMIO load/store disabled, DMA disabled 2 -- Not reset, EEH stopped, MMIO load/store disabled, DMA disabled (Slot Frozen) An EEH error places the slot in state 2 (Frozen) and the adapter driver is notified that an EEH error was detected. If the adapter driver returns PCI_ERS_RESULT_NEED_RESET, the EEH driver calls eeh_reset_device() to place the slot into state 1 (Reset) and eeh_reset_device completes by placing the slot into State 0 (Normal Operations). Upon return from eeh_reset_device(), the EEH driver calls eeh_report_reset, which then calls the adapter's slot_reset callback. At the time the adapter's slot_reset callback is called, the true state of the hardware is Normal Operations and should be accurately reflected by setting dev->error_state to pci_channel_io_normal. The current implementation of EEH driver does not do so and requires the following patch to correct this deficiency. Signed-off-by: Mike Mason diff --git a/arch/powerpc/platforms/pseries/eeh_driver.c b/arch/powerpc/platforms/pseries/eeh_driver.c index 380420f..9a2a6e3 100644 --- a/arch/powerpc/platforms/pseries/eeh_driver.c +++ b/arch/powerpc/platforms/pseries/eeh_driver.c @@ -182,6 +182,8 @@ static void eeh_report_reset(struct pci_dev *dev, void *userdata) if (!driver) return; + dev->error_state = pci_channel_io_normal; + eeh_enable_irq(dev); if (!driver->err_handler || ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
The problem is that GCC does not give an error (only a warning)
even for
things like this where it should be trivial to detect that the
usage *is*
uninitialized, not just might be:
int foo(void)
{
int a;
return a;
}
The compiler must not reject this code, because the undefined
behavior
only occurs if executed. There is no constraint violated.
Fine (though GCC could have something similar to -Werror but more
limited in scope to the really serious stuff that *should* be
illegal even if it isn't), but it should at least be a separate
warning class.
My point was to counter Segher's assertion that the compiler
currently gives an error on the obvious stuff.
I never said that, or didn't intend to anyway; what I was trying to say
is that the compiler makes a difference between cases where it knows
something is uninitialized vs. cases where it cannot prove either way:
$ cat mm.c
int bork(void)
{
int a;
return a;
}
int main(void)
{
return bork();
}
$ powerpc-linux-gcc -Wall -W -Os -c mm.c
mm.c: In function 'bork':
mm.c:5: warning: 'a' is used uninitialized in this function
Note: _is_ used uninitialized, not "may be" like in cases where the
compiler
isn't sure.
I don't know why this isn't an error; perhaps GCC does not assume main
() to
always be executed. I don't think it could prove much anything to be
executed in non-toy examples, anyway.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
And further, there is no separation of warning classes into might- be-uninitialized and is-uninitialized-compiler-can-tell-for-sure. Indeed. Please file a bug report. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [V2] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
From: Suneel
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel
Signed-off-by: John Linn
---
V2 - Incorporated comments from Josh, Grant and others
drivers/video/xilinxfb.c | 213 --
1 files changed, 150 insertions(+), 63 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..d151237 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,13 +1,13 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed "as is" without any warranty of any
@@ -31,27 +31,31 @@
#include
#include
#include
-#if defined(CONFIG_OF)
#include
#include
-#endif
-#include
+#include
#include
#include
#define DRIVER_NAME"xilinxfb"
-#define DRIVER_DESCRIPTION "Xilinx TFT LCD frame buffer driver"
+
/*
* Xilinx calls it "PLB TFT LCD Controller" though it can also be used for
- * the VGA port on the Xilinx ML40x board. This is a hardware display
controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a 640x480 resolution TFT or VGA screen.
*
* The interface to the framebuffer is nice and simple. There are two
* control registers. The first tells the LCD interface where in memory
* the frame buffer is (only the 11 most significant bits are used, so
* don't start thinking about scrolling). The second allows the LCD to
* be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
*/
#define NUM_REGS 2
#define REG_FB_ADDR0
@@ -108,10 +112,18 @@ static struct fb_var_screeninfo xilinx_fb_var = {
.activate = FB_ACTIVATE_NOW
};
+
+#define PLB_ACCESS_FLAG0x1 /* 1 = PLB, 0 = DCR */
+
struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ phys_addr_t regs_phys; /* phys. address of the control
+ registers */
+ void __iomem*regs; /* virt. address of the control
+ registers */
+
dcr_host_t dcr_host;
unsigned intdcr_start;
unsigned intdcr_len;
@@ -120,6 +132,8 @@ struct xilinxfb_drvdata {
dma_addr_t fb_phys;/* phys. address of the frame buffer */
int fb_alloced; /* Flag, was the fb memory alloced? */
+ u8 flags; /* features of the driver */
+
u32 reg_ctrl_default;
u32 pseudo_palette[PALETTE_ENTRIES_NO];
@@ -130,14 +144,19 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple to add the direct DCR access
- * when it's needed.
+ * The XPS TFT Controller can be accessed through PLB or DCR interface.
+ * To perform the read/write on the registers we need to check on
+ * which bus its connected and call the appropriate write API.
*/
-#define xilinx_fb_out_be32(driverdata, offset, val) \
- dcr_write(driverdata->dcr_host, offset, val)
+static void xilinx_fb_out_be32(struct xilinxfb_drvdata *drvdata, u32 offset,
+ u32 val)
+{
+ if (drvdata->flags & PLB_ACCESS_FLAG)
+ out_be32(drvdata->regs + (offset << 2), val);
+ else
+ dcr_write(drvdata->dcr_host, offset, val);
+
+}
static int
xilinx_fb_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned
blue,
@@ -175,7 +194,8 @@ xilinx_fb_blank(int blank_mode, struct fb_info *fbi)
switch (blank_mode) {
case FB_BLANK_UNBLANK:
/* turn on panel */
- xilinx_fb_out_be32(drvdata, REG_CTRL,
drvdata->reg_ctrl_default);
+ xilinx_fb_out_be32(drvdata, REG_CTRL,
+ drvdata->reg_ctrl_default);
break;
case FB
Re: bug in drivers/edac/mpc85xx_edac.c:mpc85xx_mc_check() ?
(cc's added)
On Wed, 8 Apr 2009 14:57:42 -0700
"Jeff Haran" wrote:
> Hi,
>
> Recent versions of this function start off with:
>
> static void mpc85xx_mc_check(struct mem_ctl_info *mci)
> {
> struct mpc85xx_mc_pdata *pdata = mci->pvt_info;
> ...
>
> err_detect = in_be32(pdata->mc_vbase + MPC85XX_MC_ERR_DETECT);
> if (err_detect)
> return;
>
> ...
> }
>
> My reading of the Freescale 8548E Manual leads me to conclude that the
> Memory Error Detect register (ERR_DETECT) will have various bits set if
> the memory controller has detected an error since the last time it was
> cleared. If no memory error has occurred, the register will contain 0.
>
> Perhaps I am missing something very basic, but it seem to me that the
> above "if" should be:
>
> if (!err_detect)
> return;
>
> as the existing code would seem to read "if any errors have occurred,
> ignore them", though perhaps testing has demonstrated that the Freescale
> manual is in error.
>
> Please include this email address in responses as I do not subscribe.
>
> Thanks,
>
> Jeff Haran
> Brocade
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
Segher Boessenkool wrote: And further, there is no separation of warning classes into might-be-uninitialized and is-uninitialized-compiler-can-tell-for-sure. Indeed. Please file a bug report. Done: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39731 -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
