* RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
From: Aggrwal Poonam-B10812 @ 2010-06-16 7:29 UTC (permalink / raw)
To: Micha Nelissen, linuxppc-dev
In-Reply-To: <4C187616.4000303@neli.hopto.org>
> -----Original Message-----
> From:
linuxppc-dev-bounces+poonam.aggrwal=3Dfreescale.com@lists.ozlabs.org
> [mailto:linuxppc-dev-
> bounces+poonam.aggrwal=3Dfreescale.com@lists.ozlabs.org] On Behalf Of
Micha
> Nelissen
> Sent: Wednesday, June 16, 2010 12:29 PM
> To: linuxppc-dev@lists.ozlabs.org
> Subject: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
>=20
> Hi,
>=20
> Attached is a patch to fix large physical address support for the
e500v2
> core. When >4GB addresses are used, the MAS7 register needs to be
valid
> for tlbsx instruction usage.
>=20
> Please review and apply.
[Aggrwal Poonam] This is already being done by u-boot, should linux set
it again?
>=20
> Micha
^ permalink raw reply
* Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)
From: Anatolij Gustschin @ 2010-06-16 7:38 UTC (permalink / raw)
To: Timur Tabi
Cc: linux-fbdev, wd, dzu, devicetree-discuss, linuxppc-dev, yorksun
In-Reply-To: <AANLkTims596hCnLgN5Po6nS1bRFxKywEDlBA4mlreciV@mail.gmail.com>
Hi Timur,
On Fri, 4 Jun 2010 10:46:28 -0500
Timur Tabi <timur@freescale.com> wrote:
> On Tue, Jun 1, 2010 at 4:38 AM, Anatolij Gustschin <agust@denx.de> wrote:
>
> > Could you please test these patches on MPC8610 HPCD? I think these
> > changes won't break that platform. The patches apply cleanly on
> > 2.6.35-rc1.
>
> I'll try to get to them as soon as I can.
Any chance this could be done soon? I'd like to include the MPC5121e DIU
support in 2.6.36 since it is currently broken in mainline and the patches
provide the fix.
Thanks,
Anatolij
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-16 7:40 UTC (permalink / raw)
To: Mike Rapoport
Cc: Nicolas Pitre, microblaze-uclinux, devicetree-discuss,
Jamie Lokier, linuxppc-dev, Dan Malek, Jeremy Kerr,
linux-arm-kernel, David Gibson
In-Reply-To: <4C18738C.4090809@compulab.co.il>
Mike Rapoport wrote:
> Mitch Bradley wrote:
>> Mike Rapoport wrote:
>>> Mitch Bradley wrote:
>>>> Mike Rapoport wrote:
>>>>> Mitch Bradley wrote:
>>>>>
>>>>>> The second topic is the hypothetical use of OFW as a HAL. That
>>>>>> will not happen for several reasons. The opposition to the idea
>>>>>> is widespread and deeply held, and there are good arguments to
>>>>>> support that opposition. Furthermore, the economic conditions
>>>>>> necessary for the creation of such a HAL do not exist in the ARM
>>>>>> world, nor indeed in the Linux world in general. (The necessary
>>>>>> condition is the ability for one company to impose a substantial
>>>>>> change by fiat - essentially a monopoly position.)
>>>>>>
>>>>>> Shall we agree, then, that any further discussion of the HAL
>>>>>> issue is "just for fun", and that nobody needs to feel threatened
>>>>>> that it would actually happen?
>>>>>
>>>>> I've recently worked with vendor versions of U-Boot for advanced
>>>>> ARM SoCs. There is already *huge* chunk of HAL code in those
>>>>> versions. And if there would be possibility to have callbacks into
>>>>> the firmware these chunks would only grow, IMHO.
>>>>
>>>> How can there be HAL code in U-Boot unless there is already the
>>>> possibility to have callbacks into the firmware?
>>>
>>> Currently it aims to abstract hardware from U-Boot and reuse the
>>> same HW access code across operating systems and bootloaders. If
>>> this code would have callbacks I afraid the things would became worse.
>>
>> The only way I can understand what you said is if I assume that by
>> "callback", you mean the following sequence:
>>
>> a) U-boot loads and executes the OS, providing to the OS the address
>> of some HW access routines that it can use
>> b) The OS calls one of those HW access routines
>> c) During the execution of that HW access routine, that routine calls
>> "back" into the OS, before returning. So a call into the OS is
>> nested inside a call into U-boot resident code.
>>
>> If that is what you are worried about, it is not what we were
>> discussing. We were discussing - and many people were against - step
>> (b).
>>
>> Are you saying that step (b) - the OS calling into routines provided
>> by U-Boot - is already the status quo?
>
> I'm also objecting the step (b) and, fortunately, it's not yet the
> status quo.
> Current U-Boot/kernel implementations I've encountered still do not
> have OS calls to resident HW access routines. But if such calls would
> be allowed, my impression is that SoC vendors would make extensive use
> of them.
One could argue that a feature that vendors would use extensively is one
that is sorely needed from their point of view.
One counterargument, of course, is that "there is a better way". But it
is only "better" under a cost function that values things differently
than the vendors value them. Were that not so, the vendors would gladly
use the "better" way and not be tempted to use the objectionable
feature. (Unless, of course, the vendors are just ignorant or unskilled
- but I generally find that different cost functions cause more
disconnects than lack of ability.)
Which of course raises the question: How does the Linux community view
such SoC vendors? Are they embraced and eagerly supported, or (either
openly or secretly) viewed as a nuisance? How does the widespread
objection to something that such vendors "would make extensive use of"
mesh with that view?
>
>>>
>>>> It is not HAL if it can't be called.
>>>>
>>>>>
>>>>>
>>>>>> The potential for "vendors breaking out of the debugging use case
>>>>>> and turning it into a HAL" is miniscule, because
>>>>>>
>>>>>> a) The callback is disabled by default
>>>>>> b) The technical challenges of the callback interface limit its
>>>>>> applicability to specific "wizard user" scenarios
>>>>>> c) OFW is unlikely to achieve sufficient market penetration for
>>>>>> the HAL thing to be worth doing
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> linux-arm-kernel mailing list
>>>>>> linux-arm-kernel@lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>>>
>>>>>
>>>
>>>
>
>
^ permalink raw reply
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
From: Micha Nelissen @ 2010-06-16 9:24 UTC (permalink / raw)
To: Aggrwal Poonam-B10812, linuxppc-dev
In-Reply-To: <8660DA277DC57B4BAAC78225F03146B6AB1B5C@zin33exm24.fsl.freescale.net>
Aggrwal Poonam-B10812 wrote:
>> Attached is a patch to fix large physical address support for the
>
> This is already being done by u-boot, should linux set it again?
Yikes! Took me 5 min to reformat your email.
Our version of U-boot does not but it's not latest greatest.
IMHO:
1) Linux should not be dependent on U-boot or any other bootloader, or
at least as possible
2) U-boot cannot (and does not want to) know whether Linux is going to
use large physical addresses.
Regards,
Micha
^ permalink raw reply
* Re: Request review of device tree documentation
From: Vladimir Pantelic @ 2010-06-16 9:45 UTC (permalink / raw)
To: Mitch Bradley
Cc: Nicolas Pitre, microblaze-uclinux, devicetree-discuss,
Jamie Lokier, linuxppc-dev, Mike Rapoport, Dan Malek, Jeremy Kerr,
linux-arm-kernel, David Gibson
In-Reply-To: <4C187FF0.5020806@firmworks.com>
Mitch Bradley wrote:
>> I'm also objecting the step (b) and, fortunately, it's not yet the
>> status quo.
>> Current U-Boot/kernel implementations I've encountered still do not
>> have OS calls to resident HW access routines. But if such calls would
>> be allowed, my impression is that SoC vendors would make extensive use
>> of them.
>
> One could argue that a feature that vendors would use extensively is one
> that is sorely needed from their point of view.
yes, it would free them from writing these pesky linux drivers and getting
them into mainline :)
^ permalink raw reply
* Re: [PATCH 12/12] ptp: Added a clock driver for the National Semiconductor PHYTER.
From: Richard Cochran @ 2010-06-16 10:05 UTC (permalink / raw)
To: Grant Likely
Cc: netdev, devicetree-discuss, linuxppc-dev, linux-arm-kernel,
Krzysztof Halasa
In-Reply-To: <AANLkTilqd-wxqMWDxssC-XMDJqZ8iIiSrvp2t8xARAQV@mail.gmail.com>
On Tue, Jun 15, 2010 at 12:49:13PM -0600, Grant Likely wrote:
> Won't this break things for existing DP83640 users?
Nope, the driver was only added five patches ago, and it only offers
the timestamping stuff. The standard PHY functions just call the
generic functions, so the PHY works fine even without this driver.
> > +static struct ptp_clock *dp83640_clock;
> > +DEFINE_SPINLOCK(clock_lock); /* protects the one and only dp83640_clock */
>
> Why only one? Is it not possible to have 2 of these PHYs in a system?
Yes, you can have multiple PHYs, but only one PTP clock.
If you do use multiple PHYs, then you must wire their clocks together
and adjust the PTP clock on only one of the PHYs.
Thanks for your other comments,
Richard
^ permalink raw reply
* [PATCH 2.6.35 v3] powerpc: fix logic error in fixup_irqs
From: Johannes Berg @ 2010-06-16 10:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, alastair.bridgewater
In-Reply-To: <1276289669.3918.3.camel@jlt3.sipsolutions.net>
When SPARSE_IRQ is set, irq_to_desc() can
return NULL. While the code here has a
check for NULL, it's not really correct.
Fix it by separating the check for it.
This fixes CPU hot unplug for me.
Reported-by: Alastair Bridgewater <alastair.bridgewater@gmail.com>
Cc: stable@kernel.org [2.6.32+]
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
v2: cc Alastair, sorry
v3: indicate stable versions
arch/powerpc/kernel/irq.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- wireless-testing.orig/arch/powerpc/kernel/irq.c 2010-06-11 22:51:08.000000000 +0200
+++ wireless-testing/arch/powerpc/kernel/irq.c 2010-06-11 22:54:11.000000000 +0200
@@ -295,7 +295,10 @@ void fixup_irqs(const struct cpumask *ma
for_each_irq(irq) {
desc = irq_to_desc(irq);
- if (desc && desc->status & IRQ_PER_CPU)
+ if (!desc)
+ continue;
+
+ if (desc->status & IRQ_PER_CPU)
continue;
cpumask_and(mask, desc->affinity, map);
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mike Rapoport @ 2010-06-16 10:39 UTC (permalink / raw)
To: Mitch Bradley
Cc: Nicolas Pitre, microblaze-uclinux, devicetree-discuss,
Jamie Lokier, linuxppc-dev, Mike Rapoport, Dan Malek, Jeremy Kerr,
linux-arm-kernel, David Gibson
In-Reply-To: <4C187FF0.5020806@firmworks.com>
Mitch Bradley wrote:
> Mike Rapoport wrote:
>> Mitch Bradley wrote:
>>> Mike Rapoport wrote:
>>>> Mitch Bradley wrote:
>>>>> Mike Rapoport wrote:
>>>>>> Mitch Bradley wrote:
>>>>>>
>>>>>>> The second topic is the hypothetical use of OFW as a HAL. That
>>>>>>> will not happen for several reasons. The opposition to the idea
>>>>>>> is widespread and deeply held, and there are good arguments to
>>>>>>> support that opposition. Furthermore, the economic conditions
>>>>>>> necessary for the creation of such a HAL do not exist in the ARM
>>>>>>> world, nor indeed in the Linux world in general. (The necessary
>>>>>>> condition is the ability for one company to impose a substantial
>>>>>>> change by fiat - essentially a monopoly position.)
>>>>>>>
>>>>>>> Shall we agree, then, that any further discussion of the HAL
>>>>>>> issue is "just for fun", and that nobody needs to feel threatened
>>>>>>> that it would actually happen?
>>>>>>
>>>>>> I've recently worked with vendor versions of U-Boot for advanced
>>>>>> ARM SoCs. There is already *huge* chunk of HAL code in those
>>>>>> versions. And if there would be possibility to have callbacks into
>>>>>> the firmware these chunks would only grow, IMHO.
>>>>>
>>>>> How can there be HAL code in U-Boot unless there is already the
>>>>> possibility to have callbacks into the firmware?
>>>>
>>>> Currently it aims to abstract hardware from U-Boot and reuse the
>>>> same HW access code across operating systems and bootloaders. If
>>>> this code would have callbacks I afraid the things would became worse.
>>>
>>> The only way I can understand what you said is if I assume that by
>>> "callback", you mean the following sequence:
>>>
>>> a) U-boot loads and executes the OS, providing to the OS the address
>>> of some HW access routines that it can use
>>> b) The OS calls one of those HW access routines
>>> c) During the execution of that HW access routine, that routine calls
>>> "back" into the OS, before returning. So a call into the OS is
>>> nested inside a call into U-boot resident code.
>>>
>>> If that is what you are worried about, it is not what we were
>>> discussing. We were discussing - and many people were against - step
>>> (b).
>>>
>>> Are you saying that step (b) - the OS calling into routines provided
>>> by U-Boot - is already the status quo?
>>
>> I'm also objecting the step (b) and, fortunately, it's not yet the
>> status quo.
>> Current U-Boot/kernel implementations I've encountered still do not
>> have OS calls to resident HW access routines. But if such calls would
>> be allowed, my impression is that SoC vendors would make extensive use
>> of them.
>
> One could argue that a feature that vendors would use extensively is one
> that is sorely needed from their point of view.
>
> One counterargument, of course, is that "there is a better way". But it
> is only "better" under a cost function that values things differently
> than the vendors value them. Were that not so, the vendors would gladly
> use the "better" way and not be tempted to use the objectionable
> feature. (Unless, of course, the vendors are just ignorant or unskilled
> - but I generally find that different cost functions cause more
> disconnects than lack of ability.)
It's hardly arguable that Linux community and decision makers at chip
vendor companies use different cost functions. But it's not that obvious
that vendors cost functions based on well established _technical_ analysis.
Many vendors try to use the same code base for several operating
systems. From the high level perspective it sounds logical: use the same
core functionality and thin adaptation layers to fit the core
functionality into several OSes. But in reality, developing the OS
abstraction layer and "thin" adaptation layers may become more expensive
than developing each OS support from scratch. Besides, such code becomes
a real mess after a while, and it's maintainability is very questionable.
> Which of course raises the question: How does the Linux community view
> such SoC vendors? Are they embraced and eagerly supported, or (either
> openly or secretly) viewed as a nuisance? How does the widespread
> objection to something that such vendors "would make extensive use of"
> mesh with that view?
I cannot tell for the entire Linux community, but from what I know, such
vendors are not much welcomed in the community.
>>
>>>>
>>>>> It is not HAL if it can't be called.
>>>>>
>>>>>>
>>>>>>
>>>>>>> The potential for "vendors breaking out of the debugging use case
>>>>>>> and turning it into a HAL" is miniscule, because
>>>>>>>
>>>>>>> a) The callback is disabled by default
>>>>>>> b) The technical challenges of the callback interface limit its
>>>>>>> applicability to specific "wizard user" scenarios
>>>>>>> c) OFW is unlikely to achieve sufficient market penetration for
>>>>>>> the HAL thing to be worth doing
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> linux-arm-kernel mailing list
>>>>>>> linux-arm-kernel@lists.infradead.org
>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
--
Sincerely yours,
Mike.
^ permalink raw reply
* RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
From: Aggrwal Poonam-B10812 @ 2010-06-16 10:49 UTC (permalink / raw)
To: Micha Nelissen, linuxppc-dev
In-Reply-To: <4C189860.3040702@neli.hopto.org>
> -----Original Message-----
> From: Micha Nelissen [mailto:micha@neli.hopto.org]
> Sent: Wednesday, June 16, 2010 2:55 PM
> To: Aggrwal Poonam-B10812; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
>=20
> Aggrwal Poonam-B10812 wrote:
> >> Attached is a patch to fix large physical address support for the
> >
> > This is already being done by u-boot, should linux set it again?
>=20
> Yikes! Took me 5 min to reformat your email.
>=20
> Our version of U-boot does not but it's not latest greatest.
>=20
> IMHO:
> 1) Linux should not be dependent on U-boot or any other bootloader, or
at
> least as possible
> 2) U-boot cannot (and does not want to) know whether Linux is going to
> use large physical addresses.
>=20
Not sure of other platforms but on 85xx platforms on which I am
currently working u-boot does LAW and eLBC programming for 36bit
physical address. Hence=20
possibly u-boot has to made aware of large physical address space.
Please correct me if I am wrong.
> Regards,
>=20
> Micha
^ permalink raw reply
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
From: Micha Nelissen @ 2010-06-16 11:34 UTC (permalink / raw)
To: Aggrwal Poonam-B10812; +Cc: linuxppc-dev
In-Reply-To: <8660DA277DC57B4BAAC78225F03146B6AB1BB3@zin33exm24.fsl.freescale.net>
Aggrwal Poonam-B10812 wrote:
> Not sure of other platforms but on 85xx platforms on which I am
> currently working u-boot does LAW and eLBC programming for 36bit
> physical address. Hence
> possibly u-boot has to made aware of large physical address space.
> Please correct me if I am wrong.
Yes, I can understand this for SDRAM and local flash interface. For
RapidIO we have (local) patches to pass the law address range in the
dtb. Perhaps also for PCI-express this might be done; U-boot has nothing
to with these high speed interfaces (in our case at least).
Micha
^ permalink raw reply
* RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
From: Aggrwal Poonam-B10812 @ 2010-06-16 11:38 UTC (permalink / raw)
To: Micha Nelissen; +Cc: linuxppc-dev
In-Reply-To: <4C18B6AD.3030200@neli.hopto.org>
> -----Original Message-----
> From: Micha Nelissen [mailto:micha@neli.hopto.org]
> Sent: Wednesday, June 16, 2010 5:04 PM
> To: Aggrwal Poonam-B10812
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
>=20
> Aggrwal Poonam-B10812 wrote:
> > Not sure of other platforms but on 85xx platforms on which I am
> > currently working u-boot does LAW and eLBC programming for 36bit
> > physical address. Hence possibly u-boot has to made aware of large
> > physical address space.
> > Please correct me if I am wrong.
>=20
> Yes, I can understand this for SDRAM and local flash interface. For
> RapidIO we have (local) patches to pass the law address range in the
dtb.
> Perhaps also for PCI-express this might be done; U-boot has nothing to
> with these high speed interfaces (in our case at least).
You are correct , for PCIe and SRIO kinds of interfaces Linux reprograms
the address windows.
Thanks
Poonam
>=20
> Micha
^ permalink raw reply
* Re: Request review of device tree documentation
From: Jamie Lokier @ 2010-06-16 11:41 UTC (permalink / raw)
To: Mike Rapoport
Cc: Nicolas Pitre, microblaze-uclinux, devicetree-discuss,
linuxppc-dev, Mitch Bradley, Dan Malek, Jeremy Kerr,
linux-arm-kernel, David Gibson
In-Reply-To: <4C18A9C7.5070800@compulab.co.il>
Mike Rapoport wrote:
> >Which of course raises the question: How does the Linux community view
> >such SoC vendors? Are they embraced and eagerly supported, or (either
> >openly or secretly) viewed as a nuisance? How does the widespread
> >objection to something that such vendors "would make extensive use of"
> >mesh with that view?
>
> I cannot tell for the entire Linux community, but from what I know, such
> vendors are not much welcomed in the community.
As far as I can tell, many such vendors don't have much interest in
contributing to the Linux community either. They use Linux code, glue
in their black-box binary modules and/or HALs, and engage poorly with
the community. It is not just end-product makers, but upstream
component, board and SDK manufacturers too.
-- Jamie
^ permalink raw reply
* Re: Request review of device tree documentation
From: Jamie Bennett @ 2010-06-16 13:48 UTC (permalink / raw)
To: Jamie Lokier
Cc: Nicolas Pitre, microblaze-uclinux, devicetree-discuss,
linuxppc-dev, Mike Rapoport, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <20100616114151.GB15054@shareable.org>
On 16 Jun 2010, at 12:41, Jamie Lokier wrote:
> Mike Rapoport wrote:
>>> Which of course raises the question: How does the Linux community view
>>> such SoC vendors? Are they embraced and eagerly supported, or (either
>>> openly or secretly) viewed as a nuisance? How does the widespread
>>> objection to something that such vendors "would make extensive use of"
>>> mesh with that view?
>>
>> I cannot tell for the entire Linux community, but from what I know, such
>> vendors are not much welcomed in the community.
>
> As far as I can tell, many such vendors don't have much interest in
> contributing to the Linux community either. They use Linux code, glue
> in their black-box binary modules and/or HALs, and engage poorly with
> the community. It is not just end-product makers, but upstream
> component, board and SDK manufacturers too.
That is what we are trying to change [1].
> -- Jamie
Regards,
Jamie.
[1] http://www.linaro.org
^ permalink raw reply
* Re: [PATCH 08/12] ptp: Added a brand new class driver for ptp clocks.
From: Richard Cochran @ 2010-06-16 14:22 UTC (permalink / raw)
To: Grant Likely
Cc: netdev, devicetree-discuss, Thomas Gleixner, linuxppc-dev,
linux-arm-kernel, Krzysztof Halasa
In-Reply-To: <AANLkTin4lYghEWhjzEyARvYDgHaXdniwLbfyZ4jY0rwm@mail.gmail.com>
On Tue, Jun 15, 2010 at 11:00:10AM -0600, Grant Likely wrote:
>
> Question from an ignorant reviewer: Why a new interface instead of
> working with the existing high resolution timers infrastructure?
Short answer: Timers are only one part of the PTP API. If you offer
the PTP clock as a Linux clock source, then you could just use the
existing POSIX timers. However, we decided not to offer the PTP clock
in that way. The following excerpts from an upcoming paper explain
why:
\subsection{Basic Clock Operations}
Based on our experience with a number of commercially available
hardware clocks, we identified a set of four basic clock
operations. Besides simply setting or getting the clock's time
value, two additional operations are needed for clock control.
Once a PTP slave has an initial estimate of the offset to its
master, it typically would need to shift the clock by the offset
atomically. Also, the servo loop of a slave periodically needs to
adjust the clock frequency.
\subsection{Ancillary Clock Features}
Perhaps the most challenging design issue was deciding how to offer
a PTP clock's capabilities to the GNU/Linux operating system. As
John Eidson pointed out~\cite{eidson2006measurement}, modern
operating systems provide surprisingly little support for
programming based on absolute time. As the IEEE 1588 standard is
being applied to a wide variety of test, measurement, and control
applications, we can imagine many possible ways to use an embedded
computer equipped with a PTP hardware clock. We do not expect that
any API will be able to cover every conceivable application of this
technology. However, the design presented here does cover common
use cases based on the capabilities of currently available hardware
clocks.
The design allows user space programs to control all of a clock's
ancillary features. Programs may create one-shot or periodic
alarms, with signal delivery on expiration. \Timestamps on
external events are provided via a First In, First Out (FIFO)
interface. If the clock has output signals, then their periods are
configurable from user space. Synchronization of the Linux system
time via the PPS subsystem may be enabled or disabled as desired.
\subsection{Synchronizing the Linux System Clock}
One important question that needed to be addressed was, now that we
have a precise time source, how do we synchronize the Linux kernel
to it? The Linux kernel offers a modular clock infrastructure
comprising ``clock sources'' and ``clock event devices.'' Clock
sources provide a monotonically increasing time base, and clock
event devices are used to schedule the next interrupt for various
timer events.
We considered but ultimately rejected the idea of offering the PTP
clock to the Linux kernel as a combined clock source and clock
event device. The one great advantage of this approach would have
been that it obviates the need for synchronization when the PTP
clock is selected as the system timer.
However, this approach is problematic when using certain kinds of
clock hardware. For example, physical layer (PHY) chip based clocks
can only be accessed by the relatively slow 16 bit wide MDIO
bus. Such a clock would not be suitable for providing high
resolution timers, which are now a standard Linux kernel feature.
Furthermore, we cannot even be sure that a given hardware clock
will offer any interrupt to the system at all.
Instead, we elected to use the Pulse Per Second (PPS) subsystem as
a method to optionally synchronize the Linux system time to the PTP
clock. This method is feasible even for clocks that do not offer
fast register access, such as the PHY clocks. Of course, the main
disadvantage of this approach is that the Linux system time will
not be exactly synchronized to the PTP clock time. Since PTP
clocks can be synchronized an order of magnitude better than the
typical operating system scheduling latency, we expect that this
method will still yield acceptable results for many applications.
Applications with more demanding time requirements may use the new
PTP interfaces directly when needed.
\subsection{System Calls or Character Device}
When adding new functionality to an operating system, a basic design
decision is how user space programs will call into the kernel. For
the Linux kernel, two different ways come into question, namely
system calls or as a ``character device.'' In an attempt to make
the PTP clock API easy to understand, we patterned it after the
existing Network Time Protocol (NTP) and the POSIX timer APIs, as
described in Section~\ref{UserAPI}. Both of these services are
exported to the user space as system calls. However, we decided to
offer the PTP clock as a character device because extending the NTP
and POSIX interfaces seemed impractical. In addition, the
character device's \fn{read()} method provides a
convenient way to deliver time stamped events to user space
programs.
^ permalink raw reply
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
From: Timur Tabi @ 2010-06-16 14:23 UTC (permalink / raw)
To: Micha Nelissen; +Cc: Aggrwal Poonam-B10812, linuxppc-dev
In-Reply-To: <4C189860.3040702@neli.hopto.org>
On Wed, Jun 16, 2010 at 4:24 AM, Micha Nelissen <micha@neli.hopto.org> wrote:
> IMHO:
> 1) Linux should not be dependent on U-boot or any other bootloader, or at
> least as possible
> 2) U-boot cannot (and does not want to) know whether Linux is going to use
> large physical addresses.
To quote The Dude: "Yeah, well, you know, that's just, like, your opinion, man."
I'm sorry, but Linux does depend on the boot loader, and U-Boot does
need to know whether Linux is going to use 36-bit addressing. That's
just the way it works. Linux patches that repeat what U-Boot already
does just so that you don't need to update your U-boot are going to be
rejected.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] powerpc/iseries: fix constant warning
From: Denis Kirjanov @ 2010-06-16 14:34 UTC (permalink / raw)
To: benh, sfr; +Cc: linuxppc-dev
Fix smatch warning: constant 0x8000000000000000 is so big it is unsigned long
Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
---
arch/powerpc/include/asm/abs_addr.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/abs_addr.h b/arch/powerpc/include/asm/abs_addr.h
index 98324c5..c3bffc3 100644
--- a/arch/powerpc/include/asm/abs_addr.h
+++ b/arch/powerpc/include/asm/abs_addr.h
@@ -69,7 +69,7 @@ static inline unsigned long phys_to_abs(unsigned long pa)
* Legacy iSeries Hypervisor calls
*/
#define iseries_hv_addr(virtaddr) \
- (0x8000000000000000 | virt_to_abs(virtaddr))
+ (0x8000000000000000UL | virt_to_abs(virtaddr))
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_ABS_ADDR_H */
^ permalink raw reply related
* Re: Request review of device tree documentation
From: Nicolas Pitre @ 2010-06-16 14:39 UTC (permalink / raw)
To: Mike Rapoport
Cc: microblaze-uclinux, devicetree-discuss, Jamie Lokier,
linuxppc-dev, Mitch Bradley, Dan Malek, Jeremy Kerr,
linux-arm-kernel, David Gibson
In-Reply-To: <4C18A9C7.5070800@compulab.co.il>
On Wed, 16 Jun 2010, Mike Rapoport wrote:
> Mitch Bradley wrote:
> > One counterargument, of course, is that "there is a better way". But it is
> > only "better" under a cost function that values things differently than the
> > vendors value them. Were that not so, the vendors would gladly use the
> > "better" way and not be tempted to use the objectionable feature. (Unless,
> > of course, the vendors are just ignorant or unskilled - but I generally find
> > that different cost functions cause more disconnects than lack of ability.)
>
> It's hardly arguable that Linux community and decision makers at chip vendor
> companies use different cost functions. But it's not that obvious that vendors
> cost functions based on well established _technical_ analysis.
> Many vendors try to use the same code base for several operating systems. From
> the high level perspective it sounds logical: use the same core functionality
> and thin adaptation layers to fit the core functionality into several OSes.
> But in reality, developing the OS abstraction layer and "thin" adaptation
> layers may become more expensive than developing each OS support from scratch.
> Besides, such code becomes a real mess after a while, and it's maintainability
> is very questionable.
The cost function _is_ different for the Linux community and decision
makers at chip vendor companies. I know that for having worked long
enough at a prominent chip vendor already.
Those vendors want to ship a product and be first on the market before
the competitors do. They grab a kernel tree, fit in their existing HAL
as quickly as they can, so that they are able to demo the new chip to
potential customers even before moving to full production. And if the
HAL fitting work has been done into last year's kernel already, then
they will simply reuse that kernel to minimize the effort further as in
theory only the HAL part needs to be swapped with the new one (doesn't
matter if last year's kernel was itself already based on a kernel from
the year before). Once the software appears to work, they send it to
customers and forget about it as they move to the next chip design. So
here, the cost is directly related to bring-up time, and quick (or big)
ugly software hacks are more than a convenience but rather a necessity
if you want to win the race.
People from the Linux community care about totally different things. The
most important factor here is _long term_ maintainability. It is
important that the code be clean, use a uniform coding style, and follow
common interfaces. This is so because the cost function here is
directly related to the difficulty for the Linux community to evolve the
kernel with generic improvements and new features. If each driver has a
different style, or rely on a different HAL, then it quickly becomes
extremely expensive to update those drivers along with the generic
improvements. And if the HAL is in binary form only, or stuck behind
some unalterable BIOS-like calls or firmware API, then it may even be
impossible to update those drivers as the execution context assumed by
the HAL firmware may not be guaranteed anymore (think about UP vs SMP,
different preemption modes, different realtime kernel modes, etc.) And
of course it is impossible to anticipate what execution context and
requirements the kernel might need in the future, hence this can't be
provisioned for (and much less validated) into the HAL design in advance
(and see above why it is next to hopeless to expect vendors to update
their HAL for old products in a timely fashion).
So there *is* indeed a big difference between both points of view. And
sometimes the imperatives from each group are in total conflict.
> > Which of course raises the question: How does the Linux community view such
> > SoC vendors? Are they embraced and eagerly supported, or (either openly or
> > secretly) viewed as a nuisance? How does the widespread objection to
> > something that such vendors "would make extensive use of" mesh with that
> > view?
>
> I cannot tell for the entire Linux community, but from what I know, such
> vendors are not much welcomed in the community.
And the reverse is also true: those vendors are not amenable to more
openness and early community involvement which could help them get to
market with "community acceptable" support for their products due to
NDAs and such, or simply because of the perception that the Linux
community is putting too much value on "expendable software". It is way
too common to hear from hardware designers that "software is cheap"...
which is not quite the case in the end. That's a real pity.
Nicolas
^ permalink raw reply
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
From: Micha Nelissen @ 2010-06-16 14:52 UTC (permalink / raw)
To: Timur Tabi, linuxppc-dev
In-Reply-To: <AANLkTikDywS1B5i2kCQfTvJAWBuq7K3UuOmGQzi45UAX@mail.gmail.com>
Timur Tabi wrote:
> I'm sorry, but Linux does depend on the boot loader, and U-Boot does
> need to know whether Linux is going to use 36-bit addressing.
Why?
> That's
> just the way it works.
What a great design philosophy!
> Linux patches that repeat what U-Boot already
> does just so that you don't need to update your U-boot are going to be
> rejected.
Who said anything about not wanting/needing to upgrade U-boot?
Micha
^ permalink raw reply
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
From: Kumar Gala @ 2010-06-16 15:01 UTC (permalink / raw)
To: Micha Nelissen; +Cc: linuxppc-dev
In-Reply-To: <4C187616.4000303@neli.hopto.org>
On Jun 16, 2010, at 1:58 AM, Micha Nelissen wrote:
> Hi,
>=20
> Attached is a patch to fix large physical address support for the =
e500v2 core. When >4GB addresses are used, the MAS7 register needs to be =
valid for tlbsx instruction usage.
>=20
> Please review and apply.
>=20
> Micha
> diff -u -ru linux-2.6.34/arch/powerpc/include/asm/reg.h =
linux-2.6.34-fix/arch/powerpc/include/asm/reg.h
> --- linux-2.6.34/arch/powerpc/include/asm/reg.h 2010-05-16 =
23:17:36.000000000 +0200
> +++ linux-2.6.34-fix/arch/powerpc/include/asm/reg.h 2010-06-16 =
08:43:28.000000000 +0200
> @@ -272,6 +272,7 @@
> #define HID0_DAPUEN (1<<8) /* Debug APU enable */
> #define HID0_SGE (1<<7) /* Store Gathering Enable */
> #define HID0_SIED (1<<7) /* Serial Instr. Execution =
[Disable] */
> +#define HID0_EN_MAS7_UPDATE (1<<7) /* tlbre/tlbsx update MAS7 - =
e500v2 */
> #define HID0_DCFA (1<<6) /* Data Cache Flush Assist */
> #define HID0_LRSTK (1<<4) /* Link register stack - 745x */
> #define HID0_BTIC (1<<5) /* Branch Target Instr Cache =
Enable */
> diff -u -ru linux-2.6.34/arch/powerpc/kernel/head_fsl_booke.S =
linux-2.6.34-fix/arch/powerpc/kernel/head_fsl_booke.S
> --- linux-2.6.34/arch/powerpc/kernel/head_fsl_booke.S 2010-05-16 =
23:17:36.000000000 +0200
> +++ linux-2.6.34-fix/arch/powerpc/kernel/head_fsl_booke.S =
2010-06-16 08:45:10.000000000 +0200
> @@ -328,6 +328,13 @@
> oris r2,r2,HID0_DOZE@h
> mtspr SPRN_HID0, r2
> #endif
> +#ifdef CONFIG_PTE_64BIT
> +BEGIN_MMU_FTR_SECTION
> + mfspr r2,SPRN_HID0
> + ori r2,r2,HID0_EN_MAS7_UPDATE@l
> + mtspr SPRN_HID0, r2
> +END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
> +#endif
If you want to do this, do it in:
arch/powerpc/kernel/cpu_setup_fsl_booke.S
- k=
^ permalink raw reply
* Re: [PATCH 12/12] ptp: Added a clock driver for the National Semiconductor PHYTER.
From: Grant Likely @ 2010-06-16 15:10 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, devicetree-discuss, linuxppc-dev, linux-arm-kernel,
Krzysztof Halasa
In-Reply-To: <20100616100539.GA3569@riccoc20.at.omicron.at>
On Wed, Jun 16, 2010 at 4:05 AM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Tue, Jun 15, 2010 at 12:49:13PM -0600, Grant Likely wrote:
>> Won't this break things for existing DP83640 users?
>
> Nope, the driver was only added five patches ago, and it only offers
> the timestamping stuff. The standard PHY functions just call the
> generic functions, so the PHY works fine even without this driver.
>
>> > +static struct ptp_clock *dp83640_clock;
>> > +DEFINE_SPINLOCK(clock_lock); /* protects the one and only dp83640_clo=
ck */
>>
>> Why only one? =A0Is it not possible to have 2 of these PHYs in a system?
>
> Yes, you can have multiple PHYs, but only one PTP clock.
>
> If you do use multiple PHYs, then you must wire their clocks together
> and adjust the PTP clock on only one of the PHYs.
>
>
> Thanks for your other comments,
You're welcome. Make sure to cc: linux-kernel on your next posting.
I commented on what I could, but there is a lot of code outside my
areas of expertise. In particular the time keeping code needs to be
looked at by the maintainers in that area.
Cheers,
g.
^ permalink raw reply
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
From: Micha Nelissen @ 2010-06-16 15:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <A79B65D2-CDAF-4B16-8E97-E3522F154056@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 445 bytes --]
Kumar Gala wrote:
>> +BEGIN_MMU_FTR_SECTION
>> + mfspr r2,SPRN_HID0
>> + ori r2,r2,HID0_EN_MAS7_UPDATE@l
>> + mtspr SPRN_HID0, r2
>> +END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
>> +#endif
>
> If you want to do this, do it in:
>
> arch/powerpc/kernel/cpu_setup_fsl_booke.S
Do you mean like attached? I had to change the order of the '_GLOBAL'
definitions __setup_cpu_e500v1/__setup_cpu_e500v2 since this bit is
e500v2 only.
Thanks,
Micha
[-- Attachment #2: en-mas7-update-v2.diff --]
[-- Type: text/plain, Size: 1326 bytes --]
Index: linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S
===================================================================
--- linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S (revision 2871)
+++ linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S (working copy)
@@ -57,8 +57,14 @@
ori r3,r3,HID0_DAPUEN@l
mtspr SPRN_HID0,r3
b __setup_e200_ivors
+_GLOBAL(__setup_cpu_e500v2)
+#ifdef CONFIG_PTE_64BIT
+ /* enable mas7 register for tlbre/tlbsx */
+ mfspr r2,SPRN_HID0
+ ori r2,r2,HID0_EN_MAS7_UPDATE@l
+ mtspr SPRN_HID0,r2
+#endif
_GLOBAL(__setup_cpu_e500v1)
-_GLOBAL(__setup_cpu_e500v2)
mflr r4
bl __e500_icache_setup
bl __e500_dcache_setup
Index: linux/arch/powerpc/include/asm/reg.h
===================================================================
--- linux/arch/powerpc/include/asm/reg.h (revision 2871)
+++ linux/arch/powerpc/include/asm/reg.h (working copy)
@@ -276,6 +276,7 @@
#define HID0_DAPUEN (1<<8) /* Debug APU enable */
#define HID0_SGE (1<<7) /* Store Gathering Enable */
#define HID0_SIED (1<<7) /* Serial Instr. Execution [Disable] */
+#define HID0_EN_MAS7_UPDATE (1<<7) /* Enable MAS7 reg for tlbre/tlbsx */
#define HID0_DCFA (1<<6) /* Data Cache Flush Assist */
#define HID0_LRSTK (1<<4) /* Link register stack - 745x */
#define HID0_BTIC (1<<5) /* Branch Target Instr Cache Enable */
^ permalink raw reply
* [PATCH] powerpc/iseries: fix possible null pointer dereference in iSeries_pcibios_fixup_resources
From: Denis Kirjanov @ 2010-06-16 15:16 UTC (permalink / raw)
To: benh, sfr; +Cc: linuxppc-dev, anton
I don't know if this is a right fix for the problem
since of_get_property can return NULL.
Since iseries_device_information is used only for informational purpose,
we can skip this function without valid HvSubBusNumber number.
Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
---
arch/powerpc/platforms/iseries/pci.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/pci.c b/arch/powerpc/platforms/iseries/pci.c
index 3fc2e64..ab3962b 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -445,7 +445,11 @@ void __init iSeries_pcibios_fixup_resources(struct pci_dev *pdev)
}
allocate_device_bars(pdev);
- iseries_device_information(pdev, bus, *sub_bus);
+ if (likely(sub_bus))
+ iseries_device_information(pdev, bus, *sub_bus);
+ else
+ printk(KERN_ERR "PCI: Device node %s has missing or invalid "
+ "linux,subbus property\n", node->full_name);
}
/*
^ permalink raw reply related
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
From: Micha Nelissen @ 2010-06-16 15:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <4C18E9EA.2090903@neli.hopto.org>
[-- Attachment #1: Type: text/plain, Size: 236 bytes --]
Micha Nelissen wrote:
> Do you mean like attached? I had to change the order of the '_GLOBAL'
> definitions __setup_cpu_e500v1/__setup_cpu_e500v2 since this bit is
> e500v2 only.
Hmm, maybe need to use r0 or r3 instead of r2?
Micha
[-- Attachment #2: en-mas7-update-v2.diff --]
[-- Type: text/plain, Size: 1326 bytes --]
Index: linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S
===================================================================
--- linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S (revision 2871)
+++ linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S (working copy)
@@ -57,8 +57,14 @@
ori r3,r3,HID0_DAPUEN@l
mtspr SPRN_HID0,r3
b __setup_e200_ivors
+_GLOBAL(__setup_cpu_e500v2)
+#ifdef CONFIG_PTE_64BIT
+ /* enable mas7 register for tlbre/tlbsx */
+ mfspr r0,SPRN_HID0
+ ori r0,r0,HID0_EN_MAS7_UPDATE@l
+ mtspr SPRN_HID0,r0
+#endif
_GLOBAL(__setup_cpu_e500v1)
-_GLOBAL(__setup_cpu_e500v2)
mflr r4
bl __e500_icache_setup
bl __e500_dcache_setup
Index: linux/arch/powerpc/include/asm/reg.h
===================================================================
--- linux/arch/powerpc/include/asm/reg.h (revision 2871)
+++ linux/arch/powerpc/include/asm/reg.h (working copy)
@@ -276,6 +276,7 @@
#define HID0_DAPUEN (1<<8) /* Debug APU enable */
#define HID0_SGE (1<<7) /* Store Gathering Enable */
#define HID0_SIED (1<<7) /* Serial Instr. Execution [Disable] */
+#define HID0_EN_MAS7_UPDATE (1<<7) /* Enable MAS7 reg for tlbre/tlbsx */
#define HID0_DCFA (1<<6) /* Data Cache Flush Assist */
#define HID0_LRSTK (1<<4) /* Link register stack - 745x */
#define HID0_BTIC (1<<5) /* Branch Target Instr Cache Enable */
^ permalink raw reply
* Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)
From: Timur Tabi @ 2010-06-16 15:42 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: linux-fbdev, wd, dzu, devicetree-discuss, linuxppc-dev, yorksun
In-Reply-To: <20100616093805.3a8df747@wker>
Anatolij Gustschin wrote:
> Any chance this could be done soon? I'd like to include the MPC5121e DIU
> support in 2.6.36 since it is currently broken in mainline and the patches
> provide the fix.
Ok, I'll try it today.
^ permalink raw reply
* Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)
From: Anatolij Gustschin @ 2010-06-16 15:47 UTC (permalink / raw)
To: Timur Tabi
Cc: linux-fbdev, wd, dzu, devicetree-discuss, linuxppc-dev, yorksun
In-Reply-To: <4C18F0E4.90309@freescale.com>
On Wed, 16 Jun 2010 10:42:28 -0500
Timur Tabi <timur@freescale.com> wrote:
> Anatolij Gustschin wrote:
>
> > Any chance this could be done soon? I'd like to include the
> > MPC5121e DIU support in 2.6.36 since it is currently broken in
> > mainline and the patches provide the fix.
>
> Ok, I'll try it today.
Thanks!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox