be the whole problem..
I'll see what you've got after the weekend ;D
Ta
Matt Sealey
h,
and the mess it introduces here belies the performance improvement
it provides. Versus the true scope of the code cleanup to do it
right, it's a very concise and reliable and within-style improvement.
Would we agree to let it in for now on the basis that we thought
about it but I side with MFXJO's urgency?
Ta!
Matt Sealey
Arm Partner Enablement Group
s only ever implemented in pairs in the kernel -
can you point out where this might not be the case in the future
(and why they couldn't still use COPY8 in that case)?
Ta!
Matt Sealey
Arm Partner Enablement Group
On 3 August 2018 at 13:25, Mikulas Patocka wrote:
>
>
> On Fri, 3 Aug 2018, Ard Biesheuvel wrote:
>
>> Are we still talking about overlapping unaligned accesses here? Or do
>> you see other failures as well?
>
> Yes - it is caused by overlapping unaligned accesses inside memcpy. When I
> put "dmb
The easiest explanation for this would be that the memory isn’t mapped
correctly. You can’t use PCIe memory spaces with anything other than
Device-nGnRE or stricter mappings. That’s just differences between the AMBA
and PCIe (posted/unposted) memory models.
Normal memory (cacheable or uncacheable,
Hi Rob,
To take this in a somewhat different direction...
> > No, the above comment is about using "unit" ( if it is a standard
> > property for specifying something specific to hardware) instead of
> > "coresight,hwid". I would prefer to stick to the DT graph bindings,
> > because :
>
> "unit" i
> -Original Message-
> From: Mathieu Poirier
>
> > So, if the suggestion is to use an existing property "unit", I am fine
> > with it, if people agree to it.
>
> If we're going to have something sharply different than ACPI I prefer
> Rob's idea.
What are you trying to say about being sh
Hi Suzuki,
> > Why not use “unit”?
> >
> > I believe we had this discussion years ago about numbering serial ports
> > and sdhci (i.e. how do you know it’s UART0 or UART1 from just the address?
> > Some SoC’s don’t address sequentially *or* in a forward direction) - I
> > believe it’s not exactly
Suzuki,
Why not use “unit”?
I believe we had this discussion years ago about numbering serial ports and
sdhci (i.e. how do you know it’s UART0 or UART1 from just the address? Some
SoC’s don’t address sequentially *or* in a forward direction) - I believe it’s
not exactly codified in ePAPR, not
Hi all,
> > I don't have any dog in this, but maybe if providing information to the
> > users is so essential to having a pleasant user experience, then
> > rethinking the whole way these messages are funneled is necessary
> > because the kernel log + dmesg is by no means appropriate. Take a look
Hiya,
On 25 January 2018 at 17:55, Channagoud Kadabi wrote:
> Documentation for last level cache controller device tree bindings,
> client bindings usage examples.
[snippety snip]
> +- llcc-bank-off:
> + Usage: required
> + Value Type:
> + Definition: Offsets of llcc banks fr
ever-updated custom
firmware binaries, so..
The best thing would be to pick up one of those boards and port a PSCI firmware
to it (ATF or your own..) and just embarrass the SoC vendor by having better
mainline power management support (implemented by 10 lines in a device tree)
with the comp
On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett wrote:
> On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote:
>
>> there's no guarantee that the kernel hasn't been decompressed over
>> some important UEFI feature or some memory hasn't been trashed. You
>
On Mon, Dec 2, 2013 at 3:07 PM, Leif Lindholm wrote:
> On Mon, Dec 02, 2013 at 01:51:22PM -0600, Matt Sealey wrote:
>> Here's where I think this whole thing falls down as being the weirdest
>> possible implementation of this. It defies logic to put this
>> information
ssentially meant Linux never took
advantage of the resources available. In OF's case, the CIF sucked by
specification. In UEFI's case here, it's been implemented in Linux in
such a way that guarantees poor-performing firmware code with huge
penalties to call them, which isn't even
nalty for the extra
branching, or the performance hit for the ARMv7-without-division
cases?
Ta,
Matt Sealey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
A good chunk of the original Debian arm
port probably would just pitch a SIGILL if you ran it under an Ubuntu
kernel).
I would ignore anyone who enables it in a distribution, since they
probably weren't intending to enable it in the first place, and never
noticed the.. what.. 3-4KiB it adds t
On Thu, Oct 24, 2013 at 2:12 PM, Rostislav Lisovy wrote:
> Dear Shawn;
> Thank you for your comments.
> Should I also add Voipac to
> Documentation/devicetree/bindings/vendor-prefixes.txt?
I would agree with that, but why is your chosen prefix "vp" instead of
"voipa
On Mon, Aug 19, 2013 at 11:59 AM, Ezequiel Garcia
wrote:
> On Mon, Aug 12, 2013 at 07:29:42PM +0100, Will Deacon wrote:
>
>> This means that you don't have ordering guarantees between the two accesses
>> outside of the CPU, potentially giving you:
>>
>> spin_lock(&__io_lock);
>> spin_u
On Fri, Aug 2, 2013 at 3:13 AM, Tony Lindgren wrote:
> * Mel Gorman [130731 08:28]:
>> On Wed, Jul 31, 2013 at 12:38:03AM -0700, Tony Lindgren wrote:
>> > Hi all,
>> >
>> > Probably the biggest kernel data bloat issue is in the ARM land, but
>> > it also seems that it's becoming a Linux generic i
1, 2013 at 11:35 AM, Heiko Stübner wrote:
> Am Montag, 29. Juli 2013, 23:39:45 schrieb Matt Sealey:
>> On Mon, Jul 29, 2013 at 9:02 AM, Philipp Zabel
> wrote:
>> > Hi Heiko,
>> >
>> > Am Montag, den 29.07.2013, 15:12 +0200 schrieb Heiko Stübner:
>> >
e syntax and definition as defining any
other chunk of memory, as OpenFirmware and device trees have been
doing since the dark ages. In this case, why not re-use the
"available" property name instead of creating a new one? Standard OF
memory parsing code is then free for you to use to
above. You can stop using stock tickers for new
company names, but anything that has been defined in a device tree
before has to stay that way, and all the manufacturer prefixes to
device names should be the same. What you're proposing is purely
driver bloat and increasing the size of kernel
On Tue, Jun 4, 2013 at 2:22 PM, Mike Turquette wrote:
> Quoting Matt Sealey (2013-06-04 10:39:53)
>> On Tue, Jun 4, 2013 at 12:11 PM, Stephen Boyd wrote:
>> > On 06/03/13 10:53, Mike Turquette wrote:
>> >> +Required properties:
>> >> +- compatible :
vider-table rather
than table, divider-range (modifying the idea above). While we're
inside a particular namespace in the binding I think naming properties
with their intent (i.e. what table is it?) is good behavior.
--
Matt Sealey
--
To unsubscribe from this list: send the line "
ot;.
> The blank line after "CPU revision" is fine.
>
> Also, please rename this to "System name". Not all systems are "on
> chip". By using "System name" this is more universally useful.
I can't agree with "System name", it is confus
el log.
>>
>
> Actually mode=200 might be better, as mode=500 is for asynchronous
> implementations and might use hardware crypto if such device/module is
> available.
Okeydokey I'll start running some tests..
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
On Mon, Jan 21, 2013 at 7:31 PM, John Stultz wrote:
> On 01/21/2013 05:06 PM, Matt Sealey wrote:
>>
>> On Mon, Jan 21, 2013 at 6:51 PM, John Stultz
>> wrote:
>>>
>>> On 01/21/2013 02:54 PM, Matt
On Mon, Jan 21, 2013 at 7:18 PM, Russell King - ARM Linux
wrote:
> On Mon, Jan 21, 2013 at 07:06:59PM -0600, Matt Sealey wrote:
>> On Mon, Jan 21, 2013 at 6:51 PM, John Stultz wrote:
>> > On 01/21/2013 02:54 PM, Matt Sealey wrote:
>
> sched_clock() has nothing to do wit
On Mon, Jan 21, 2013 at 6:51 PM, John Stultz wrote:
> On 01/21/2013 02:54 PM, Matt Sealey wrote:
>>
>> On Mon, Jan 21, 2013 at 4:36 PM, John Stultz
>> wrote:
>>>
>>> On 01/21/2013 01:14 PM, Matt Sealey wrote:
>
> As far as jiffies rating, from jiffies
On Mon, Jan 21, 2013 at 4:46 PM, Nicolas Pitre wrote:
> On Mon, 21 Jan 2013, Matt Sealey wrote:
>
>> The optimized assembler SHA1 code for ARM does not conform to Thumb2
>> register usage requirements, so it cannot be built when the kernel is
>> configured with THUMB2_KER
On Mon, Jan 21, 2013 at 6:09 PM, Matt Sealey wrote:
[LAKML: about lack of SCHED_HRTICK because we don't use
kernel/Kconfig.hz on ARM)]
> kind of leaves ARM in the doghouse.. who knows what weirdo scheduler
> reactions are related to it not being enabled. Maybe when it is, HZ
> *
eally freakish SMP architectures with no ability to use
GENERIC_SMP_HELPERS have ever run these code paths besides ARM. That
kind of leaves ARM in the doghouse.. who knows what weirdo scheduler
reactions are related to it not being enabled. Maybe when it is, HZ
*would* need to be allowed to be bumpe
On Mon, Jan 21, 2013 at 5:13 PM, Russell King - ARM Linux
wrote:
> On Mon, Jan 21, 2013 at 04:54:31PM -0600, Matt Sealey wrote:
>> Hmm, I think it might be appreciated for people looking at this stuff
>> (same as I stumbled into it) for a little comment on WHY the default
>>
On Mon, Jan 21, 2013 at 4:42 PM, Russell King - ARM Linux
wrote:
> On Mon, Jan 21, 2013 at 04:20:14PM -0600, Matt Sealey wrote:
>> I am sorry it sounded if I was being high and mighty about not being
>> able to select my own HZ (or being forced by Exynos to be 200 or by
>> n
On Mon, Jan 21, 2013 at 4:45 PM, Russell King - ARM Linux
wrote:
> On Mon, Jan 21, 2013 at 10:30:07PM +, Arnd Bergmann wrote:
>> On Monday 21 January 2013, Matt Sealey wrote:
>> > So is that a bug in that it is not available to ARM right now, a bug
>> > in that
On Mon, Jan 21, 2013 at 4:36 PM, John Stultz wrote:
> On 01/21/2013 01:14 PM, Matt Sealey wrote:
>>
>> On Mon, Jan 21, 2013 at 3:00 PM, John Stultz
>> wrote:
>>>
>>> On 01/21/2013 12:41 PM, Arnd Bergmann wrote:
>>>>
>>>> Right.
t timer divisor (OMAP says "Kernel internal timer
frequency should be a divisor of 32768") in which case their timer
drivers should not be so stupid and instead round down to the nearest
acceptable timer divisor or WARN_ON if the compile-time values are
unacceptable at runtime before anyone
nd explode if nobody registers a
non-jiffies sched_clock (since the jiffies clock is technically
reporting itself as a ridiculously high resolution clocksource..)?
Or is this one of those things that if your platform doesn't have a
real high resolution timer, you shouldn't enable HRTI
On Mon, Jan 21, 2013 at 2:41 PM, Arnd Bergmann wrote:
> On Monday 21 January 2013, Matt Sealey wrote:
>>
>> ARM seems to be the only "major" platform not using the
>> kernel/Kconfig.hz definitions, instead rolling it's own and setting
>> what could be des
and very strange re-calibrations popping out (with
constant rate for the timer, lpj goes down.. when using the
delay_timer implementation, shouldn't lpj be still relative to the
timer rate and NOT cpu frequency?) when using cpufreq on i.MX5 when I
do it, and whether CONFIG_SCHED_HRTICK is a go
d driver names,
and sets the appropriate num_regulators value. It also gives a little
warning for device tree authors that they MAY have screwed something up,
such that this patch does not hide the device tree authoring problem.
Signed-off-by: Matt Sealey
Tested-by: Steev Klimaszewski
Cc: Sh
the register.
* correct a comment in probe which is doing a version check. Magic
values are awful but for once instance, a comment does just as
good a job as something symbolic.
Signed-off-by: Matt Sealey
Tested-by: Steev Klimaszewski
Cc: Shawn Guo
Cc: Fabio Estevam
---
drivers/regulator/
The optimized assembler SHA1 code for ARM does not conform to Thumb2
register usage requirements, so it cannot be built when the kernel is
configured with THUMB2_KERNEL.
Fix the FTBFS for now by preventing misconfigurations of the kernel.
Signed-off-by: Matt Sealey
---
crypto/Kconfig |2
On Fri, Jan 18, 2013 at 10:46 PM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Jan 18, 2013 at 07:11:32PM -0600, Matt Sealey wrote:
>> On Fri, Jan 18, 2013 at 3:08 PM, Russell King - ARM Linux
>>
>> I'm gonna put this out to the maintainers (Konrad, and Seth since he
>>
Hi Minchan,
On Sun, Jan 20, 2013 at 11:55 PM, Minchan Kim wrote:
> On Fri, Jan 18, 2013 at 11:46:02PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Jan 18, 2013 at 07:11:32PM -0600, Matt Sealey wrote:
>> >
>> > diff --git a/drivers/staging/zsmalloc/zsmalloc-ma
On Fri, Jan 18, 2013 at 3:08 PM, Russell King - ARM Linux
wrote:
> On Fri, Jan 18, 2013 at 02:24:15PM -0600, Matt Sealey wrote:
>> Hello all,
>>
>> I wonder if anyone can shed some light on this linking problem I have
>> right now. If I configure my kernel withou
eems like it should
exist even on UP, to me.
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordo
Since Efika MX platform support (pre-devicetree) was removed from the tree
this code no longer has any possibility of running and clutters up the
driver which is being replaced by the chipidea host in the future anyway.
Signed-off-by: Matt Sealey
Tested-by: Steev Klimazewski
CC: Sascha Hauer
Since Efika MX platform support (pre-devicetree) was removed from the tree
this code no longer has any possibility of running and clutters up the
driver which is being replaced by the chipidea host in the future anyway.
Signed-off-by: Matt Sealey
Tested-by: Steev Klimazewski
CC: Sascha Hauer
to go
through a strange and unusual path for suspend and resume which leaves
ALL cards 'mounted' unecessarily over suspend/resume, especially in
the common case where eMMC is also not the ONLY boot medium (PATA,
SATA, non-eMMC flash) and eMMC or SD *MAY* only be the root filesystem
(as oppos
On Sun, Sep 9, 2012 at 10:00 PM, Fabio Estevam wrote:
> On Wed, Aug 1, 2012 at 2:49 PM, Matt Sealey wrote:
>> Since we're removing Efika MX support from the tree (for now), remove
>> the hack present in the USB host driver since it will never run and
>> isn
On Mon, Aug 13, 2012 at 12:38 PM, Mark Brown
wrote:
> On Mon, Aug 13, 2012 at 10:42:58AM -0500, Matt Sealey wrote:
>> On Thu, Aug 9, 2012 at 5:19 AM, Mark Brown
>
>> > This and many of your other regulators have voltage ranges specified but
>> > no consumers which
On Thu, Aug 9, 2012 at 5:19 AM, Mark Brown
wrote:
> On Tue, Aug 07, 2012 at 04:46:18PM -0500, Matt Sealey wrote:
>
> Yay for indentation! It'd be good to rewrite your DT so you could cut
> down on that, at the minute it's n
ally a Smarttop.
Sure, it's not as fun as using the real SPI, I2C buses and you don't
get a UART, but it's possible.
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
On Fri, Aug 10, 2012 at 9:26 AM, Matt Sealey wrote:
> On Fri, Aug 10, 2012 at 9:04 AM, Shawn Guo
On Fri, Aug 10, 2012 at 9:04 AM, Shawn Guo wrote:
> On Fri, Aug 10, 2012 at 08:36:02AM -0500, Matt Sealey wrote:
>> Requiring it breaks the entire concept of the device tree to describe running
>> hardware. It is not a configuration script. pinctrl should be optional
>> - bu
On Thu, Aug 9, 2012 at 8:41 PM, Shawn Guo wrote:
> On Thu, Aug 09, 2012 at 09:29:39AM -0500, Matt Sealey wrote:
>> The reason the new kernel depends on the new U-Boot is we're trying to
>> do all pinmux configuration in U-Boot (and we do in-house, and it
>> works). No p
On Thu, Aug 9, 2012 at 9:50 AM, Dave Martin wrote:
> On Thu, Aug 09, 2012 at 09:32:59AM -0500, Matt Sealey wrote:
>> Matt Sealey
>> Product Development Analyst, Genesi USA, Inc.
>>
>>
>> On Thu, Aug 9, 2012 at 5:24 AM, Dave Martin wrote:
>> > On W
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
On Thu, Aug 9, 2012 at 5:24 AM, Dave Martin wrote:
> On Wed, Aug 08, 2012 at 12:32:39PM -0500, Matt Sealey wrote:
>
> [...]
>
>> I'm going to do a trapse through and find where Russell nacked Dave's
>>
On Wed, Aug 8, 2012 at 12:19 PM, Fabio Estevam wrote:
> Matt,
>
> On Wed, Aug 8, 2012 at 1:55 PM, Matt Sealey wrote:
>
> ...
>> or any setup at all for this. What's stopping this right now is you
>> need a new U-Boot which we
>> didn't release or main
On Thu, Aug 9, 2012 at 5:19 AM, Mark Brown
wrote:
> On Tue, Aug 07, 2012 at 04:46:18PM -0500, Matt Sealey wrote:
>
> Yay for indentation! It'd be good to rewrite your DT so you could cut
> down on that, at the minute it's n
ite.. would you mind if you have any of these boards seeing if it
really DOES
cause broken code? The moment we noticed this was broken we quit designing
with AC97 codecs, so there's no Genesi board of similar pedigree
around that ever
got to a PCB..
--
Matt Sealey
Product Development Analyst, Gen
On Wed, Aug 8, 2012 at 10:15 AM, Shawn Guo wrote:
> On Tue, Aug 07, 2012 at 04:46:18PM -0500, Matt Sealey wrote:
>> This device tree only supports the final retail board ("TO3").
>>
>> It is currently feature equivalent to the MX51 Babbage device tree. The
>>
imx_v6_v7_defconfig
or wanting to remove certain boards from their configs.
Matt Sealey (2):
ARM: build ssi-fiq.S in ARM mode to prevent CONFIG_THUMB2_KERNEL
build breakage
ARM: only build ssi-fiq.S et al if CONFIG_SND_IMX_SOC_PCM_FIQ is
selected
arch/arm/plat-mxc/Makefile |2 +-
arch/arm
Thumb2 code. This also makes rewriting the
code as Thumb-compatible kind of redundant. But since one Eukrea board audio
driver needs it, and there is an i.MX51 CPU module for this board, it gets
pulled in for imx_v6_v7_defconfig too, making this a necessity.
Signed-off-by: Matt Sealey
---
arch
eople reconfiguring their kernels more sparsely than the
default.
Signed-off-by: Matt Sealey
Acked-by: Shawn Guo
---
arch/arm/plat-mxc/Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/plat-mxc/Makefile b/arch/arm/plat-mxc/Makefile
index 6ac7200..89927f5 1
a lack of drivers or device tree bindings currently.
Signed-off-by: Matt Sealey
Signed-off-by: Steev Klimaszewski
---
arch/arm/boot/dts/imx51-efikamx.dts | 247 +++
arch/arm/mach-imx/Makefile.boot |2 +-
2 files changed, 248 insertions(+), 1 deletion(-)
c
boot, DEBUG_LL needs to be enabled
and a valid UART for the booting board needs to be configured for it to
show any result, but this is true of all the above warnings anyway,
otherwise all you get is Starting Kernel and a blinking terminal prompt.
Signed-off-by: Matt Sealey
Tested-by: Ste
On Mon, Aug 6, 2012 at 4:41 PM, Mark Brown
wrote:
> On Mon, Aug 06, 2012 at 03:39:50PM -0500, Matt Sealey wrote:
>> On Mon, Aug 6, 2012 at 3:16 PM, Robert Schwebel
>
>> > That's not true; we still run MX25, MX27, MX35, MX28 on mainline in
>> > active projects.
Sascha to pipe up and tell me what the code is needed
for exactly again.. and someone to test the result of the changes..
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Mon, Aug 6, 2012 at 10:49 AM, Mark Brown
wrote:
> On Mon, Aug 06, 2012 at 10:19:50AM -0500, Matt Sealey wrote:
>
>> it's not compiled in unless absolutely necessary. However, there was a
>> rumble that this code may disappear or be reworked in the future
>> mak
t;user" of
"FIQ" in the Kconfigs going away now all the FIQ-specific symbols went
away outside of the generic irq subsystem?
I will probably throw out all three today anyway, but I thought it
would make a good discussion anyway.
--
Matt Sealey
Product Development Analyst, Gene
Delete the files that can no longer be built.
Signed-off-by: Matt Sealey
---
arch/arm/mach-imx/efika.h | 10 -
arch/arm/mach-imx/mach-mx51_efikamx.c | 300
arch/arm/mach-imx/mach-mx51_efikasb.c | 296 ---
arch/arm/mach-imx/mx51_efika.c| 632
No need to have Efika MX listed in the defconfig if it can't be built.
Signed-off-by: Matt Sealey
---
arch/arm/configs/imx_v6_v7_defconfig |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig
b/arch/arm/configs/imx_v6_v7_defconfig
index b1d3675..0b
Since we're removing Efika MX support from the tree (for now), remove
the hack present in the USB host driver since it will never run and
isn't useful on any other systems.
Signed-off-by: Matt Sealey
---
drivers/usb/host/ehci-mxc.c | 20
1 file changed, 20
Disable building for Efika MX boards by not having any configuration or
object file definitions.
Signed-off-by: Matt Sealey
---
arch/arm/mach-imx/Kconfig | 26 --
arch/arm/mach-imx/Makefile |3 ---
2 files changed, 29 deletions(-)
diff --git a/arch/arm/mach-imx
rts by external developers wishing to
run modern kernels on Genesi Efika MX boards should be directed at device tree
support for the MX51 platforms.
Matt Sealey (4):
efikamx: remove support for Genesi Efika MX from the build
efikamx: remove Genesi Efika MX from the i.MX v6/v7 defconfig
ed again in other changes, I
think the device tree should be fixed at the firmware level and
not in the kernel.
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Chuck Ebbert wrote:
Without this patch, taken from a Suse 2.6.22 kernel, the Pegasos
PPC machines can
work on the script
instead.
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info
ype in the boot
wrapper (be it the chrp boot loader) is the wrong place, because we have
had real experts here (Ben, Segher etc.) complain that fixing the device
tree in the boot wrapper is no substitute for a correctly working
firmware.
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, D
se
200 lines of code to work around Efika device tree mistakes you yourself
complained about at Christmas last year..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
ure requests before we waste time on stuff
bplan is silently fixing.
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Alan Curry wrote:
Matt Sealey writes the following:
Yeah please do a fixup for the boot wrapper.
Or, if you have trouble, go into the firmware an
code+ s" ranges" property
device-end
If anyone wants to test and confirm the 8042 fix and then we can add
it to the end here.. we can unclutter the kernel.
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Matt Sealey wrote:
Yeah please do a fixup for the boot wra
e patch first, on the firmware console, just to be sure I got it right,
because I can't test it here)
You don't need to patch Linux at all. In fact for silly things like this
I would recommend against it :)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
ualisation options would help eke out
more value ;)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kern
isting all your disks
present, and even then, Linux will redetect all of these with native
drivers and give them new names anyway. In fact, Solaris does the
same (but it is better about associating the device tree entries
than Linux)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Develo
t the CPU core anyway, which I think is probably a
good thing from a system integration and possibly the point of
view of redundancy..)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
p for to find an example (I wonder if
we have any candidates in the ppc tree mostly..)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mor
Kumar Gala wrote:
>
> On May 18, 2007, at 9:48 AM, Thomas Gleixner wrote:
>
>> On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote:
>>>
>>> I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly
>>> easily.
>>
>> Ther
I already have that stuff, but it only implements the decrementer (in fact
it's the patch submitted at the beginning of this thread).
I got it because I was far more interested in the GPIO handling..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Thomas Gle
D users for at least 2 or 3 independant, high resolution
timer interrupt sources beyond dynticks and nanosleep, but perhaps it
is too early (hrtimers were only integrated 6 months? ago, dynticks
is still brand new in mainline?) and I am being a bit impatient?
--
Matt Sealey <[EMAIL PROTE
handling interrupts?
The 52XX has 8 general purpose timers and 2 slice timers. Both will
generate an interrupt once the clock hits a preset value, the timing
of which is determined by prescalers and the IPB clock..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
-
To unsub
Kristen Carlson Accardi wrote:
> On Wed, 25 Apr 2007 20:16:51 +0100
> Matt Sealey <[EMAIL PROTECTED]> wrote:
>
>>> +#define ata_id_has_AN(id) \
>>> + ( (((id)[76] != 0x) && ((id)[76] != 0x)) && \
>>> + ((id)[78] & (1
= (1 << 3), /* device supports NCQ */
> ATA_DFLAG_FLUSH_EXT = (1 << 4), /* do FLUSH_EXT instead of FLUSH */
> + ATA_DFLAG_AN= (1 << 5), /* device supports Async
> notification */
> ATA_DFLAG_CFG_MASK = (1 << 8) - 1,
94 matches
Mail list logo
