* [Bug 44852] 3D Acceleration initialization failed for Fusion Wrestler 9808
From: bugzilla-daemon @ 2012-01-17 9:31 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-44852-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=44852
--- Comment #5 from Michel Dänzer <michel@daenzer.net> 2012-01-17 01:31:54 PST ---
(In reply to comment #3)
> Created attachment 55665 [details]
> dmesg
There's no trace of the radeon kernel module being loaded. Does the kernel have
the fix from bug 43739?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH] mac80211: clean up aggregation destruction
From: Johannes Berg @ 2012-01-17 9:31 UTC (permalink / raw)
To: John Linville; +Cc: Yogesh Ashok Powar, linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
Yogesh's patch to destroy aggregation sessions when
stations are destroyed was needed, but unnecessarily
complex. Clean up this code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
(resent to include the list)
net/mac80211/sta_info.c | 31 ++++++++-----------------------
1 file changed, 8 insertions(+), 23 deletions(-)
--- a/net/mac80211/sta_info.c 2012-01-17 10:23:59.000000000 +0100
+++ b/net/mac80211/sta_info.c 2012-01-17 10:28:14.000000000 +0100
@@ -763,35 +763,20 @@ int __must_check __sta_info_destroy(stru
}
#endif
- /* There could be some memory leaks because of ampdu tx pending queue
- * not being freed before destroying the station info.
- *
- * Make sure that such queues are purged before freeing the station
- * info.
- * TODO: We have to somehow postpone the full destruction
- * until the aggregation stop completes. Refer
- * http://thread.gmane.org/gmane.linux.kernel.wireless.general/81936
+ /*
+ * Destroy aggregation state here. It would be nice to wait for the
+ * driver to finish aggregation stop and then clean up, but for now
+ * drivers have to handle aggregation stop being requested, followed
+ * directly by station destruction.
*/
-
- mutex_lock(&sta->ampdu_mlme.mtx);
-
for (i = 0; i < STA_TID_NUM; i++) {
- tid_tx = rcu_dereference_protected_tid_tx(sta, i);
+ tid_tx = rcu_dereference_raw(sta->ampdu_mlme.tid_tx[i]);
if (!tid_tx)
continue;
- if (skb_queue_len(&tid_tx->pending)) {
-#ifdef CONFIG_MAC80211_HT_DEBUG
- wiphy_debug(local->hw.wiphy, "TX A-MPDU purging %d "
- "packets for tid=%d\n",
- skb_queue_len(&tid_tx->pending), i);
-#endif /* CONFIG_MAC80211_HT_DEBUG */
- __skb_queue_purge(&tid_tx->pending);
- }
- kfree_rcu(tid_tx, rcu_head);
+ __skb_queue_purge(&tid_tx->pending);
+ kfree(tid_tx);
}
- mutex_unlock(&sta->ampdu_mlme.mtx);
-
sta_info_free(local, sta);
return 0;
^ permalink raw reply
* Re: Driver domains and hotplug scripts, redux
From: Roger Pau Monné @ 2012-01-17 9:30 UTC (permalink / raw)
To: Ian Campbell
Cc: xen-devel@lists.xensource.com, Ian Jackson, Stefano Stabellini
In-Reply-To: <1326791863.14689.52.camel@zakaz.uk.xensource.com>
2012/1/17 Ian Campbell <Ian.Campbell@citrix.com>:
> On Mon, 2012-01-16 at 17:58 +0000, Ian Jackson wrote:
>> Roger Pau Monné writes ("Re: [Xen-devel] Driver domains and hotplug scripts, redux"):
>> > 2012/1/12 Ian Jackson <Ian.Jackson@eu.citrix.com>:
>> > > Ian Campbell writes ("Re: [Xen-devel] Driver domains and hotplug scripts, redux"):
>> > >> The forceful destroy case is different, it is effectively:
>> > >> 1. rm backend dir in xenstore.
>> > >
>> > > That's (iii). We want a way to do (ii) as well.
>> >
>> > From my point of view, (iii) should only happen after (i) or (ii) has
>> > failed (timeout or error trying to unplug devices).
>>
>> There has to be a user option to ask for a "very forceful" detach.
>>
>> > What should we do with xend? Are we keeping it on 4.2? I'm asking this
>> > because the changes I'm introducing disables some udev rules that are
>> > needed for xend. The other option is to update xend to talk to
>> > xenbackendd also.
>>
>> I think xend is not going to go away in 4.2, unfortunately.
>
> However xend should not be transition to this new scheme but should
> continue to use its existing scripts in the current manner.
>
> There was a conversation last year[0] about how a toolstack could
> opt-in/out of the use of the hotplug scripts. We decided that toolstacks
> should have to opt into the use of these scripts, by touching a stamp
> file.
I'm not sure this solves our problems, since this doesn't disable udev
exactly, it disables hotplug scripts entirely, but they are needed
from libxl also (my approach uses the current hotplug scripts).
Also, if both xl and xend are running, there are a lot of chances of
getting a mess, since machines started from xl (using the new xenstore
protocol /hotplug/...) could not be stopped successfully from xend,
and the other way around.
> Although this wasn't implemented yet (unless I missed it) I guess the
> same scheme would apply to this work if that sort of thing turns out to
> be necessary.
>
> Ian.
>
> [0] http://lists.xen.org/archives/html/xen-devel/2011-06/msg00952.html
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [PATCH v9 3.2 7/9] tracing: uprobes trace_event interface
From: Ingo Molnar @ 2012-01-17 9:28 UTC (permalink / raw)
To: Jiri Olsa, Arnaldo Carvalho de Melo
Cc: Srikar Dronamraju, Peter Zijlstra, Linus Torvalds, Oleg Nesterov,
Andrew Morton, LKML, Linux-mm, Andi Kleen, Christoph Hellwig,
Steven Rostedt, Roland McGrath, Thomas Gleixner, Masami Hiramatsu,
Arnaldo Carvalho de Melo, Anton Arapov,
Ananth N Mavinakayanahalli, Jim Keniston, Stephen Rothwell
In-Reply-To: <20120116131137.GB5265@m.brq.redhat.com>
* Jiri Olsa <jolsa@redhat.com> wrote:
> I've tested following event:
> echo "p:probe_libc/free /lib64/libc-2.13.so:0x7a4f0 %ax" > ./uprobe_events
>
> and commands like:
> perf record -a -e probe_libc:free --filter "common_pid == 1127"
> perf record -e probe_libc:free --filter "arg1 == 0xa" ls
>
> got me proper results.
Btw., Srikar, if that's the primary UI today then we'll need to
make it a *lot* more user-friendly than the above usage
workflow.
In particular this line:
> echo "p:probe_libc/free /lib64/libc-2.13.so:0x7a4f0 %ax" > ./uprobe_events
is not something a mere mortal will be able to figure out.
There needs to be perf probe integration, that allows intuitive
usage, such as:
perf probe add libc:free
Using the perf symbols code it should first search a libc*so DSO
in the system, finding say /lib64/libc-2.15.so. The 'free'
symbol is readily available there:
aldebaran:~> eu-readelf -s /lib64/libc-2.15.so | grep ' free$'
7186: 00000039ff47f080 224 FUNC GLOBAL DEFAULT 12 free
then the tool can automatically turn that symbol information
into the specific probe.
Will it all work with DSO randomization, prelinking and default
placement as well?
Users should not be expected to enter magic hexa numbers to get
a trivial usecase going ...
this bit:
> perf record -a -e probe_libc:free --filter "common_pid == 1127"
> perf record -e probe_libc:free --filter "arg1 == 0xa" ls
looks good and intuitive and 'perf list' should list all the
available uprobes.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v9 3.2 7/9] tracing: uprobes trace_event interface
From: Ingo Molnar @ 2012-01-17 9:28 UTC (permalink / raw)
To: Jiri Olsa, Arnaldo Carvalho de Melo
Cc: Srikar Dronamraju, Peter Zijlstra, Linus Torvalds, Oleg Nesterov,
Andrew Morton, LKML, Linux-mm, Andi Kleen, Christoph Hellwig,
Steven Rostedt, Roland McGrath, Thomas Gleixner, Masami Hiramatsu,
Arnaldo Carvalho de Melo, Anton Arapov,
Ananth N Mavinakayanahalli, Jim Keniston, Stephen Rothwell
In-Reply-To: <20120116131137.GB5265@m.brq.redhat.com>
* Jiri Olsa <jolsa@redhat.com> wrote:
> I've tested following event:
> echo "p:probe_libc/free /lib64/libc-2.13.so:0x7a4f0 %ax" > ./uprobe_events
>
> and commands like:
> perf record -a -e probe_libc:free --filter "common_pid == 1127"
> perf record -e probe_libc:free --filter "arg1 == 0xa" ls
>
> got me proper results.
Btw., Srikar, if that's the primary UI today then we'll need to
make it a *lot* more user-friendly than the above usage
workflow.
In particular this line:
> echo "p:probe_libc/free /lib64/libc-2.13.so:0x7a4f0 %ax" > ./uprobe_events
is not something a mere mortal will be able to figure out.
There needs to be perf probe integration, that allows intuitive
usage, such as:
perf probe add libc:free
Using the perf symbols code it should first search a libc*so DSO
in the system, finding say /lib64/libc-2.15.so. The 'free'
symbol is readily available there:
aldebaran:~> eu-readelf -s /lib64/libc-2.15.so | grep ' free$'
7186: 00000039ff47f080 224 FUNC GLOBAL DEFAULT 12 free
then the tool can automatically turn that symbol information
into the specific probe.
Will it all work with DSO randomization, prelinking and default
placement as well?
Users should not be expected to enter magic hexa numbers to get
a trivial usecase going ...
this bit:
> perf record -a -e probe_libc:free --filter "common_pid == 1127"
> perf record -e probe_libc:free --filter "arg1 == 0xa" ls
looks good and intuitive and 'perf list' should list all the
available uprobes.
Thanks,
Ingo
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC 1/3] /dev/low_mem_notify
From: Pekka Enberg @ 2012-01-17 9:27 UTC (permalink / raw)
To: Minchan Kim
Cc: linux-mm, LKML, leonid.moiseichuk, kamezawa.hiroyu, Rik van Riel,
mel, rientjes, KOSAKI Motohiro, Johannes Weiner, Marcelo Tosatti,
Andrew Morton, Ronen Hod, KOSAKI Motohiro
In-Reply-To: <1326788038-29141-2-git-send-email-minchan@kernel.org>
On Tue, Jan 17, 2012 at 10:13 AM, Minchan Kim <minchan@kernel.org> wrote:
> +static unsigned int low_mem_notify_poll(struct file *file, poll_table *wait)
> +{
> + unsigned int ret = 0;
> +
> + poll_wait(file, &low_mem_wait, wait);
> +
> + if (atomic_read(&nr_low_mem) != 0) {
> + ret = POLLIN;
> + atomic_set(&nr_low_mem, 0);
> + }
> +
> + return ret;
> +}
Doesn't this mean that only one application will receive the notification?
Pekka
^ permalink raw reply
* Re: [RFC 1/3] /dev/low_mem_notify
From: Pekka Enberg @ 2012-01-17 9:27 UTC (permalink / raw)
To: Minchan Kim
Cc: linux-mm, LKML, leonid.moiseichuk, kamezawa.hiroyu, Rik van Riel,
mel, rientjes, KOSAKI Motohiro, Johannes Weiner, Marcelo Tosatti,
Andrew Morton, Ronen Hod, KOSAKI Motohiro
In-Reply-To: <1326788038-29141-2-git-send-email-minchan@kernel.org>
On Tue, Jan 17, 2012 at 10:13 AM, Minchan Kim <minchan@kernel.org> wrote:
> +static unsigned int low_mem_notify_poll(struct file *file, poll_table *wait)
> +{
> + unsigned int ret = 0;
> +
> + poll_wait(file, &low_mem_wait, wait);
> +
> + if (atomic_read(&nr_low_mem) != 0) {
> + ret = POLLIN;
> + atomic_set(&nr_low_mem, 0);
> + }
> +
> + return ret;
> +}
Doesn't this mean that only one application will receive the notification?
Pekka
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC PATCH 1/2] KVM: PPC: Book3S HV: Make virtual processor area registration more robust
From: Alexander Graf @ 2012-01-17 9:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org, kvm-ppc@vger.kernel.org
In-Reply-To: <20120117055654.GB9170@drongo>
On 17.01.2012, at 06:56, Paul Mackerras <paulus@samba.org> wrote:
> On Mon, Jan 16, 2012 at 02:04:29PM +0100, Alexander Graf wrote:
>>
>> On 20.12.2011, at 11:22, Paul Mackerras wrote:
>
>>> @@ -152,6 +152,8 @@ static unsigned long do_h_register_vpa(struct kvm_vcpu *vcpu,
>>> flags &= 7;
>>> if (flags = 0 || flags = 4)
>>
>> This could probably use a new variable name. Also, what do 0 and 4 mean? Constant defines would be nice here.
>
> Those constants are defined in PAPR as being a subfunction code
> indicating what sort of area and whether it is to be registered or
> unregistered. I'll make up some names for them.
>
>> [pasted from real source]
>>> va = kvmppc_pin_guest_page(kvm, vpa, &nb);
>>
>> Here you're pinning the page, setting va to that temporarily available address.
>
> Well, it's not just temporarily available, it's available until we
> unpin it, since we increment the page count, which inhibits migration.
>
>>> len = *(unsigned int *)(va + 4);
>>
>> va + 4 isn't really descriptive. Is this a defined struct? Why not actually define one which you can just read data from? Or at least make this a define too. Reading random numbers in code is barely readable.
>
> It's not really a struct, at least not one that is used for anything
> else. PAPR defines that the length of the buffer has to be placed in
> the second 32-bit word at registration time.
>
>>
>>> + free_va = va;
>>
>> Now free_va is the temporarily available address.
> ...
>>> + free_va = tvcpu->arch.next_vpa;
>>> + tvcpu->arch.next_vpa = va;
>>
>> Now you're setting next_vpa to this temporarily available address? But next_vpa will be used after va is getting free'd, no? Or is that why you have free_va?
>
> Yes; here we are freeing any previously-set value of next_vpa. The
> idea of free_va is that it is initially set to va so that we correctly
> unpin va if any error occurs. But if there is no error, va gets put
> into next_vpa and we free anything that was previously in next_vpa
> instead.
>
>>
>> Wouldn't it be easier to just map it every time we actually use it and only shove the GPA around? We could basically save ourselves a lot of the logic here.
>
> There are fields in the VPA that we really want to be able to access
> from real mode, for instance the fields that indicate whether we need
> to save the FPR and/or VR values. As far as the DTL is concerned, we
> could in fact use copy_to_user to access it, so it doesn't strictly
> need to be pinned. We don't currently use the slb_shadow buffer, but
> if we did we would need to access it from real mode, since we would be
> reading it in order to set up guest SLB entries.
>
> The other thing is that the VPA registration/unregistration is only
> done a few times in the life of the guest, whereas we use the VPAs
> constantly while the guest is running. So it is more efficient to do
> more of the work at registration time to make it quicker to access the
> VPAs.
The thing I was getting at was not the map during the lifetime, but the map during registration. Currently we have:
1) Set VPA to x
2) Assign feature y to VPA
3) Use VPA
1 and 2 are the slow path, 3 occurs more frequently. So we want 3 to be fast. 1 and 2 don't matter that much wrt performance.
You are currently mapping the VPA at /, which gets you into this map/unmap mess trying to free the previous mapping. If you moved the map to step 2 and only stored the GPA at step 1, all map+unmap operations except for final unmaps would be in one spot, so you wouldn't need to construct this big complex state machine.
I hope that makes it more clear :)
Alex
>
> I'll send revised patches. There's a small change I want to make to
> patch 2 to avoid putting a very large stolen time value in the first
> entry that gets put in after the DTL is registered, which can happen
> currently if the DTL gets registered some time after the guest started
> running.
>
> Paul.
^ permalink raw reply
* Re: Updated btrfs/crypto snappy interface ready for merging
From: Li Zefan @ 2012-01-17 9:27 UTC (permalink / raw)
To: Andi Kleen; +Cc: Chris Mason, linux-kernel, linux-btrfs
In-Reply-To: <20120117084650.GP11715@one.firstfloor.org>
Andi Kleen wrote:
>> It's because decompressing inline extents always fails. I've fixed it
>> and will send the patch out in a new mail thread.
>
> Thanks for fixing.
>
>>
>> But seems there's bug in lib snappy code, which makes the decompressed
>> data doesn't quite match the original data.
>>
>> Simply copy a file to a btrfs filesystem with snappy enabled, and clear
>> page cache, and check the file:
>
> Hmm weird, I have never seen this. Do you have a reproducer?
>
> The basic compression code is quite well tested, I have a reasonable
> unit test.
>
At first I saved emails and patched them in linux-btrfs git tree, and I
got weired result. Then I pulled the snappy branch directly, and now
nothing is wrong.. Sorry for the noise.
^ permalink raw reply
* Re: [RFC PATCH 1/2] KVM: PPC: Book3S HV: Make virtual processor area registration more robust
From: Alexander Graf @ 2012-01-17 9:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org, kvm-ppc@vger.kernel.org
In-Reply-To: <20120117055654.GB9170@drongo>
On 17.01.2012, at 06:56, Paul Mackerras <paulus@samba.org> wrote:
> On Mon, Jan 16, 2012 at 02:04:29PM +0100, Alexander Graf wrote:
>>=20
>> On 20.12.2011, at 11:22, Paul Mackerras wrote:
>=20
>>> @@ -152,6 +152,8 @@ static unsigned long do_h_register_vpa(struct kvm_vc=
pu *vcpu,
>>> flags &=3D 7;
>>> if (flags =3D=3D 0 || flags =3D=3D 4)
>>=20
>> This could probably use a new variable name. Also, what do 0 and 4 mean? C=
onstant defines would be nice here.
>=20
> Those constants are defined in PAPR as being a subfunction code
> indicating what sort of area and whether it is to be registered or
> unregistered. I'll make up some names for them.
>=20
>> [pasted from real source]
>>> va =3D kvmppc_pin_guest_page(kvm, vpa, &nb);
>>=20
>> Here you're pinning the page, setting va to that temporarily available ad=
dress.
>=20
> Well, it's not just temporarily available, it's available until we
> unpin it, since we increment the page count, which inhibits migration.
>=20
>>> len =3D *(unsigned int *)(va + 4);
>>=20
>> va + 4 isn't really descriptive. Is this a defined struct? Why not actual=
ly define one which you can just read data from? Or at least make this a def=
ine too. Reading random numbers in code is barely readable.
>=20
> It's not really a struct, at least not one that is used for anything
> else. PAPR defines that the length of the buffer has to be placed in
> the second 32-bit word at registration time.
>=20
>>=20
>>> + free_va =3D va;
>>=20
>> Now free_va is the temporarily available address.
> ...
>>> + free_va =3D tvcpu->arch.next_vpa;
>>> + tvcpu->arch.next_vpa =3D va;
>>=20
>> Now you're setting next_vpa to this temporarily available address? But ne=
xt_vpa will be used after va is getting free'd, no? Or is that why you have f=
ree_va?
>=20
> Yes; here we are freeing any previously-set value of next_vpa. The
> idea of free_va is that it is initially set to va so that we correctly
> unpin va if any error occurs. But if there is no error, va gets put
> into next_vpa and we free anything that was previously in next_vpa
> instead.
>=20
>>=20
>> Wouldn't it be easier to just map it every time we actually use it and on=
ly shove the GPA around? We could basically save ourselves a lot of the logi=
c here.
>=20
> There are fields in the VPA that we really want to be able to access
> from real mode, for instance the fields that indicate whether we need
> to save the FPR and/or VR values. As far as the DTL is concerned, we
> could in fact use copy_to_user to access it, so it doesn't strictly
> need to be pinned. We don't currently use the slb_shadow buffer, but
> if we did we would need to access it from real mode, since we would be
> reading it in order to set up guest SLB entries.
>=20
> The other thing is that the VPA registration/unregistration is only
> done a few times in the life of the guest, whereas we use the VPAs
> constantly while the guest is running. So it is more efficient to do
> more of the work at registration time to make it quicker to access the
> VPAs.
The thing I was getting at was not the map during the lifetime, but the map d=
uring registration. Currently we have:
1) Set VPA to x
2) Assign feature y to VPA
3) Use VPA
1 and 2 are the slow path, 3 occurs more frequently. So we want 3 to be fast=
. 1 and 2 don't matter that much wrt performance.
You are currently mapping the VPA at /, which gets you into this map/unmap m=
ess trying to free the previous mapping. If you moved the map to step 2 and o=
nly stored the GPA at step 1, all map+unmap operations except for final unma=
ps would be in one spot, so you wouldn't need to construct this big complex s=
tate machine.
I hope that makes it more clear :)
Alex
>=20
> I'll send revised patches. There's a small change I want to make to
> patch 2 to avoid putting a very large stolen time value in the first
> entry that gets put in after the DTL is registered, which can happen
> currently if the DTL gets registered some time after the guest started
> running.
>=20
> Paul.
^ permalink raw reply
* RE: [PATCH] mpt2sas: New feature - Fast Load Support - scsi_mod.scan=sync drops drive
From: Nandigama, Nagalakshmi @ 2012-01-17 9:26 UTC (permalink / raw)
To: André-Sebastian Liebe, Desai, Kashyap
Cc: linux-scsi@vger.kernel.org, Thakkar, Vishal
In-Reply-To: <4F13DA75.5090703@lianse.eu>
[-- Attachment #1: Type: text/plain, Size: 3653 bytes --]
Andre,
Request you to apply the attached patch to 3.2 kernel and test.
Regards,
Nagalakshmi
-----Original Message-----
From: André-Sebastian Liebe [mailto:andre@lianse.eu]
Sent: Monday, January 16, 2012 1:36 PM
To: Desai, Kashyap
Cc: linux-scsi@vger.kernel.org; Nandigama, Nagalakshmi; Thakkar, Vishal
Subject: Re: [PATCH] mpt2sas: New feature - Fast Load Support - scsi_mod.scan=sync drops drive
Hi guys,
sorry for the late reply, I haven't had the chance to reboot the system earlier. But here are the logs for both scan types.
-andre
On 12.01.2012 07:30, Desai, Kashyap wrote:
> Andre,
>
> Can you enable mpt2sas driver log level to 0x38c and re-send the
> driver logs in case of "scsi_mod.scan=sync"
>
> You need to pass boot time parameter mpt2sas.logging_level=0x38c
>
> ` Kashyap
>
>> -----Original Message-----
>> From: André-Sebastian Liebe [mailto:andre@lianse.eu]
>> Sent: Wednesday, January 11, 2012 2:17 PM
>> To: Desai, Kashyap
>> Cc: linux-scsi@vger.kernel.org
>> Subject: Re: [PATCH] mpt2sas: New feature - Fast Load Support -
>> scsi_mod.scan=sync drops drive
>>
>> Tanks for your suggestion Kashyap!
>>
>> I've tried it out but ran directly into an other problem. With
>> scsi_mod.scan=sync the hba reported all 4 drives correctly but
>> dropped one of it instantaneously. So I'm either stuck with kernel
>> 3.1 and all booting up correctly or using 3.2 and manually mounting
>> the drives behind the hba and starting the services depending on them thereafter.
>>
>> I've attached parts of the kernel log with scsi_mod.sync parameter
>> set to sync/async
>>
>> -andre
>>
>>
>> On 10.01.2012 11:53, Desai, Kashyap wrote:
>>> There is a some scsi_mod parameter called "scan".
>>> If you pass those parameter at boot time you can change the behavior.
>>> (see below description)
>>>
>>> scsi_mod.scan= [SCSI] sync (default) scans SCSI busses as they
>> are
>>> discovered. Async scans them in kernel threads, allowing
>> boot to proceed.
>>> none ignores them, expecting user space to do the scan.
>>>
>>> ~ Kashyap
>>>
>>>> -----Original Message-----
>>>> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
>>>> owner@vger.kernel.org] On Behalf Of André-Sebastian Liebe
>>>> Sent: Tuesday, January 10, 2012 2:18 PM
>>>> To: linux-scsi@vger.kernel.org
>>>> Subject: Re: [PATCH] mpt2sas: New feature - Fast Load Support
>>>>
>>> Hi guys,
>>>
>>> I've run into problems with the all new shiny 3.2 kernel. My system
>>> broke badly as it's depending on some devices which are attached to
>>> my LSI SAS 2008 hba.
>>> The mount scripts of my gentoo/openrc setup get triggered right
>>> after udev has settled. But with the new fast load support udev
>>> settles before my drives appear to the system, so mount fails for
>>> all those drives and of cause all subsequent services depending on them.
>>> Is there any switch to revert back to the old behavior of blocking
>>> until all ports scans are done?
>>>
>>> Thanks in advance
>>> André-Sebastian Liebe
>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi"
>>>> in the body of a message to majordomo@vger.kernel.org More
>>>> majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> --
>> gpg key AA1E1F66 @ gpg-keyserver.de: André-Sebastian Liebe
>> <andre@lianse.eu> Key fingerprint = 5436 5358 172C EB7D E414 C6DE
>> 6664 89BF AA1E 1F66
--
gpg key AA1E1F66 @ gpg-keyserver.de: André-Sebastian Liebe <andre@lianse.eu> Key fingerprint = 5436 5358 172C EB7D E414 C6DE 6664 89BF AA1E 1F66
[-- Attachment #2: scsi-misc-2[1].6.git-2cb6fc8c014b9b00c4487a79b8f6ed0da4121f45.patch --]
[-- Type: application/octet-stream, Size: 3221 bytes --]
From 2cb6fc8c014b9b00c4487a79b8f6ed0da4121f45 Mon Sep 17 00:00:00 2001
From: "nagalakshmi.nandigama@lsi.com" <nagalakshmi.nandigama@lsi.com>
Date: Tue, 13 Dec 2011 09:29:15 +0530
Subject: [PATCH] [SCSI] mpt2sas: Removed redundant calling of
_scsih_probe_devices() from _scsih_probe
Removed redundant calling of _scsih_probe_devices() from _scsih_probe as
it is getting called from _scsih_scan_finished.
Also moved the function scsi_scan_host(shost) to get called after the
volumes on warp drive are reported to the OS. Otherwise by the time
the (ioc->hide_drives) flags is set, the volumes on warp drive
are reported to the OS already.
Also modified the initialization of reply queues only in case of driver load
time in the function _base_make_ioc_operational().
Signed-off-by: Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 20 +++++++-------------
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 3 +--
2 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c b/drivers/scsi/mpt2sas/mpt2sas_base.c
index 4819181..0b2c955 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -4099,7 +4099,8 @@ _base_make_ioc_operational(struct MPT2SAS_ADAPTER *ioc, int sleep_flag)
ioc->reply_free[i] = cpu_to_le32(reply_address);
/* initialize reply queues */
- _base_assign_reply_queues(ioc);
+ if (ioc->is_driver_loading)
+ _base_assign_reply_queues(ioc);
/* initialize Reply Post Free Queue */
reply_post_free = (long)ioc->reply_post_free;
@@ -4147,24 +4148,17 @@ _base_make_ioc_operational(struct MPT2SAS_ADAPTER *ioc, int sleep_flag)
if (ioc->is_driver_loading) {
-
-
-
- ioc->wait_for_discovery_to_complete =
- _base_determine_wait_on_discovery(ioc);
- return r; /* scan_start and scan_finished support */
- }
-
-
- if (ioc->wait_for_discovery_to_complete && ioc->is_warpdrive) {
- if (ioc->manu_pg10.OEMIdentifier == 0x80) {
+ if (ioc->is_warpdrive && ioc->manu_pg10.OEMIdentifier
+ == 0x80) {
hide_flag = (u8) (ioc->manu_pg10.OEMSpecificFlags0 &
MFG_PAGE10_HIDE_SSDS_MASK);
if (hide_flag != MFG_PAGE10_HIDE_SSDS_MASK)
ioc->mfg_pg10_hide_flag = hide_flag;
}
+ ioc->wait_for_discovery_to_complete =
+ _base_determine_wait_on_discovery(ioc);
+ return r; /* scan_start and scan_finished support */
}
-
r = _base_send_port_enable(ioc, sleep_flag);
if (r)
return r;
diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
index 8cd4ebb..193e33e 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@ -8039,7 +8039,6 @@ _scsih_probe(struct pci_dev *pdev, const struct pci_device_id *id)
goto out_attach_fail;
}
- scsi_scan_host(shost);
if (ioc->is_warpdrive) {
if (ioc->mfg_pg10_hide_flag == MFG_PAGE10_EXPOSE_ALL_DISKS)
ioc->hide_drives = 0;
@@ -8053,8 +8052,8 @@ _scsih_probe(struct pci_dev *pdev, const struct pci_device_id *id)
}
} else
ioc->hide_drives = 0;
+ scsi_scan_host(shost);
- _scsih_probe_devices(ioc);
return 0;
out_attach_fail:
--
1.7.6.5
^ permalink raw reply related
* Re: [PATCH 1/3]: Store SRAT revision
From: Len Brown @ 2012-01-17 9:24 UTC (permalink / raw)
To: Kurt Garloff, linux-kernel, linux-acpi, Luck, Tony, x86
In-Reply-To: <20120115213407.GU12380@tpkurt2.garloff.de>
looks fine to me.
as #2 (x86) and #3 (ia64) depend on #1, which is ACPI,
I can send this via the ACPI tree.
thanks,
-Len Brown, Intel Open Source Technology Center
^ permalink raw reply
* [PATCH] Btrfs: fix enospc error caused by wrong checks of the chunk allocation
From: Miao Xie @ 2012-01-17 9:24 UTC (permalink / raw)
To: Chris Mason; +Cc: Linux Btrfs
When we did sysbench test for inline files, enospc error happened easily though
there was lots of free disk space which could be allocated for new chunks.
Reproduce steps:
# mkfs.btrfs -b $((2 * 1024 * 1024 * 1024)) <test partition>
# mount <test partition> /mnt
# ulimit -n 102400
# cd /mnt
# sysbench --num-threads=1 --test=fileio --file-num=81920 \
> --file-total-size=80M --file-block-size=1K --file-io-mode=sync \
> --file-test-mode=seqwr prepare
# sysbench --num-threads=1 --test=fileio --file-num=81920 \
> --file-total-size=80M --file-block-size=1K --file-io-mode=sync \
> --file-test-mode=seqwr run
<soon later, BUG_ON() was triggered by enospc error>
The reason of this bug is:
Now, we can reserve space which is larger than the free space in the chunks if
we have enough free disk space which can be used for new chunks. By this way,
the space allocator should allocate a new chunk by force if there is no free
space in the free space cache. But there are two wrong checks which break this
operation.
One is
if (ret == -ENOSPC && num_bytes > min_alloc_size)
in btrfs_reserve_extent(), it is wrong, we should try to allocate a new chunk
even we fail to allocate free space by minimum allocable size.
The other is
if (space_info->force_alloc)
force = space_info->force_alloc;
in do_chunk_alloc(). It makes the allocator ignore CHUNK_ALLOC_FORCE If someone
sets ->force_alloc to CHUNK_ALLOC_LIMITED, and makes the enospc error happen.
Fix these two wrong checks. Especially the second one, we fix it by changing
the value of CHUNK_ALLOC_LIMITED and CHUNK_ALLOC_FORCE, and make
CHUNK_ALLOC_FORCE greater than CHUNK_ALLOC_LIMITED since CHUNK_ALLOC_FORCE has
higher priority. And if the value which is passed in by the caller is greater
than ->force_alloc, use the passed value.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
---
This patch is based on the new viro branch.
---
fs/btrfs/extent-tree.c | 49 ++++++++++++++++++++++++++---------------------
1 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 700879e..283af7a 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -34,23 +34,24 @@
#include "locking.h"
#include "free-space-cache.h"
-/* control flags for do_chunk_alloc's force field
+/*
+ * control flags for do_chunk_alloc's force field
* CHUNK_ALLOC_NO_FORCE means to only allocate a chunk
* if we really need one.
*
- * CHUNK_ALLOC_FORCE means it must try to allocate one
- *
* CHUNK_ALLOC_LIMITED means to only try and allocate one
* if we have very few chunks already allocated. This is
* used as part of the clustering code to help make sure
* we have a good pool of storage to cluster in, without
* filling the FS with empty chunks
*
+ * CHUNK_ALLOC_FORCE means it must try to allocate one
+ *
*/
enum {
CHUNK_ALLOC_NO_FORCE = 0,
- CHUNK_ALLOC_FORCE = 1,
- CHUNK_ALLOC_LIMITED = 2,
+ CHUNK_ALLOC_LIMITED = 1,
+ CHUNK_ALLOC_FORCE = 2,
};
/*
@@ -3414,7 +3415,7 @@ static int do_chunk_alloc(struct btrfs_trans_handle *trans,
again:
spin_lock(&space_info->lock);
- if (space_info->force_alloc)
+ if (force < space_info->force_alloc)
force = space_info->force_alloc;
if (space_info->full) {
spin_unlock(&space_info->lock);
@@ -5794,6 +5795,7 @@ int btrfs_reserve_extent(struct btrfs_trans_handle *trans,
u64 search_end, struct btrfs_key *ins,
u64 data)
{
+ bool final_tried = false;
int ret;
u64 search_start = 0;
@@ -5813,22 +5815,25 @@ again:
search_start, search_end, hint_byte,
ins, data);
- if (ret == -ENOSPC && num_bytes > min_alloc_size) {
- num_bytes = num_bytes >> 1;
- num_bytes = num_bytes & ~(root->sectorsize - 1);
- num_bytes = max(num_bytes, min_alloc_size);
- do_chunk_alloc(trans, root->fs_info->extent_root,
- num_bytes, data, CHUNK_ALLOC_FORCE);
- goto again;
- }
- if (ret == -ENOSPC && btrfs_test_opt(root, ENOSPC_DEBUG)) {
- struct btrfs_space_info *sinfo;
-
- sinfo = __find_space_info(root->fs_info, data);
- printk(KERN_ERR "btrfs allocation failed flags %llu, "
- "wanted %llu\n", (unsigned long long)data,
- (unsigned long long)num_bytes);
- dump_space_info(sinfo, num_bytes, 1);
+ if (ret == -ENOSPC) {
+ if (!final_tried) {
+ num_bytes = num_bytes >> 1;
+ num_bytes = num_bytes & ~(root->sectorsize - 1);
+ num_bytes = max(num_bytes, min_alloc_size);
+ do_chunk_alloc(trans, root->fs_info->extent_root,
+ num_bytes, data, CHUNK_ALLOC_FORCE);
+ if (num_bytes == min_alloc_size)
+ final_tried = true;
+ goto again;
+ } else if (btrfs_test_opt(root, ENOSPC_DEBUG)) {
+ struct btrfs_space_info *sinfo;
+
+ sinfo = __find_space_info(root->fs_info, data);
+ printk(KERN_ERR "btrfs allocation failed flags %llu, "
+ "wanted %llu\n", (unsigned long long)data,
+ (unsigned long long)num_bytes);
+ dump_space_info(sinfo, num_bytes, 1);
+ }
}
trace_btrfs_reserved_extent_alloc(root, ins->objectid, ins->offset);
--
1.7.6.5
^ permalink raw reply related
* Re: [RFC PATCH v2] ARM: imx: Add basic imx6q thermal management
From: Sascha Hauer @ 2012-01-17 9:23 UTC (permalink / raw)
To: Rob Lee
Cc: linux, shawn.guo, amit.kachhap, amit.kucheria, linux-arm-kernel,
patches, linux-acpi, lenb
In-Reply-To: <CAMXH7KFdBQmh9eQYXU4Hzg=M9cxyJWzDKouYsGUp+POw0FRXqQ@mail.gmail.com>
On Mon, Jan 16, 2012 at 11:11:42PM -0600, Rob Lee wrote:
> Arrrrgh, just noticed I sent the wrong patch. Here is the correct one:
>
> Adds support for temperature sensor readings, registers with common
> thermal framework, and uses the new common cpu_cooling interface.
>
> Signed-off-by: Robert Lee <rob.lee@linaro.org>
> ---
> arch/arm/boot/dts/imx6q.dtsi | 1 +
> drivers/thermal/Kconfig | 6 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/imx6q_thermal.c | 547 +++++++++++++++++++++++++++++++++++++++
> 4 files changed, 555 insertions(+), 0 deletions(-)
> create mode 100644 drivers/thermal/imx6q_thermal.c
>
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index 7dda599..d62b88d 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -508,6 +508,7 @@
> };
>
> ocotp@021bc000 {
> + compatible = "fsl,imx6q-ocotp";
> reg = <0x021bc000 0x4000>;
> };
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 298c1cd..dd8cede 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -29,3 +29,9 @@ config CPU_THERMAL
> This will be useful for platforms using the generic thermal interface
> and not the ACPI interface.
> If you want this support, you should say Y or M here.
> +
> +config IMX6Q_THERMAL
> + bool "IMX6Q Thermal interface support"
> + depends on THERMAL && CPU_THERMAL
> + help
> + Adds thermal management for IMX6Q.
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 655cbc4..e2bcffe 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -4,3 +4,4 @@
>
> obj-$(CONFIG_THERMAL) += thermal_sys.o
> obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
> +obj-$(CONFIG_IMX6Q_THERMAL) += imx6q_thermal.o
> diff --git a/drivers/thermal/imx6q_thermal.c b/drivers/thermal/imx6q_thermal.c
> new file mode 100644
> index 0000000..c7174b5
> --- /dev/null
> +++ b/drivers/thermal/imx6q_thermal.c
> @@ -0,0 +1,547 @@
> +/*
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2012 Linaro Ltd.
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/* i.MX6Q Thermal Implementation */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/dmi.h>
> +#include <linux/init.h>
> +#include <linux/slab.h>
> +#include <linux/delay.h>
> +#include <linux/types.h>
> +#include <linux/thermal.h>
> +#include <linux/io.h>
> +#include <linux/syscalls.h>
> +#include <linux/cpufreq.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/smp.h>
> +#include <linux/cpu_cooling.h>
> +#include <linux/platform_device.h>
> +
> +/* register define of anatop */
> +#define HW_ANADIG_ANA_MISC0 0x00000150
> +#define HW_ANADIG_ANA_MISC0_SET 0x00000154
> +#define HW_ANADIG_ANA_MISC0_CLR 0x00000158
> +#define HW_ANADIG_ANA_MISC0_TOG 0x0000015c
> +#define BM_ANADIG_ANA_MISC0_REFTOP_SELBIASOFF 0x00000008
> +
> +#define HW_ANADIG_TEMPSENSE0 0x00000180
> +#define HW_ANADIG_TEMPSENSE0_SET 0x00000184
> +#define HW_ANADIG_TEMPSENSE0_CLR 0x00000188
> +#define HW_ANADIG_TEMPSENSE0_TOG 0x0000018c
> +
> +#define BP_ANADIG_TEMPSENSE0_TEMP_VALUE 8
> +#define BM_ANADIG_TEMPSENSE0_TEMP_VALUE 0x000FFF00
> +#define BM_ANADIG_TEMPSENSE0_FINISHED 0x00000004
> +#define BM_ANADIG_TEMPSENSE0_MEASURE_TEMP 0x00000002
> +#define BM_ANADIG_TEMPSENSE0_POWER_DOWN 0x00000001
> +
> +#define HW_ANADIG_TEMPSENSE1 0x00000190
> +#define HW_ANADIG_TEMPSENSE1_SET 0x00000194
> +#define HW_ANADIG_TEMPSENSE1_CLR 0x00000198
> +#define BP_ANADIG_TEMPSENSE1_MEASURE_FREQ 0
> +#define BM_ANADIG_TEMPSENSE1_MEASURE_FREQ 0x0000FFFF
> +
> +#define HW_OCOTP_ANA1 0x000004E0
> +
> +#define IMX6Q_THERMAL_POLLING_FREQUENCY_MS 10000
> +#define IMX6Q_THERMAL_ACT_TRP_PTS 3
> +/* assumption: always one critical trip point */
> +#define IMX6Q_THERMAL_TOTAL_TRP_PTS (IMX6Q_THERMAL_ACT_TRP_PTS + 1)
> +
> +struct th_sys_trip_point {
> + u32 temp; /* in celcius */
> + enum thermal_trip_type type;
> +};
> +
> +struct imx6q_thermal_data {
> + struct th_sys_trip_point trp_pts[IMX6Q_THERMAL_TOTAL_TRP_PTS];
> + struct freq_pctg_table freq_tab[IMX6Q_THERMAL_ACT_TRP_PTS];
> +};
> +
> +struct imx6q_sensor_data {
> + int c1, c2;
> + char *name;
> + bool was_suspended;
> +};
> +
> +struct imx6q_thermal_zone {
> + struct thermal_zone_device *therm_dev;
> + struct thermal_cooling_device *cool_dev;
> + struct imx6q_sensor_data sensor_data;
> + struct imx6q_thermal_data *thermal_data;
> +};
> +
> +/*
> + * This data defines the various trip points that will trigger action
> + * when crossed.
> + */
> +static struct imx6q_thermal_data thermal_data = {
> + .trp_pts[0] = {
> + .temp = 85000,
> + .type = THERMAL_TRIP_STATE_ACTIVE,
> + },
> + .freq_tab[0] = {
> + .freq_clip_pctg[0] = 25,
> + },
> + .trp_pts[1] = {
> + .temp = 90000,
> + .type = THERMAL_TRIP_STATE_ACTIVE,
> + },
> + .freq_tab[1] = {
> + .freq_clip_pctg[0] = 65,
> + },
> + .trp_pts[2] = {
> + .temp = 95000,
> + .type = THERMAL_TRIP_STATE_ACTIVE,
> + },
> + .freq_tab[2] = {
> + .freq_clip_pctg[0] = 99,
> + },
> + .trp_pts[3] = {
> + .temp = 100000,
> + .type = THERMAL_TRIP_CRITICAL,
> + },
> +};
> +
> +static int th_sys_get_temp(struct thermal_zone_device *thermal,
> + unsigned long *temp);
> +
> +static struct platform_device *dev;
> +static struct imx6q_thermal_zone *th_zone;
> +static void __iomem *anatop_base;
> +
> +static inline int imx6q_get_temp(int *temp)
> +{
> + unsigned int n_meas;
> + unsigned int reg;
> + struct imx6q_sensor_data *p = &th_zone->sensor_data;
> +
> + /*
> + * For now we only using single measure. Every time we measure
> + * the temperature, we will power on/down the anadig module
> + */
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_POWER_DOWN,
> + anatop_base + HW_ANADIG_TEMPSENSE0_CLR);
> +
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_FINISHED,
> + anatop_base + HW_ANADIG_TEMPSENSE0_CLR);
> +
> + p->was_suspended = false;
> +
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_MEASURE_TEMP,
> + anatop_base + HW_ANADIG_TEMPSENSE0_SET);
> +
> + /*
> + * According to SoC designers, it may require up to ~17us to complete
> + * a measurement. But we have a 'finished' status bit, so we
> + * check it just in case the designers are liars.
> + */
> + do {
> + msleep(1);
> +
> + /*
> + * if system was possibly suspended while measurement
> + * was being taken, we take another measurement to make
> + * sure the measurement is valid.
> + */
> + if (p->was_suspended) {
How can this ever be true? It is set to false above. Wait a minute, you
are trying to synchronize with the suspend/resume callbacks below. No,
please remove this. If your system suspends in the middle of this
function it's the thermal framework that does something wrong.
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_MEASURE_TEMP,
> + anatop_base + HW_ANADIG_TEMPSENSE0_CLR);
> +
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_FINISHED,
> + anatop_base + HW_ANADIG_TEMPSENSE0_CLR);
> +
> + p->was_suspended = false;
> +
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_MEASURE_TEMP,
> + anatop_base + HW_ANADIG_TEMPSENSE0_SET);
> +
> + continue;
unnecessary continue
> + }
> + } while (!(readl_relaxed(anatop_base + HW_ANADIG_TEMPSENSE0)
> + & BM_ANADIG_TEMPSENSE0_FINISHED));
> +
> + reg = readl_relaxed(anatop_base + HW_ANADIG_TEMPSENSE0);
> +
> + n_meas = (reg & BM_ANADIG_TEMPSENSE0_TEMP_VALUE)
> + >> BP_ANADIG_TEMPSENSE0_TEMP_VALUE;
> +
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_MEASURE_TEMP,
> + anatop_base + HW_ANADIG_TEMPSENSE0_CLR);
> +
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_POWER_DOWN,
> + anatop_base + HW_ANADIG_TEMPSENSE0_SET);
> +
> + /* See imx6q_thermal_process_fuse_data for forumla derivation. */
> + *temp = p->c2 + (p->c1 * n_meas);
> +
> + pr_debug("Temperature: %d\n", *temp / 1000);
> +
> + return 0;
> +}
> +
> +static int th_sys_get_temp(struct thermal_zone_device *thermal,
> + unsigned long *temp)
> +{
> + int tmp = 0;
> +
> + imx6q_get_temp(&tmp);
> +
> + /*
> + * The thermal framework code stores temperature in unsigned long. Also,
> + * it has references to "millicelcius" which limits the lowest
> + * temperature possible (compared to Kelvin).
> + */
> + if (likely(tmp > 0))
Please no 'likely' in such slow pathes.
> + *temp = tmp;
> + else
> + *temp = 0;
> +
> + return 0;
> +}
> +
> +static int th_sys_get_mode(struct thermal_zone_device *thermal,
> + enum thermal_device_mode *mode)
> +{
> + *mode = THERMAL_DEVICE_ENABLED;
> + return 0;
> +}
> +
> +static int th_sys_get_trip_type(struct thermal_zone_device *thermal, int trip,
> + enum thermal_trip_type *type)
> +{
> + if (trip >= IMX6Q_THERMAL_TOTAL_TRP_PTS)
> + return -EINVAL;
> +
> + *type = th_zone->thermal_data->trp_pts[trip].type;
> +
> + return 0;
> +}
> +
> +static int th_sys_get_trip_temp(struct thermal_zone_device *thermal, int trip,
> + unsigned long *temp)
> +{
> + if (trip >= IMX6Q_THERMAL_TOTAL_TRP_PTS)
> + return -EINVAL;
> +
> + *temp = th_zone->thermal_data->trp_pts[trip].temp;
> + return 0;
> +}
> +
> +static int th_sys_get_crit_temp(struct thermal_zone_device *thermal,
> + unsigned long *temp)
> +{
> +
> + *temp = th_zone->thermal_data->trp_pts[
> + IMX6Q_THERMAL_TOTAL_TRP_PTS - 1].temp;
> + return 0;
> +}
> +
> +static int th_sys_bind(struct thermal_zone_device *thermal,
> + struct thermal_cooling_device *cdev)
> +{
> + int i;
> +
> + /* if the cooling device is the one from imx6 bind it */
> + if (cdev != th_zone->cool_dev)
> + return 0;
> +
> + for (i = 0; i < IMX6Q_THERMAL_ACT_TRP_PTS; i++) {
> + if (thermal_zone_bind_cooling_device(thermal, i, cdev)) {
> + pr_err("error binding cooling dev\n");
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int th_sys_unbind(struct thermal_zone_device *thermal,
> + struct thermal_cooling_device *cdev)
> +{
> + int i;
> +
> + if (cdev != th_zone->cool_dev)
> + return 0;
> +
> + for (i = 0; i < IMX6Q_THERMAL_ACT_TRP_PTS; i++) {
> + if (thermal_zone_unbind_cooling_device(thermal, i, cdev)) {
> + pr_err("error unbinding cooling dev\n");
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static struct thermal_zone_device_ops imx6q_dev_ops = {
> + .bind = th_sys_bind,
> + .unbind = th_sys_unbind,
> + .get_temp = th_sys_get_temp,
> + .get_mode = th_sys_get_mode,
> + .get_trip_type = th_sys_get_trip_type,
> + .get_trip_temp = th_sys_get_trip_temp,
> + .get_crit_temp = th_sys_get_crit_temp,
> +};
> +
> +static int imx6q_thermal_process_fuse_data(unsigned int fuse_data)
> +{
> + int t1, t2, n1, n2;
> + struct imx6q_sensor_data *p = &th_zone->sensor_data;
> +
> + if (fuse_data == 0 || fuse_data == 0xffffffff)
> + return -EINVAL;
> +
> + /*
> + * Fuse data layout:
> + * [31:20] sensor value @ 25C
> + * [19:8] sensor value of hot
> + * [7:0] hot temperature value
> + */
> + n1 = fuse_data >> 20;
> + n2 = (fuse_data & 0xfff00) >> 8;
> + t2 = fuse_data & 0xff;
> + t1 = 25; /* t1 always 25C */
> +
> + pr_debug(" -- temperature sensor calibration data --\n");
> + pr_debug("HW_OCOTP_ANA1: %x\n", fuse_data);
> + pr_debug("n1: %d\nn2: %d\nt1: %d\nt2: %d\n", n1, n2, t1, t2);
> +
> + /*
> + * From reference manual (derived from linear interpolation),
> + * Tmeas = T2 + (Nmeas - N2) * (T1 - T2) / (N1 - N2)
> + * We want to reduce this down to the minimum computation necessary
> + * for each temperature read. Also, we want Tmeas in millicelcius
> + * and we don't want to lose precision from integer division. So...
> + * milli_Tmeas = 1000 * T2 + 1000 * (Nmeas - N2) * (T1 - T2) / (N1 - N2)
> + * Let constant c1 = 1000 * (T1 - T2) / (N1 - N2)
> + * milli_Tmeas = (1000 * T2) + c1 * (Nmeas - N2)
> + * milli_Tmeas = (1000 * T2) + (c1 * Nmeas) - (c1 * N2)
> + * Let constant c2 = (1000 * T2) - (c1 * N2)
> + * milli_Tmeas = c2 + (c1 * Nmeas)
> + */
> + p->c1 = (1000 * (t1 - t2)) / (n1 - n2);
> + p->c2 = (1000 * t2) - (p->c1 * n2);
> +
> + pr_debug("c1: %i\n", p->c1);
> + pr_debug("c2: %i\n", p->c2);
> +
> + return 0;
> +}
> +
> +
> +static int imx6q_thermal_probe(struct platform_device *pdev)
> +{
> + return 0;
> +}
> +
> +static int imx6q_thermal_remove(struct platform_device *pdev)
> +{
> + return 0;
> +}
> +
> +static int imx6q_thermal_suspend(struct platform_device *pdev,
> + pm_message_t state)
> +{
> + /*
> + * according to imx6q thermal sensor designers, system problems will
> + * not occur if low power modes are entered while temp_sensor is active,
> + * so do nothing here.
> + */
> + return 0;
> +}
> +
> +static int imx6q_thermal_resume(struct platform_device *pdev)
> +{
> + th_zone->sensor_data.was_suspended = true;
> + return 0;
> +}
> +
> +void imx6q_unregister_thermal(void)
> +{
static
> + if (th_zone && th_zone->cool_dev)
> + cpufreq_cooling_unregister();
> +
> + if (th_zone && th_zone->therm_dev)
> + thermal_zone_device_unregister(th_zone->therm_dev);
> +
> + kfree(th_zone);
> +
> + pr_info("i.MX6Q: Kernel Thermal management unregistered\n");
> +}
> +
> +static int __init imx6q_thermal_register(void)
> +{
> + void __iomem *ocotp_base;
> + struct device_node *np;
> + unsigned int fuse_data;
> + int ret;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-ocotp");
> + ocotp_base = of_iomap(np, 0);
Clean up after yourself. of_iomap has a corresponding of_iounmap.
> +
> + if (!ocotp_base) {
> + pr_err("Could not retrieve ocotp-base\n");
> + ret = -EINVAL;
> + goto err_unregister;
> + }
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");
> + anatop_base = of_iomap(np, 0);
> +
> + if (!anatop_base) {
> + pr_err("Could not retrieve anantop-base\n");
> + ret = -EINVAL;
> + goto err_unregister;
> + }
> +
> + fuse_data = readl_relaxed(ocotp_base + HW_OCOTP_ANA1);
> +
> + th_zone = kzalloc(sizeof(struct imx6q_thermal_zone), GFP_KERNEL);
> +
> + if (!th_zone) {
> + ret = -ENOMEM;
> + goto err_unregister;
> + }
> +
> + th_zone->sensor_data.name = "imx6q-temp_sens",
> +
> + ret = imx6q_thermal_process_fuse_data(fuse_data);
> +
> + if (ret) {
> + pr_err("Invalid temperature calibration data.\n");
> + goto err_unregister;
> + }
> +
> + /* Make sure sensor is in known good state for measurements */
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_POWER_DOWN,
> + anatop_base + HW_ANADIG_TEMPSENSE0_CLR);
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_MEASURE_TEMP,
> + anatop_base + HW_ANADIG_TEMPSENSE0_CLR);
> + writel_relaxed(BM_ANADIG_TEMPSENSE1_MEASURE_FREQ,
> + anatop_base + HW_ANADIG_TEMPSENSE1_CLR);
> + writel_relaxed(BM_ANADIG_ANA_MISC0_REFTOP_SELBIASOFF,
> + anatop_base + HW_ANADIG_ANA_MISC0_SET);
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_POWER_DOWN,
> + anatop_base + HW_ANADIG_TEMPSENSE0_SET);
> +
> + th_zone->thermal_data = &thermal_data;
> + if (!th_zone->thermal_data) {
> + pr_err("Temperature sensor data not initialised\n");
> + ret = -EINVAL;
> + goto err_unregister;
> + }
> +
> + th_zone->cool_dev = cpufreq_cooling_register(
> + (struct freq_pctg_table *)th_zone->thermal_data->freq_tab,
> + IMX6Q_THERMAL_ACT_TRP_PTS, cpumask_of(0));
> +
> + if (IS_ERR(th_zone->cool_dev)) {
> + pr_err("Failed to register cpufreq cooling device\n");
> + ret = -EINVAL;
> + goto err_unregister;
> + }
> +
> + th_zone->therm_dev = thermal_zone_device_register(
> + th_zone->sensor_data.name, IMX6Q_THERMAL_TOTAL_TRP_PTS,
> + NULL,
The NULL pointer here is for your devdata. Use it instead of global
variables.
> &imx6q_dev_ops, 0, 0, 0,
> + IMX6Q_THERMAL_POLLING_FREQUENCY_MS);
> +
> + if (IS_ERR(th_zone->therm_dev)) {
> + pr_err("Failed to register thermal zone device\n");
> + ret = -EINVAL;
> + goto err_unregister;
> + }
> +
> + return 0;
> +
> +err_unregister:
> + imx6q_unregister_thermal();
> + return ret;
> +}
> +
> +static struct platform_driver imx6q_thermal_driver = {
> + .probe = imx6q_thermal_probe,
> + .remove = imx6q_thermal_remove,
> + .suspend = imx6q_thermal_suspend,
> + .resume = imx6q_thermal_resume,
> + .driver = {
> + .name = "imx6q-thermal",
> + .owner = THIS_MODULE,
> + },
> +};
> +
> +static int imx6q_th_platform_register(void)
> +{
> + int ret;
> +
> + ret = platform_driver_register(&imx6q_thermal_driver);
> + if (ret)
> + return ret;
> +
> + dev = platform_device_alloc("imx6q-thermal-cpu", -1);
Now I understand your question what advantages it has to make this
a real driver. If you register the device here in this driver it has
no advantages at all.
Of course the device has to be registered in the oftree or platform
code where we know we are actually running on an i.MX6 SoC. Hint: just
because i.MX6 support is compiled into the kernel does not mean we
are actually running on such a SoC.
> +
> + if (!dev) {
> + ret = -ENOMEM;
> + goto err_device_alloc;
> + }
> + ret = platform_device_add(dev);
> + if (ret)
> + goto err_device_add;
> +
> + return ret;
> +
> +err_device_add:
> + platform_device_put(dev);
> +err_device_alloc:
> + platform_driver_unregister(&imx6q_thermal_driver);
> +
> + return ret;
> +}
> +
> +static int __init imx6q_thermal_init(void)
> +{
> + int ret;
> +
> + ret = imx6q_th_platform_register();
> + if (ret)
> + goto err;
> +
> + ret = imx6q_thermal_register();
> + if (ret)
> + goto err;
> +
> + pr_info("i.MX Thermal management enabled.\n");
> + return ret;
> +
> +err:
> + pr_info("WARNING: Thermal management NOT enabled due to errors.\n");
> + return ret;
> +}
> +
> +static void __exit imx6q_thermal_driver_exit(void)
> +{
> + imx6q_unregister_thermal();
> + platform_device_unregister(dev);
> + platform_driver_unregister(&imx6q_thermal_driver);
> +}
> +
> +module_init(imx6q_thermal_init);
> +module_exit(imx6q_thermal_driver_exit);
> +
> +MODULE_AUTHOR("Freescale Semiconductor");
> +MODULE_DESCRIPTION("i.MX6Q SoC thermal driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:imx6q-thermal");
> --
> 1.7.1
>
>
> ---------- Forwarded message ----------
> From: Rob Lee <rob.lee@linaro.org>
> Date: Mon, Jan 16, 2012 at 10:51 PM
> Subject: Re: [RFC PATCH v2] ARM: imx: Add basic imx6q thermal management
> To: linux@arm.linux.org.uk, s.hauer@pengutronix.de, shawn.guo@freescale.com
> Cc: amit.kachhap@linaro.org, amit.kucheria@linaro.org,
> linux-arm-kernel@lists.infradead.org, patches@linaro.org,
> linux-acpi@vger.kernel.org, lenb@kernel.org
>
>
> link to v1 submission:
>
> http://www.spinics.net/lists/arm-kernel/msg155111.html
>
> Based on v3.2 plus recently submitted cpu_cooling functionality here:
>
> http://www.spinics.net/lists/linux-pm/msg26500.html
>
> Changes since v1:
> 1. Cleaned up some style issue pointed out in v1
> 2. Made various other code cleanup and re-organizing
> 3. Added temperature sensor calibration
> 4. Created platform driver and device to hook into pm suspend.
>
> Performed some basic testing to ensure proper cooling operating. If
> you want to test this, full testing requires imx6q cpufreq
> implementation (not yet in v3.2) and requires an imx6q part that has
> temperature sensor calibration fuse correctly burned.
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Bug 44852] 3D Acceleration initialization failed for Fusion Wrestler 9808
From: bugzilla-daemon @ 2012-01-17 9:23 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-44852-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=44852
--- Comment #4 from samit vats <hysvats@gmail.com> 2012-01-17 01:23:38 PST ---
Created attachment 55666
--> https://bugs.freedesktop.org/attachment.cgi?id=55666
xorg.conf
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [RFC PATCH v2] ARM: imx: Add basic imx6q thermal management
From: Sascha Hauer @ 2012-01-17 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMXH7KFdBQmh9eQYXU4Hzg=M9cxyJWzDKouYsGUp+POw0FRXqQ@mail.gmail.com>
On Mon, Jan 16, 2012 at 11:11:42PM -0600, Rob Lee wrote:
> Arrrrgh, just noticed I sent the wrong patch. Here is the correct one:
>
> Adds support for temperature sensor readings, registers with common
> thermal framework, and uses the new common cpu_cooling interface.
>
> Signed-off-by: Robert Lee <rob.lee@linaro.org>
> ---
> arch/arm/boot/dts/imx6q.dtsi | 1 +
> drivers/thermal/Kconfig | 6 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/imx6q_thermal.c | 547 +++++++++++++++++++++++++++++++++++++++
> 4 files changed, 555 insertions(+), 0 deletions(-)
> create mode 100644 drivers/thermal/imx6q_thermal.c
>
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index 7dda599..d62b88d 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -508,6 +508,7 @@
> };
>
> ocotp at 021bc000 {
> + compatible = "fsl,imx6q-ocotp";
> reg = <0x021bc000 0x4000>;
> };
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 298c1cd..dd8cede 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -29,3 +29,9 @@ config CPU_THERMAL
> This will be useful for platforms using the generic thermal interface
> and not the ACPI interface.
> If you want this support, you should say Y or M here.
> +
> +config IMX6Q_THERMAL
> + bool "IMX6Q Thermal interface support"
> + depends on THERMAL && CPU_THERMAL
> + help
> + Adds thermal management for IMX6Q.
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 655cbc4..e2bcffe 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -4,3 +4,4 @@
>
> obj-$(CONFIG_THERMAL) += thermal_sys.o
> obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
> +obj-$(CONFIG_IMX6Q_THERMAL) += imx6q_thermal.o
> diff --git a/drivers/thermal/imx6q_thermal.c b/drivers/thermal/imx6q_thermal.c
> new file mode 100644
> index 0000000..c7174b5
> --- /dev/null
> +++ b/drivers/thermal/imx6q_thermal.c
> @@ -0,0 +1,547 @@
> +/*
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2012 Linaro Ltd.
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/* i.MX6Q Thermal Implementation */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/dmi.h>
> +#include <linux/init.h>
> +#include <linux/slab.h>
> +#include <linux/delay.h>
> +#include <linux/types.h>
> +#include <linux/thermal.h>
> +#include <linux/io.h>
> +#include <linux/syscalls.h>
> +#include <linux/cpufreq.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/smp.h>
> +#include <linux/cpu_cooling.h>
> +#include <linux/platform_device.h>
> +
> +/* register define of anatop */
> +#define HW_ANADIG_ANA_MISC0 0x00000150
> +#define HW_ANADIG_ANA_MISC0_SET 0x00000154
> +#define HW_ANADIG_ANA_MISC0_CLR 0x00000158
> +#define HW_ANADIG_ANA_MISC0_TOG 0x0000015c
> +#define BM_ANADIG_ANA_MISC0_REFTOP_SELBIASOFF 0x00000008
> +
> +#define HW_ANADIG_TEMPSENSE0 0x00000180
> +#define HW_ANADIG_TEMPSENSE0_SET 0x00000184
> +#define HW_ANADIG_TEMPSENSE0_CLR 0x00000188
> +#define HW_ANADIG_TEMPSENSE0_TOG 0x0000018c
> +
> +#define BP_ANADIG_TEMPSENSE0_TEMP_VALUE 8
> +#define BM_ANADIG_TEMPSENSE0_TEMP_VALUE 0x000FFF00
> +#define BM_ANADIG_TEMPSENSE0_FINISHED 0x00000004
> +#define BM_ANADIG_TEMPSENSE0_MEASURE_TEMP 0x00000002
> +#define BM_ANADIG_TEMPSENSE0_POWER_DOWN 0x00000001
> +
> +#define HW_ANADIG_TEMPSENSE1 0x00000190
> +#define HW_ANADIG_TEMPSENSE1_SET 0x00000194
> +#define HW_ANADIG_TEMPSENSE1_CLR 0x00000198
> +#define BP_ANADIG_TEMPSENSE1_MEASURE_FREQ 0
> +#define BM_ANADIG_TEMPSENSE1_MEASURE_FREQ 0x0000FFFF
> +
> +#define HW_OCOTP_ANA1 0x000004E0
> +
> +#define IMX6Q_THERMAL_POLLING_FREQUENCY_MS 10000
> +#define IMX6Q_THERMAL_ACT_TRP_PTS 3
> +/* assumption: always one critical trip point */
> +#define IMX6Q_THERMAL_TOTAL_TRP_PTS (IMX6Q_THERMAL_ACT_TRP_PTS + 1)
> +
> +struct th_sys_trip_point {
> + u32 temp; /* in celcius */
> + enum thermal_trip_type type;
> +};
> +
> +struct imx6q_thermal_data {
> + struct th_sys_trip_point trp_pts[IMX6Q_THERMAL_TOTAL_TRP_PTS];
> + struct freq_pctg_table freq_tab[IMX6Q_THERMAL_ACT_TRP_PTS];
> +};
> +
> +struct imx6q_sensor_data {
> + int c1, c2;
> + char *name;
> + bool was_suspended;
> +};
> +
> +struct imx6q_thermal_zone {
> + struct thermal_zone_device *therm_dev;
> + struct thermal_cooling_device *cool_dev;
> + struct imx6q_sensor_data sensor_data;
> + struct imx6q_thermal_data *thermal_data;
> +};
> +
> +/*
> + * This data defines the various trip points that will trigger action
> + * when crossed.
> + */
> +static struct imx6q_thermal_data thermal_data = {
> + .trp_pts[0] = {
> + .temp = 85000,
> + .type = THERMAL_TRIP_STATE_ACTIVE,
> + },
> + .freq_tab[0] = {
> + .freq_clip_pctg[0] = 25,
> + },
> + .trp_pts[1] = {
> + .temp = 90000,
> + .type = THERMAL_TRIP_STATE_ACTIVE,
> + },
> + .freq_tab[1] = {
> + .freq_clip_pctg[0] = 65,
> + },
> + .trp_pts[2] = {
> + .temp = 95000,
> + .type = THERMAL_TRIP_STATE_ACTIVE,
> + },
> + .freq_tab[2] = {
> + .freq_clip_pctg[0] = 99,
> + },
> + .trp_pts[3] = {
> + .temp = 100000,
> + .type = THERMAL_TRIP_CRITICAL,
> + },
> +};
> +
> +static int th_sys_get_temp(struct thermal_zone_device *thermal,
> + unsigned long *temp);
> +
> +static struct platform_device *dev;
> +static struct imx6q_thermal_zone *th_zone;
> +static void __iomem *anatop_base;
> +
> +static inline int imx6q_get_temp(int *temp)
> +{
> + unsigned int n_meas;
> + unsigned int reg;
> + struct imx6q_sensor_data *p = &th_zone->sensor_data;
> +
> + /*
> + * For now we only using single measure. Every time we measure
> + * the temperature, we will power on/down the anadig module
> + */
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_POWER_DOWN,
> + anatop_base + HW_ANADIG_TEMPSENSE0_CLR);
> +
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_FINISHED,
> + anatop_base + HW_ANADIG_TEMPSENSE0_CLR);
> +
> + p->was_suspended = false;
> +
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_MEASURE_TEMP,
> + anatop_base + HW_ANADIG_TEMPSENSE0_SET);
> +
> + /*
> + * According to SoC designers, it may require up to ~17us to complete
> + * a measurement. But we have a 'finished' status bit, so we
> + * check it just in case the designers are liars.
> + */
> + do {
> + msleep(1);
> +
> + /*
> + * if system was possibly suspended while measurement
> + * was being taken, we take another measurement to make
> + * sure the measurement is valid.
> + */
> + if (p->was_suspended) {
How can this ever be true? It is set to false above. Wait a minute, you
are trying to synchronize with the suspend/resume callbacks below. No,
please remove this. If your system suspends in the middle of this
function it's the thermal framework that does something wrong.
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_MEASURE_TEMP,
> + anatop_base + HW_ANADIG_TEMPSENSE0_CLR);
> +
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_FINISHED,
> + anatop_base + HW_ANADIG_TEMPSENSE0_CLR);
> +
> + p->was_suspended = false;
> +
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_MEASURE_TEMP,
> + anatop_base + HW_ANADIG_TEMPSENSE0_SET);
> +
> + continue;
unnecessary continue
> + }
> + } while (!(readl_relaxed(anatop_base + HW_ANADIG_TEMPSENSE0)
> + & BM_ANADIG_TEMPSENSE0_FINISHED));
> +
> + reg = readl_relaxed(anatop_base + HW_ANADIG_TEMPSENSE0);
> +
> + n_meas = (reg & BM_ANADIG_TEMPSENSE0_TEMP_VALUE)
> + >> BP_ANADIG_TEMPSENSE0_TEMP_VALUE;
> +
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_MEASURE_TEMP,
> + anatop_base + HW_ANADIG_TEMPSENSE0_CLR);
> +
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_POWER_DOWN,
> + anatop_base + HW_ANADIG_TEMPSENSE0_SET);
> +
> + /* See imx6q_thermal_process_fuse_data for forumla derivation. */
> + *temp = p->c2 + (p->c1 * n_meas);
> +
> + pr_debug("Temperature: %d\n", *temp / 1000);
> +
> + return 0;
> +}
> +
> +static int th_sys_get_temp(struct thermal_zone_device *thermal,
> + unsigned long *temp)
> +{
> + int tmp = 0;
> +
> + imx6q_get_temp(&tmp);
> +
> + /*
> + * The thermal framework code stores temperature in unsigned long. Also,
> + * it has references to "millicelcius" which limits the lowest
> + * temperature possible (compared to Kelvin).
> + */
> + if (likely(tmp > 0))
Please no 'likely' in such slow pathes.
> + *temp = tmp;
> + else
> + *temp = 0;
> +
> + return 0;
> +}
> +
> +static int th_sys_get_mode(struct thermal_zone_device *thermal,
> + enum thermal_device_mode *mode)
> +{
> + *mode = THERMAL_DEVICE_ENABLED;
> + return 0;
> +}
> +
> +static int th_sys_get_trip_type(struct thermal_zone_device *thermal, int trip,
> + enum thermal_trip_type *type)
> +{
> + if (trip >= IMX6Q_THERMAL_TOTAL_TRP_PTS)
> + return -EINVAL;
> +
> + *type = th_zone->thermal_data->trp_pts[trip].type;
> +
> + return 0;
> +}
> +
> +static int th_sys_get_trip_temp(struct thermal_zone_device *thermal, int trip,
> + unsigned long *temp)
> +{
> + if (trip >= IMX6Q_THERMAL_TOTAL_TRP_PTS)
> + return -EINVAL;
> +
> + *temp = th_zone->thermal_data->trp_pts[trip].temp;
> + return 0;
> +}
> +
> +static int th_sys_get_crit_temp(struct thermal_zone_device *thermal,
> + unsigned long *temp)
> +{
> +
> + *temp = th_zone->thermal_data->trp_pts[
> + IMX6Q_THERMAL_TOTAL_TRP_PTS - 1].temp;
> + return 0;
> +}
> +
> +static int th_sys_bind(struct thermal_zone_device *thermal,
> + struct thermal_cooling_device *cdev)
> +{
> + int i;
> +
> + /* if the cooling device is the one from imx6 bind it */
> + if (cdev != th_zone->cool_dev)
> + return 0;
> +
> + for (i = 0; i < IMX6Q_THERMAL_ACT_TRP_PTS; i++) {
> + if (thermal_zone_bind_cooling_device(thermal, i, cdev)) {
> + pr_err("error binding cooling dev\n");
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int th_sys_unbind(struct thermal_zone_device *thermal,
> + struct thermal_cooling_device *cdev)
> +{
> + int i;
> +
> + if (cdev != th_zone->cool_dev)
> + return 0;
> +
> + for (i = 0; i < IMX6Q_THERMAL_ACT_TRP_PTS; i++) {
> + if (thermal_zone_unbind_cooling_device(thermal, i, cdev)) {
> + pr_err("error unbinding cooling dev\n");
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static struct thermal_zone_device_ops imx6q_dev_ops = {
> + .bind = th_sys_bind,
> + .unbind = th_sys_unbind,
> + .get_temp = th_sys_get_temp,
> + .get_mode = th_sys_get_mode,
> + .get_trip_type = th_sys_get_trip_type,
> + .get_trip_temp = th_sys_get_trip_temp,
> + .get_crit_temp = th_sys_get_crit_temp,
> +};
> +
> +static int imx6q_thermal_process_fuse_data(unsigned int fuse_data)
> +{
> + int t1, t2, n1, n2;
> + struct imx6q_sensor_data *p = &th_zone->sensor_data;
> +
> + if (fuse_data == 0 || fuse_data == 0xffffffff)
> + return -EINVAL;
> +
> + /*
> + * Fuse data layout:
> + * [31:20] sensor value @ 25C
> + * [19:8] sensor value of hot
> + * [7:0] hot temperature value
> + */
> + n1 = fuse_data >> 20;
> + n2 = (fuse_data & 0xfff00) >> 8;
> + t2 = fuse_data & 0xff;
> + t1 = 25; /* t1 always 25C */
> +
> + pr_debug(" -- temperature sensor calibration data --\n");
> + pr_debug("HW_OCOTP_ANA1: %x\n", fuse_data);
> + pr_debug("n1: %d\nn2: %d\nt1: %d\nt2: %d\n", n1, n2, t1, t2);
> +
> + /*
> + * From reference manual (derived from linear interpolation),
> + * Tmeas = T2 + (Nmeas - N2) * (T1 - T2) / (N1 - N2)
> + * We want to reduce this down to the minimum computation necessary
> + * for each temperature read. Also, we want Tmeas in millicelcius
> + * and we don't want to lose precision from integer division. So...
> + * milli_Tmeas = 1000 * T2 + 1000 * (Nmeas - N2) * (T1 - T2) / (N1 - N2)
> + * Let constant c1 = 1000 * (T1 - T2) / (N1 - N2)
> + * milli_Tmeas = (1000 * T2) + c1 * (Nmeas - N2)
> + * milli_Tmeas = (1000 * T2) + (c1 * Nmeas) - (c1 * N2)
> + * Let constant c2 = (1000 * T2) - (c1 * N2)
> + * milli_Tmeas = c2 + (c1 * Nmeas)
> + */
> + p->c1 = (1000 * (t1 - t2)) / (n1 - n2);
> + p->c2 = (1000 * t2) - (p->c1 * n2);
> +
> + pr_debug("c1: %i\n", p->c1);
> + pr_debug("c2: %i\n", p->c2);
> +
> + return 0;
> +}
> +
> +
> +static int imx6q_thermal_probe(struct platform_device *pdev)
> +{
> + return 0;
> +}
> +
> +static int imx6q_thermal_remove(struct platform_device *pdev)
> +{
> + return 0;
> +}
> +
> +static int imx6q_thermal_suspend(struct platform_device *pdev,
> + pm_message_t state)
> +{
> + /*
> + * according to imx6q thermal sensor designers, system problems will
> + * not occur if low power modes are entered while temp_sensor is active,
> + * so do nothing here.
> + */
> + return 0;
> +}
> +
> +static int imx6q_thermal_resume(struct platform_device *pdev)
> +{
> + th_zone->sensor_data.was_suspended = true;
> + return 0;
> +}
> +
> +void imx6q_unregister_thermal(void)
> +{
static
> + if (th_zone && th_zone->cool_dev)
> + cpufreq_cooling_unregister();
> +
> + if (th_zone && th_zone->therm_dev)
> + thermal_zone_device_unregister(th_zone->therm_dev);
> +
> + kfree(th_zone);
> +
> + pr_info("i.MX6Q: Kernel Thermal management unregistered\n");
> +}
> +
> +static int __init imx6q_thermal_register(void)
> +{
> + void __iomem *ocotp_base;
> + struct device_node *np;
> + unsigned int fuse_data;
> + int ret;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-ocotp");
> + ocotp_base = of_iomap(np, 0);
Clean up after yourself. of_iomap has a corresponding of_iounmap.
> +
> + if (!ocotp_base) {
> + pr_err("Could not retrieve ocotp-base\n");
> + ret = -EINVAL;
> + goto err_unregister;
> + }
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");
> + anatop_base = of_iomap(np, 0);
> +
> + if (!anatop_base) {
> + pr_err("Could not retrieve anantop-base\n");
> + ret = -EINVAL;
> + goto err_unregister;
> + }
> +
> + fuse_data = readl_relaxed(ocotp_base + HW_OCOTP_ANA1);
> +
> + th_zone = kzalloc(sizeof(struct imx6q_thermal_zone), GFP_KERNEL);
> +
> + if (!th_zone) {
> + ret = -ENOMEM;
> + goto err_unregister;
> + }
> +
> + th_zone->sensor_data.name = "imx6q-temp_sens",
> +
> + ret = imx6q_thermal_process_fuse_data(fuse_data);
> +
> + if (ret) {
> + pr_err("Invalid temperature calibration data.\n");
> + goto err_unregister;
> + }
> +
> + /* Make sure sensor is in known good state for measurements */
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_POWER_DOWN,
> + anatop_base + HW_ANADIG_TEMPSENSE0_CLR);
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_MEASURE_TEMP,
> + anatop_base + HW_ANADIG_TEMPSENSE0_CLR);
> + writel_relaxed(BM_ANADIG_TEMPSENSE1_MEASURE_FREQ,
> + anatop_base + HW_ANADIG_TEMPSENSE1_CLR);
> + writel_relaxed(BM_ANADIG_ANA_MISC0_REFTOP_SELBIASOFF,
> + anatop_base + HW_ANADIG_ANA_MISC0_SET);
> + writel_relaxed(BM_ANADIG_TEMPSENSE0_POWER_DOWN,
> + anatop_base + HW_ANADIG_TEMPSENSE0_SET);
> +
> + th_zone->thermal_data = &thermal_data;
> + if (!th_zone->thermal_data) {
> + pr_err("Temperature sensor data not initialised\n");
> + ret = -EINVAL;
> + goto err_unregister;
> + }
> +
> + th_zone->cool_dev = cpufreq_cooling_register(
> + (struct freq_pctg_table *)th_zone->thermal_data->freq_tab,
> + IMX6Q_THERMAL_ACT_TRP_PTS, cpumask_of(0));
> +
> + if (IS_ERR(th_zone->cool_dev)) {
> + pr_err("Failed to register cpufreq cooling device\n");
> + ret = -EINVAL;
> + goto err_unregister;
> + }
> +
> + th_zone->therm_dev = thermal_zone_device_register(
> + th_zone->sensor_data.name, IMX6Q_THERMAL_TOTAL_TRP_PTS,
> + NULL,
The NULL pointer here is for your devdata. Use it instead of global
variables.
> &imx6q_dev_ops, 0, 0, 0,
> + IMX6Q_THERMAL_POLLING_FREQUENCY_MS);
> +
> + if (IS_ERR(th_zone->therm_dev)) {
> + pr_err("Failed to register thermal zone device\n");
> + ret = -EINVAL;
> + goto err_unregister;
> + }
> +
> + return 0;
> +
> +err_unregister:
> + imx6q_unregister_thermal();
> + return ret;
> +}
> +
> +static struct platform_driver imx6q_thermal_driver = {
> + .probe = imx6q_thermal_probe,
> + .remove = imx6q_thermal_remove,
> + .suspend = imx6q_thermal_suspend,
> + .resume = imx6q_thermal_resume,
> + .driver = {
> + .name = "imx6q-thermal",
> + .owner = THIS_MODULE,
> + },
> +};
> +
> +static int imx6q_th_platform_register(void)
> +{
> + int ret;
> +
> + ret = platform_driver_register(&imx6q_thermal_driver);
> + if (ret)
> + return ret;
> +
> + dev = platform_device_alloc("imx6q-thermal-cpu", -1);
Now I understand your question what advantages it has to make this
a real driver. If you register the device here in this driver it has
no advantages at all.
Of course the device has to be registered in the oftree or platform
code where we know we are actually running on an i.MX6 SoC. Hint: just
because i.MX6 support is compiled into the kernel does not mean we
are actually running on such a SoC.
> +
> + if (!dev) {
> + ret = -ENOMEM;
> + goto err_device_alloc;
> + }
> + ret = platform_device_add(dev);
> + if (ret)
> + goto err_device_add;
> +
> + return ret;
> +
> +err_device_add:
> + platform_device_put(dev);
> +err_device_alloc:
> + platform_driver_unregister(&imx6q_thermal_driver);
> +
> + return ret;
> +}
> +
> +static int __init imx6q_thermal_init(void)
> +{
> + int ret;
> +
> + ret = imx6q_th_platform_register();
> + if (ret)
> + goto err;
> +
> + ret = imx6q_thermal_register();
> + if (ret)
> + goto err;
> +
> + pr_info("i.MX Thermal management enabled.\n");
> + return ret;
> +
> +err:
> + pr_info("WARNING: Thermal management NOT enabled due to errors.\n");
> + return ret;
> +}
> +
> +static void __exit imx6q_thermal_driver_exit(void)
> +{
> + imx6q_unregister_thermal();
> + platform_device_unregister(dev);
> + platform_driver_unregister(&imx6q_thermal_driver);
> +}
> +
> +module_init(imx6q_thermal_init);
> +module_exit(imx6q_thermal_driver_exit);
> +
> +MODULE_AUTHOR("Freescale Semiconductor");
> +MODULE_DESCRIPTION("i.MX6Q SoC thermal driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:imx6q-thermal");
> --
> 1.7.1
>
>
> ---------- Forwarded message ----------
> From: Rob Lee <rob.lee@linaro.org>
> Date: Mon, Jan 16, 2012 at 10:51 PM
> Subject: Re: [RFC PATCH v2] ARM: imx: Add basic imx6q thermal management
> To: linux at arm.linux.org.uk, s.hauer at pengutronix.de, shawn.guo at freescale.com
> Cc: amit.kachhap at linaro.org, amit.kucheria at linaro.org,
> linux-arm-kernel at lists.infradead.org, patches at linaro.org,
> linux-acpi at vger.kernel.org, lenb at kernel.org
>
>
> link to v1 submission:
>
> http://www.spinics.net/lists/arm-kernel/msg155111.html
>
> Based on v3.2 plus recently submitted cpu_cooling functionality here:
>
> http://www.spinics.net/lists/linux-pm/msg26500.html
>
> Changes since v1:
> 1. Cleaned up some style issue pointed out in v1
> 2. Made various other code cleanup and re-organizing
> 3. Added temperature sensor calibration
> 4. Created platform driver and device to hook into pm suspend.
>
> Performed some basic testing to ensure proper cooling operating. ?If
> you want to test this, full testing requires imx6q cpufreq
> implementation (not yet in v3.2) and requires an imx6q part that has
> temperature sensor calibration fuse correctly burned.
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [Bug 44852] 3D Acceleration initialization failed for Fusion Wrestler 9808
From: bugzilla-daemon @ 2012-01-17 9:23 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-44852-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=44852
--- Comment #3 from samit vats <hysvats@gmail.com> 2012-01-17 01:23:11 PST ---
Created attachment 55665
--> https://bugs.freedesktop.org/attachment.cgi?id=55665
dmesg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [Bug 44852] 3D Acceleration initialization failed for Fusion Wrestler 9808
From: bugzilla-daemon @ 2012-01-17 9:22 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-44852-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=44852
--- Comment #2 from samit vats <hysvats@gmail.com> 2012-01-17 01:22:47 PST ---
Created attachment 55664
--> https://bugs.freedesktop.org/attachment.cgi?id=55664
Xorg.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: Driver domains and hotplug scripts, redux
From: Roger Pau Monné @ 2012-01-17 9:22 UTC (permalink / raw)
To: Ian Jackson
Cc: xen-devel@lists.xensource.com, Ian Campbell, Stefano Stabellini
In-Reply-To: <20244.25907.223422.50324@mariner.uk.xensource.com>
2012/1/16 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monné writes ("Re: [Xen-devel] Driver domains and hotplug scripts, redux"):
>> 2012/1/12 Ian Jackson <Ian.Jackson@eu.citrix.com>:
>> > Ian Campbell writes ("Re: [Xen-devel] Driver domains and hotplug scripts, redux"):
>> >> The forceful destroy case is different, it is effectively:
>> >> 1. rm backend dir in xenstore.
>> >
>> > That's (iii). We want a way to do (ii) as well.
>>
>> From my point of view, (iii) should only happen after (i) or (ii) has
>> failed (timeout or error trying to unplug devices).
>
> There has to be a user option to ask for a "very forceful" detach.
Let's map current shutdown options to your points:
xl shutdown -> (i)
xl destroy -> (ii) or (iii) if timeout happens while trying to unplug devices.
xl destroy -f -> (iii)?
I guess adding a -f to destroy is easy and it should work as you
described in (iii).
>
>> What should we do with xend? Are we keeping it on 4.2? I'm asking this
>> because the changes I'm introducing disables some udev rules that are
>> needed for xend. The other option is to update xend to talk to
>> xenbackendd also.
>
> I think xend is not going to go away in 4.2, unfortunately.
I see pain.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* [Bug 44852] 3D Acceleration initialization failed for Fusion Wrestler 9808
From: bugzilla-daemon @ 2012-01-17 9:21 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-44852-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=44852
--- Comment #1 from samit vats <hysvats@gmail.com> 2012-01-17 01:21:50 PST ---
Created attachment 55663
--> https://bugs.freedesktop.org/attachment.cgi?id=55663
glxinfo
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH 8/8] dmaengine/dw_dmac: Add support for DMA_SLAVE_CONFIG
From: Viresh Kumar @ 2012-01-17 9:19 UTC (permalink / raw)
To: Linus Walleij
Cc: vinod.koul@intel.com, dan.j.williams@intel.com,
linux@arm.linux.org.uk, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Armando VISCONTI,
Shiraz HASHIM, Vipin KUMAR, Rajeev KUMAR, Deepak SIKRI,
Vipul Kumar SAMAR, Amit VIRDI, Pratyush ANAND, Bhupesh SHARMA,
viresh.linux@gmail.com, Bhavna YADAV, Vincenzo FRASCINO,
Mirko GARDI
In-Reply-To: <4F153C33.5060805@st.com>
On 1/17/2012 2:45 PM, Viresh Kumar wrote:
>>>>>> >>> >> + * Fix sconfig's burst size according to dw_dmac. We need to convert
>>>>>> >>> >> + * them as: 1 -> 0, 2 -> 1, 4 -> 2, 8 -> 3, 16 -> 4.
> I need above conversion. i.e. finding bit no. of first bit set.
Something like:
unsigned int v; // 32-bit word
unsigned int r = 0;
while (v >>= 1)
{
r++;
}
Probably find_first_bit() suits it.
--
viresh
^ permalink raw reply
* [Bug 44852] New: 3D Acceleration initialization failed for Fusion Wrestler 9808
From: bugzilla-daemon @ 2012-01-17 9:20 UTC (permalink / raw)
To: dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=44852
Bug #: 44852
Summary: 3D Acceleration initialization failed for Fusion
Wrestler 9808
Classification: Unclassified
Product: Mesa
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: All
Status: NEW
Severity: critical
Priority: medium
Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: hysvats@gmail.com
Driver Stack Details:
=========================
1) Kernel- 3.0.0-12-generice-pae (x86_64)
2) drm- 2.4.30
3) Mesa- 8.0-devel (git-3e18ad7)
4) Xorg-server- 1.10.1
5) xf86-video-ati- master
System Environment:
===================
Asic/Chipset : Fusion Wrestler 9808
O.S. : Ubuntu-11.10 (64 bit)
Processor : AMD E2-1800 APU @ 850 MHz
Memory : 4 GB
Steps to Reproduce:
===================
glxinfo output is as follows :
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x208)
Observation :
=============
1) Error message observed in Xorg.log : "EE) RADEON(0): Acceleration
initialization failed"
2) 3D Acceleration works fine for Fusion Wrestler 9802,9807 etc
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: Optimal XFS formatting options?
From: Michael Monnerie @ 2012-01-17 9:19 UTC (permalink / raw)
To: xfs, stan
In-Reply-To: <4F14EBAF.10808@hardwarefreak.com>
[-- Attachment #1.1: Type: Text/Plain, Size: 1379 bytes --]
On Dienstag, 17. Januar 2012 Stan Hoeppner wrote:
> Thanks for the correction/reminder Dave. So in this case the first
> sector of the first partition would need to reside at LBA1280 in this
> array (655360 byte stripe width, 1280 sectors/stripe), as the
> partition table itself is going to occupy some sectors at the
> beginning of the first stripe. By creating the partition at LBA1280
> we make sure the first sector of the XFS filesystem is aligned with
> the first sector of the 2nd stripe.
There's one big problem with that: Many people will sooner or later
expand and existing array. If you add one drive, all your nice stripe
width alignment becomes bogus, and suddenly your performance will drop.
There's no real way out of that, but three solutions come to my mind:
- backup before expand/restore after expand with new alignment
- leave existing data, just change mount options so after expansion at
least new files are going to be aligned to the new stripe width.
- expand array by factors of two. So if you have 10 data drives, add 10
data drives. But that creates other problems (probability of single
drive failure + time to recover a single broken disk)
--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc
it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: git-grep while excluding files in a blacklist
From: Nguyen Thai Ngoc Duy @ 2012-01-17 9:19 UTC (permalink / raw)
To: Dov Grobgeld; +Cc: git
In-Reply-To: <CA++fsGHGrNQzR-schP0yTXnD4jkYJjHHVk6QoJvfxPX9mguJPQ@mail.gmail.com>
On Tue, Jan 17, 2012 at 4:14 PM, Dov Grobgeld <dov.grobgeld@gmail.com> wrote:
> Does git-grep allow searching for a pattern in all files *except*
> files matching a pattern. E.g. in our project we have multiple DLL's
> in git, but when searching I would like to exclude these for speed. Is
> that possible with git-grep?
Not from command line, no. You can put "*.dll" to .gitignore file then
"git grep --exclude-standard".
--
Duy
^ permalink raw reply
* [PATCH 8/8] dmaengine/dw_dmac: Add support for DMA_SLAVE_CONFIG
From: Viresh Kumar @ 2012-01-17 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F153C33.5060805@st.com>
On 1/17/2012 2:45 PM, Viresh Kumar wrote:
>>>>>> >>> >> + * Fix sconfig's burst size according to dw_dmac. We need to convert
>>>>>> >>> >> + * them as: 1 -> 0, 2 -> 1, 4 -> 2, 8 -> 3, 16 -> 4.
> I need above conversion. i.e. finding bit no. of first bit set.
Something like:
unsigned int v; // 32-bit word
unsigned int r = 0;
while (v >>= 1)
{
r++;
}
Probably find_first_bit() suits it.
--
viresh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.