2.2.18 ide access warps time, stalls serial, slows MIDI, mouse
I've noticed a possible problem in Linux 2.2.18 relating to a CD-R drive connected to the secondary ide port. I'm not certain whether the problem cause is in the kernel software, in the hardware, or in a combination thereof. Although I've found a way to bypass the problem, I'm including a description here for anyone who wishes to better document the issue or create a more robust kernel. While the IDE CD-R drive works perfectly in and of itself, continuous access to the drive degrades the operation of other system tasks. Pointer movement with XFree86 4.0.1 or gpm becomes noticeably choppy, MIDI music playback under the ALSA drivers (0.5.10) progresses in slow motion, and network access through an external modem connected to a serial port all but ceases to function. Additional investigation also revealed that the system's notion of time slows down. For example, during continuous read access from the IDE CD-R drive, a 55 second piece of MIDI music is stretched out to nearly a minute and a half. While "time" consistently reports about 57 elapsed real seconds, manually timing the MIDI playback yielded the following repeatable results at various processor speeds: 500 MHz: 86 seconds 650 MHz: 85 seconds 750 MHz: 83 seconds Likewise, repeated application of "date" shows that system time progresses slower than real time. With no CD-R access, "time" reports about 55 elapsed real seconds for the 55 second MIDI playback test, and a stopwatch confirms this time. System time as reported by "date" also advances correctly. The problem appears whether using the CD-R drive for continuous reading (at ~3 MB per second) or writing (at ~600 KB per second). Trying "ide-cd" for read access instead of "ide-scsi" shows the same problem. The CD-R drive is wired as the master on the secondary IDE port, with an ATAPI Zip drive wired as the slave, with nothing connected to the primary IDE port. Access to the Zip drive (continuous read at ~700 KB per second) does not cause the problem, and removing the Zip drive from the system does not offer a remedy. All SCSI drives accessed through the Symbios 8751 SCSI adapter work fine with no side effects. The problem disappears when the wiring for the CD-R drive is switched from the secondary IDE port to the primary IDE port. The compiler version used to build the 2.2.18 kernel reads: gcc version 2.95.2 2220 (Debian GNU/Linux) Double checking by building the same kernel with gcc version 2.7.2.3 again demonstrates the same behavior. Mainboard/Processor: ABit KT7 / 650 MHz Athlon (model 4) "cat /usr/src/linux/.config | grep IDE | grep =": CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDESCSI=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_PARIDE_PARPORT=y CONFIG_VIDEO_DEV=m CONFIG_VIDEO_SELECT=y CONFIG_VIDEO_SELECT=y "cat /proc/scsi/scsi": Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: FUJITSU Model: MAB3045SCRev: 0108 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: FUJITSU Model: MAB3045SCRev: 0108 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 03 Lun: 00 Vendor: PLEXTOR Model: CD-ROM PX-20TS Rev: 1.00 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: IOMEGA Model: ZIP 100 Rev: 24.D Type: Direct-AccessANSI SCSI revision: Host: scsi1 Channel: 00 Id: 01 Lun: 00 Vendor: PLEXTOR Model: CD-R PX-W8432T Rev: 1.07 Type: CD-ROM ANSI SCSI revision: 02 Regards, - John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
a linux qos mailing list
Is there a linux qos mailing list? thanks, j.d. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
class handles
I've been working on automatic assignment of unique class handles inside of a system call. I came across the function qdisc_alloc_handle in net/sch_api.c, and I tried to use that. it didn't work, and I'm sure I'm missing something obvious. I don't think I clearly understand how handles are used in the kernel. could someone explain to me how they work? I've read the source code and the comments, but I'm still not clear on just how it all fits together. thanks. j.d. p.s. could you please cc me, as I'm not subscribed to linux-kernel at the moment. --- J.D. Hollis ([EMAIL PROTECTED]) "That which is overdesigned, too highly specific, anticipates outcome; the anticipation of outcome guarantees, if not failure, the absence of grace." - `All Tomorrow's Parties', William Gibson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
linux-2.4.0test10
hey. I'm having some strange memory problems with the 2.4 kernel. I first noticed in linux-2.4.0test9 (the first 2.4 kernel I installed and that I installed about a week before 2.4.0test10 came out) that a little while after I boot my system, my hard drive begins to seek rapidly for no apparent reason. after the drive stopped seeking, out of curiosity I pulled up gtop and noticed that a sizeable amount of my 256MB of physical memory had filled up with what gtop labelled 'Other.' upon closer examination, all of the processes running on my machine were only claiming about 85MB of RAM. this got my attention because my total RAM usage was sitting around 235MB of physical RAM. now, to be perfectly honest, I'm kinda curious about what's happening with that 150MB of RAM. of course my memory usage doesn't stay static, but it never goes much below 235MB out of 256MB, and often spikes, resorting to swap space. my box is a Gateway 900MHz Athlon with 256MB of RAM. I'm running Redhat 6.0 (roughly, although I've done various upgrades). if anyone needs something more specific (version numbers, detailed hardware specs), I'll be happy to dig it up for you. I'm not really sure what's wrong, so I don't know what system details to include. oh, and once I got gtop open while the hard drive was seeking and it showed kflushd was taking up 95% of processor, which I suppose means that it was responsible for the strange hard drive (and possibly memory) behavior. hope this is helpful. cheers, j.d. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0test10
a quick correction: I'm running Redhat 7.0 with some updates. sorry about that. j.d. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
major problem with linux-2.4.0test10
I've been having a problem with memory since 2.4.0test9...for some reason, shortly after my system boots, my hard drive begins to seek rapidly for no apparent reason, and suddenly about 150MB of my 256MB RAM is filled up with something gtop labels 'Other.' whatever's filling my memory isn't attached to any process. the one time I managed to get gtop open while the hard drive was seeking, I noticed that kflushd was using about 98% of my processor (an Athlon 900MHz). I'm running Redhat 7.0 (although I have no idea whether that makes a difference). regards, j.d. --- J.D. Hollis ([EMAIL PROTECTED]) "That which is overdesigned, too highly specific, anticipates outcome; the anticipation of outcome guarantees, if not failure, the absence of grace." - `All Tomorrow's Parties', William Gibson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Developing Linux-compatible Ethernet hardware
Hi all, I need a Fast Ethernet chip for an Open Hardware PCI board I'm working on. Of course said chip has to be available in small quantities (and not just attached to a NIC), and well supported by Linux. Other 'nice but not crucial' properties would be: - Gigabit Ethernet support - Integrated PHY - 66MHz PCI compliant - Multiple ports As it stands I'm thinking about using the Intel 82559ER (which lacks Gig Enet and 66MHz PCI), but I'm *very* open to other suggestions. Thanks, JD 'linux-hardware-dev@vger anyone ?' B. [oh, and the board will have 4-way SMP with G4 PowerPCs] -- LART. 250 MIPS under one Watt. Free hardware design files. http://www.lart.tudelft.nl/ - 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.html Please read the FAQ at http://www.tux.org/lkml/
Re: Maxwell strikes the heart (ECN: Clearing the air)
At 14:55 -0800 29-01-2001, Pete Zaitcev wrote: >So far I fail to see how a repainted NAK, kludged into a NAKless protocol, >would improve stability of the Internet. If anything, it is going to >exaggerate traffic oscillations. If anything RED will *reduce* oscillations by alleviating retransmit synchronization. > I would appreciate couple of links >to reputable studies or discussions on the subject. See http://www.aciri.org/floyd/ecn.html http://www.aciri.org/floyd/red.html (I particularly like ftp://ftp.ee.lbl.gov/talks/vj-nanog-red.pdf) RED and ECN can be considered independently (although they do work together quite well). You can see ECN as a way of the network telling the endpoints "Normally I would have dropped this datagram, but I'll let you get away with it this time". TCP behavior on reception of an ECN should be the same as when a datagram is dropped, but without the latency (and jitter) that is the result of a lost datagram. JDB. [using RED/ECN-like protocols for latency sensitive video communications over a wireless link] -- LART. 250 MIPS under one Watt. Free hardware design files. http://www.lart.tudelft.nl/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Threads FAQ entry incomplete
At 13:42 -0600 20-06-2001, Charles Cazabon wrote: >Rodrigo Ventura <[EMAIL PROTECTED]> wrote: > > BTW, I have a question: Can the availability of dual-CPU boards for intel >> and amd processors, rather then tri- or quadra-CPU boards, be explained with >> the fact that the performance degrades significantly for three or more CPUs? >> Or is there a technological and/or comercial reason behind? > >Commercial reasons. Cost per motherboard/chipset goes way up as the number of >CPUs supported goes up. For each CPU that a chipset supports, it has to add a >lot of pins/lands, and chipsets are already typically land-limited. That's not quite accurate. Most modern SMP-able processors have a common bus, where going from 1->2 CPUs adds just a handful of extra nets (usually bus request, bus grant and some IRQs). The actual issues are threefold. First, most commodity chipsets simply support no more than two CPUs at best; most CPUs don't support having more (or any) siblings. Adding more is cheap on the ASIC level, but nobody bothers because there is no demand. Second, adding more CPUs on a shared bus decreases the bus bandwidth that is available per CPU. This is comparable with having Ethernet hubs vs switches. The really expensive multi-CPU boards have crossbar switches between CPUs, memory and PCI. Future stuff like RapidIO may mitigate this. Third, the more CPUs a bus holds, the higher the capacitance on the bus lines. Higher capacitance means lower maximum bus speed, which aggravates point two. >Motherboard trace complexity (and therefore number of layers) goes up. Add to >that that the potential market goes down as CPUs goes up. True enough. Regards, JDB [working on a SMP PowerPC design] -- LART. 250 MIPS under one Watt. Free hardware design files. http://www.lart.tudelft.nl/ - 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.html Please read the FAQ at http://www.tux.org/lkml/
RE: [EXT] Re: [PATCH] tick/broadcast: Allow later probed device enter oneshot mode
> -Original Message-
> From: Thomas Gleixner
> Sent: Tuesday, March 30, 2021 5:18 AM
> To: J.d. Yue
> Cc: linux-kernel@vger.kernel.org; fweis...@gmail.com; mi...@kernel.org
> Subject: [EXT] Re: [PATCH] tick/broadcast: Allow later probed device enter
> oneshot mode
>
> Caution: EXT Email
>
> On Mon, Mar 29 2021 at 13:25, Jindong Yue wrote:
>
> > /*
> > * Debugging: see timer_list.c
> > @@ -115,8 +116,20 @@ void tick_install_broadcast_device(struct
> clock_event_device *dev)
> >* notification the systems stays stuck in periodic mode
> >* forever.
> >*/
> > - if (dev->features & CLOCK_EVT_FEAT_ONESHOT)
> > + if (dev->features & CLOCK_EVT_FEAT_ONESHOT) {
> > tick_clock_notify();
>
> If the kernel runs in oneshot mode already, then calling
> tick_clock_notify() does not make sense.
Yes, there should be more check before tick_clock_notify().
>
> > + /*
> > + * If new broadcast device is installed after high resolution
> > + * timers enabled, it can not switch to oneshot mode
> anymore.
>
> This is not restricted to high resolution timers. The point is that the mode
> is
> ONESHOT which might be either HIGHRES or NOHZ or both.
Got it, after kernel enters ONESHOT mode, new registered broadcast device can't
be switched to ONESHOT mode.
>
> > + */
> > + if (tick_broadcast_oneshot_active() &&
> > + dev->event_handler != tick_handle_oneshot_broadcast)
> > + {
>
> How would that condition ever be false for a newly installed device?
Okay, will remove this condition.
>
> > + tick_broadcast_switch_to_oneshot();
> > + }
>
> So what you really want is:
>
> if (!(dev->features & CLOCK_EVT_FEAT_ONESHOT))
> return;
>
> if (tick_broadcast_oneshot_active()) {
> tick_broadcast_switch_to_oneshot();
> return;
> }
>
> tick_clock_notify();
>
> Thanks,
>
> tglx
Thanks for your quick review and advice. I will test this code locally and send
V2 patch later.
Jindong
RE: [EXT] Re: [PATCH v2] tick/broadcast: Allow later registered device enter oneshot mode
> -Original Message-
> From: Thomas Gleixner
> Sent: Wednesday, March 31, 2021 4:07 PM
> To: J.d. Yue ; fweis...@gmail.com; mi...@kernel.org
> Cc: linux-kernel@vger.kernel.org; J.d. Yue
> Subject: [EXT] Re: [PATCH v2] tick/broadcast: Allow later registered device
> enter oneshot mode
>
> Caution: EXT Email
>
> On Wed, Mar 31 2021 at 09:10, Jindong Yue wrote:
> > --- a/kernel/time/tick-broadcast.c
> > +++ b/kernel/time/tick-broadcast.c
> > @@ -47,6 +47,7 @@ static inline void
> > tick_resume_broadcast_oneshot(struct clock_event_device *bc) static
> > inline void tick_broadcast_oneshot_offline(unsigned int cpu) { } #
> > endif #endif
> > +static void tick_handle_oneshot_broadcast(struct clock_event_device
> > +*dev);
>
> Leftover ...
Removed in v3.
>
> > /*
> > * Debugging: see timer_list.c
> > @@ -107,6 +108,19 @@ void tick_install_broadcast_device(struct
> clock_event_device *dev)
> > tick_broadcast_device.evtdev = dev;
> > if (!cpumask_empty(tick_broadcast_mask))
> > tick_broadcast_start_periodic(dev);
> > +
> > + if (!(dev->features & CLOCK_EVT_FEAT_ONESHOT))
> > + return;
> > +
> > + /*
> > + * If system already runs in oneshot mode, switch new registered
>
> the system the newly registered
>
> > + * broadcast device to oneshot mode explicitly if possiable.
>
> s/possible/possiable/
>
> But the 'if possible' makes no sense here. The above check for
> CLOCK_EVT_FEAT_ONESHOT established that it _is_ possible. So just remove
> the 'if ...'.
I should be more careful ...
Please check v3 patch.
Thanks
Jindong
>
> > + */
> > + if (tick_broadcast_oneshot_active()) {
> > + tick_broadcast_switch_to_oneshot();
> > + return;
> > + }
>
> Thanks,
>
> tglx
Re: [PATCH] net: davinci_mdio: Set of_node in the mdio bus
On 04/28/2016 02:44 PM, David Miller wrote:
>> --- a/drivers/net/ethernet/ti/davinci_mdio.c
>> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
>> @@ -343,6 +343,7 @@ static int davinci_mdio_probe(struct platform_device
>> *pdev)
>> if (davinci_mdio_probe_dt(&data->pdata, pdev))
>> data->pdata = default_pdata;
>> snprintf(data->bus->id, MII_BUS_ID_SIZE, "%s", pdev->name);
>> +data->bus->dev.of_node = dev->of_node;
>> } else {
>> data->pdata = pdata ? (*pdata) : default_pdata;
>> snprintf(data->bus->id, MII_BUS_ID_SIZE, "%s-%x",
>
> You can't do this.
>
> First of all, of_node objects are reference counted. So even if this was a
> legal thing to do you would have to drop the reference to the existing of_node
> pointer and gain a reference to dev->of_node.
>
> But even more importantly, it is the job of the bus driver to set that
> bus->dev.of_node correctly, you should never override it in a driver like
> this.
David, thanks for your review. I understand your point about the reference
count.
One thing to note is that it is always null for the davinci mdio bus when
going through this path. I'm not trying to override it. I'm trying to make
sure it has a way to find the davinci mdio bus. Do you see the problem I'm
trying to solve?
Is there another way to be able to make the of_mdio_find_bus() call be able to
find the davinci mdio bus?
Thanks,
JD
[PATCH v2 2/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency
From: "J.D. Schroeder"
This commit updates the OSC_32K_CLK (secure_32k_clk_src_ck) frequency
from the precise 32kHz frequency (i.e., 32.768 kHz) to a more
accurate frequency of ~34.6 kHz. Actual measured frequencies of the
clock vary from processor to processor anywhere from 34.4 kHz up to
34.8 kHz. Note that the ~34 kHz frequency clock is generated
internally by the processor, not an input to the processor. This
change makes it more clear that the consumer of the
secure_32k_clk_src_ck will not get a precise 32.768 kHz frequency
output.
Signed-off-by: J.D. Schroeder
Reviewed-by: Trenton Andres
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 3f0c61d..f7ec976 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -95,7 +95,7 @@
secure_32k_clk_src_ck: secure_32k_clk_src_ck {
#clock-cells = <0>;
compatible = "fixed-clock";
- clock-frequency = <32768>;
+ clock-frequency = <34600>; /* approximate frequency */
};
sys_clk32_crystal_ck: sys_clk32_crystal_ck {
--
1.9.1
[PATCH v2 0/3] AM57/DRA7 Clock Tree DTSI Fix-ups
This series of patches fixes several discrepancies between the AM57/DRA7 clock tree description and the actual hardware behavior and frequencies. With these changes a more complete picture of the clock tree is represented for a few of the clocks and their resulting frequencies. v2 Changes: * Rebased on linux-next as requested by Tony Lindgren * Eliminated previous patch 2 as another change fixing the same thing was merged in eea08802f586acd6aef377d1b4a541821013cc0b * Added to the commit message in patch 2 to clarify the source of the clock being internal to the processor * Added a new patch 3 to fix a new warning introduced by eea08802f586acd6aef377d1b4a541821013cc0b
[PATCH v2 3/3] ARM: dts: dra7: fix clock node definition to avoid build warning
From: "J.D. Schroeder"
This patch fixes the following warning for the DRA7 clock node:
Warning (unit_address_vs_reg): Node
/ocp/l4@4a00/scm@2000/scm_conf@0/clocks/sys_32k_ck
has a reg or ranges property, but no unit name
Signed-off-by: J.D. Schroeder
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index f7ec976..34cda4b 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -2186,7 +2186,7 @@
reg = <0x0558>;
};
- sys_32k_ck: sys_32k_ck {
+ sys_32k_ck: sys_32k_ck@6c4 {
#clock-cells = <0>;
compatible = "ti,mux-clock";
clocks = <&sys_clk32_crystal_ck>, <&sys_clk32_pseudo_ck>,
<&sys_clk32_pseudo_ck>, <&sys_clk32_pseudo_ck>;
--
1.9.1
[PATCH v2 1/3] DRA7: Fix clock data for gmac_gmii_ref_clk_div
From: "J.D. Schroeder"
This commit fixes the clock data inside the DRA7xx clocks device tree
structure for the gmac_gmii_ref_clk_div clock. This clock is actually
the GMAC_MAIN_CLK and has nothing to do with the register at address
0x4a0093d0. If CLKSEL_REF bit 24 inside of CM_GMAC_GMAC_CLKCTRL, is
set to 1 in order to use the GMAC_RMII_CLK instead of the
GMAC_RMII_HS_CLK, the kernel generates a clock divider warning:
WARNING: CPU: 0 PID: 0 at drivers/clk/clk-divider.c:129
clk_divider_recalc_rate+0xa8/0xe0()
gmac_gmii_ref_clk_div: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set
By properly configuring the gmac_gmii_ref_clk_div (GMAC_MAIN_CLK) to
have the parent of dpll_gmac_m2_ck always divided by 2 the warning is
resolved and the clock tree is fixed up.
Additionally, a new clock called rmii_50mhz_clk_mux is defined that
does utilize CM_GMAC_GMAC_CLKCTRL[24] CLKSEL_REF to configure the
source clock for the RMII_50MHZ_CLK.
Signed-off-by: J.D. Schroeder
Reviewed-by: Trenton Andres
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 8378b44..3f0c61d 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1718,13 +1718,20 @@
reg = <0x0c00>;
};
- gmac_gmii_ref_clk_div: gmac_gmii_ref_clk_div@13d0 {
+ rmii_50mhz_clk_mux: rmii_50mhz_clk_mux@13d0 {
#clock-cells = <0>;
- compatible = "ti,divider-clock";
- clocks = <&dpll_gmac_m2_ck>;
+ compatible = "ti,mux-clock";
+ clocks = <&dpll_gmac_h11x2_ck>, <&rmii_clk_ck>;
ti,bit-shift = <24>;
reg = <0x13d0>;
- ti,dividers = <2>;
+ };
+
+ gmac_gmii_ref_clk_div: gmac_gmii_ref_clk_div {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <&dpll_gmac_m2_ck>;
+ clock-mult = <1>;
+ clock-div = <2>;
};
gmac_rft_clk_mux: gmac_rft_clk_mux@13d0 {
--
1.9.1
Re: [PATCH v2 2/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency
On 05/03/2016 03:16 AM, Tero Kristo wrote:
> On 02/05/16 20:12, J.D. Schroeder wrote:
>> From: "J.D. Schroeder"
>>
>> This commit updates the OSC_32K_CLK (secure_32k_clk_src_ck) frequency
>> from the precise 32kHz frequency (i.e., 32.768 kHz) to a more
>> accurate frequency of ~34.6 kHz. Actual measured frequencies of the
>> clock vary from processor to processor anywhere from 34.4 kHz up to
>> 34.8 kHz. Note that the ~34 kHz frequency clock is generated
>> internally by the processor, not an input to the processor. This
>> change makes it more clear that the consumer of the
>> secure_32k_clk_src_ck will not get a precise 32.768 kHz frequency
>> output.
>>
>> Signed-off-by: J.D. Schroeder
>> Reviewed-by: Trenton Andres
>> ---
>> arch/arm/boot/dts/dra7xx-clocks.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
>> b/arch/arm/boot/dts/dra7xx-clocks.dtsi
>> index 3f0c61d..f7ec976 100644
>> --- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
>> +++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
>> @@ -95,7 +95,7 @@
>> secure_32k_clk_src_ck: secure_32k_clk_src_ck {
>> #clock-cells = <0>;
>> compatible = "fixed-clock";
>> -clock-frequency = <32768>;
>> +clock-frequency = <34600>; /* approximate frequency */
>> };
>>
>> sys_clk32_crystal_ck: sys_clk32_crystal_ck {
>>
>
> I still don't agree with this patch. The actual frequency can drift much more,
> you are just seeing this number at your setup.
Yes, it can drift significantly from processor to processor. Do you agree that
this frequency is closer to what can be expected than 32768 Hz?
Like I said, I would have renamed the clock also but I opted to go the less
obtrusive route while still helping others that might think they can
reasonably use this clock in their design as a 32768 Hz clock source. Perhaps
my comment and selection of the approximate frequency is not the best (I'm
open for suggestions). However, I do think this change is an improvement and
clarifying change to what is currently present in the clock description.
-JD
Re: [PATCH v2 2/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency
On 05/03/2016 12:32 PM, Tero Kristo wrote: > Personally I would not recommend using this clock for any timing sensitive > applications. May I ask why you are interested in the exact clock rate of this > clock anyway? I'm not interested in using this clock and I'm not sure how anyone would use this clock outside of the processor. See the inline comment that is part of the change and the commit message for the change. There is no hint in my change that this is an exact clock rate. It is a clarifying change to help others avoid using this clock as a 32 kHz clock (which the current clock name and frequency imply) and it more accurately represents the actual hardware behavior.
Re: [PATCH 0/3] AM57/DRA7 Clock Tree DTSI Fix-ups
On 04/26/2016 01:13 PM, Tony Lindgren wrote: > Are any of these needed for the v4.6-rc cycle? I understand that these are arriving a little late especially if we don't get to rc7. However, it would be great if these could get in the v4.6 kernel release. They shouldn't be too risky to anyone, but I understand if the logistics prevent that from happening. Thanks, JD
Re: [PATCH 2/3] ARM: DRA7x: dts: Fix the 32kHz clock calculation
On 04/27/2016 06:40 AM, Tero Kristo wrote: > On 26/04/16 20:54, J.D. Schroeder wrote: >> This commit fixes the 32kHz clock (sys_32k_ck) calculation to be >> correctly based on the SYS_CLK1 (sys_clkin1) frequency. Based on the >> TRM CTRL_CORE_BOOTSTRAP[9:8] SPEEDSELECT, set by the SYSBOOT[9:8] >> board jumpers according to the SYS_CLK1 frequency, the frequency of >> the 32kHz FUNC_32K_CLK is set to SYS_CLK1/610. The following >> sys_32k_ck frequencies get used for different SYS_CLK1 frequencies: >> 0b00: Unknown -> 32768 Hz crystal from CLKIN_32K pin >> 0b01: 20 MHz -> 32787 Hz clock (SYS_CLK1/610) >> 0b10: 27 MHz -> 44262 Hz clock (SYS_CLK1/610) >> 0b11: 19.2 MHz -> 31475 Hz clock (SYS_CLK1/610) > > A patch doing the same thing is already in mainline, see: > > commit eea08802f586acd6aef377d1b4a541821013cc0b > Author: Keerthy > Date: Mon Apr 4 11:07:15 2016 +0530 > > ARM: dts: dra7: Correct clock tree for sys_32k_ck > > So, this one can be ignored. My change had no issue when applying to the tip of master and I'm not seeing that SHA1 in mainline. Are you saying it is in another repo ready to be sent to mainline for the next release cycle?
Re: [PATCH 3/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency
On 04/27/2016 06:49 AM, Tero Kristo wrote: > On 26/04/16 20:54, J.D. Schroeder wrote: >> From: "J.D. Schroeder" >> >> This commit updates the OSC_32K_CLK (secure_32k_clk_src_ck) frequency >> from the precise 32kHz frequency (i.e., 32.768 kHz) to the more >> accurate frequency of ~34.6 kHz. Actual measured frequencies of the >> clock vary from board to board anywhere from 34.4 kHz up to 34.8 kHz. > > Uhm, if you have a board specific, accurate value for this clock, you should > update it in the board file itself. This definition is going to be used across > all the DRA7 / AM57xx boards, which can very likely have different crystal > accuracies. > > So, NAK. The source of this clock is internal to the processor and not specific to how the processor is configured or what clocks are coming in. The approximate frequency of 34.4-34.8 kHz is generated internal to the processor through some type of oscillator, not external. The problem is that the clock tree gives the impression that this is a 32.768 kHz clock source, when in fact it is *not* that. Both the name and the frequency are misleading. My change is an attempt to clarify the actual behavior of the clock and keep someone else from using the clock as a true 32.768 kHz clock when it is more than 5% off that particular frequency. I would even consider changing the name of the clock as that too is misleading, but opted not to since that would be more disruptive. If you are seeing 32.768 kHz come out of this clock source then I must have an issue with my silicon and we can discuss off line. However, if you configure this as one of the clock out sources and see something in the range of ~34 kHz, I still think the change is a valid change as it clarifies the true behavior of the hardware. Am I missing something?
Re: [PATCH 2/3] ARM: DRA7x: dts: Fix the 32kHz clock calculation
On 04/27/2016 02:47 PM, Tero Kristo wrote: > The patch is merged already in 4.6-rc3. > > Which repo / version are you using as baseline? I'm using git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git. I can see eea08802f586acd6aef377d1b4a541821013cc0b as of now. However, I don't think it was included in -rc3 or even -rc5 which is what I was basing my changes on. It looks like it got merged in late last night in Linus tree. No big deal. The change is nearly identical to my solution so no need to pursue mine. Please disregard this patch. Thanks, JD
[PATCH] OMAPDSS: HDMI5: Change DDC timings
From: "Lodes, Jim"
The DDC scl high and low times were set to the minimum values
from the i2c specification, but the i2c specification takes into
account the rise time and fall time to calculate the frequency.
To pass HDMI certification DDC can not exceed 100kHz therefore in
a system where the rise times and fall times are negligible the high
and low times for scl need to be 10us.
Signed-off-by: Lodes, Jim
Signed-off-by: J.D. Schroeder
---
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 4 ++--
drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
index 6a39752..d993f78 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
@@ -51,8 +51,8 @@ static void hdmi_core_ddc_init(struct hdmi_core_data *core)
{
void __iomem *base = core->base;
const unsigned long long iclk = 26600; /* DSS L3 ICLK */
- const unsigned ss_scl_high = 4000; /* ns */
- const unsigned ss_scl_low = 4700; /* ns */
+ const unsigned ss_scl_high = 4600; /* ns */
+ const unsigned ss_scl_low = 5400; /* ns */
const unsigned fs_scl_high = 600; /* ns */
const unsigned fs_scl_low = 1300; /* ns */
const unsigned sda_hold = 1000; /* ns */
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
index 8ea531d..f3e4b81 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
@@ -51,8 +51,8 @@ static void hdmi_core_ddc_init(struct hdmi_core_data *core)
{
void __iomem *base = core->base;
const unsigned long long iclk = 26600; /* DSS L3 ICLK */
- const unsigned ss_scl_high = 4000; /* ns */
- const unsigned ss_scl_low = 4700; /* ns */
+ const unsigned ss_scl_high = 4600; /* ns */
+ const unsigned ss_scl_low = 5400; /* ns */
const unsigned fs_scl_high = 600; /* ns */
const unsigned fs_scl_low = 1300; /* ns */
const unsigned sda_hold = 1000; /* ns */
--
1.9.1
[PATCH] OMAPDSS: HDMI5: Fix AVI infoframe
From: "Lodes, Jim" The AVI infoframe R0-R3 in the 2nd data byte represents the Active Format Aspect Ratio. It is four bits long not two bits. This fixes that mask used to extract the bits before writing the bits to the hardware registers. Signed-off-by: Lodes, Jim Signed-off-by: J.D. Schroeder --- drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 2 +- drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c index d993f78..8ab2093 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c @@ -458,7 +458,7 @@ static void hdmi_core_write_avi_infoframe(struct hdmi_core_data *core, c = (ptr[1] >> 6) & 0x3; m = (ptr[1] >> 4) & 0x3; - r = (ptr[1] >> 0) & 0x3; + r = (ptr[1] >> 0) & 0xf; itc = (ptr[2] >> 7) & 0x1; ec = (ptr[2] >> 4) & 0x7; diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c index f3e4b81..bbfe7e2 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c @@ -442,7 +442,7 @@ static void hdmi_core_write_avi_infoframe(struct hdmi_core_data *core, c = (ptr[1] >> 6) & 0x3; m = (ptr[1] >> 4) & 0x3; - r = (ptr[1] >> 0) & 0x3; + r = (ptr[1] >> 0) & 0xf; itc = (ptr[2] >> 7) & 0x1; ec = (ptr[2] >> 4) & 0x7; -- 1.9.1
Re: [PATCH] OMAPDSS: HDMI5: Fix AVI infoframe
On 04/21/2016 09:43 AM, Tomi Valkeinen wrote: >> Signed-off-by: Lodes, Jim > > Thanks, looks good. Can you fix the email here too, and resend? Yes, I'll fix the sign off and make sure we have it correct going forward.
Re: [PATCH] OMAPDSS: HDMI5: Change DDC timings
On 04/21/2016 09:38 AM, Tomi Valkeinen wrote: > Thanks, makes sense. Did you measure the rise & fall times? Do you get > more or less exactly 100kHz with the new times? Rise time is around 600 nsec and fall time is around 140 nsec. When the clock frequency is measured we get right at 100 kHz and the rise and fall times are negligible. When the HDMI certification test equipment is attached it is just slightly less than 100 kHz, which is okay. The HDMI specification states less than 100 kHz is acceptable not greater. If a particular system has slower rise and fall times then that should be okay also. This change ensures that we stay below 100 kHz regardless of the rise and fall times. >> Signed-off-by: Lodes, Jim > > The email format should be > > Firstname Lastname Yes. I'll fix the email and resubmit.
[PATCH v2] OMAPDSS: HDMI5: Change DDC timings
From: Jim Lodes
The DDC scl high and low times were set to the minimum values
from the i2c specification, but the i2c specification takes into
account the rise time and fall time to calculate the frequency.
To pass HDMI certification DDC can not exceed 100kHz therefore in
a system where the rise times and fall times are negligible the high
and low times for scl need to be 10us.
Signed-off-by: Jim Lodes
Signed-off-by: J.D. Schroeder
---
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 4 ++--
drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
index 6a39752..d993f78 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
@@ -51,8 +51,8 @@ static void hdmi_core_ddc_init(struct hdmi_core_data *core)
{
void __iomem *base = core->base;
const unsigned long long iclk = 26600; /* DSS L3 ICLK */
- const unsigned ss_scl_high = 4000; /* ns */
- const unsigned ss_scl_low = 4700; /* ns */
+ const unsigned ss_scl_high = 4600; /* ns */
+ const unsigned ss_scl_low = 5400; /* ns */
const unsigned fs_scl_high = 600; /* ns */
const unsigned fs_scl_low = 1300; /* ns */
const unsigned sda_hold = 1000; /* ns */
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
index 8ea531d..f3e4b81 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
@@ -51,8 +51,8 @@ static void hdmi_core_ddc_init(struct hdmi_core_data *core)
{
void __iomem *base = core->base;
const unsigned long long iclk = 26600; /* DSS L3 ICLK */
- const unsigned ss_scl_high = 4000; /* ns */
- const unsigned ss_scl_low = 4700; /* ns */
+ const unsigned ss_scl_high = 4600; /* ns */
+ const unsigned ss_scl_low = 5400; /* ns */
const unsigned fs_scl_high = 600; /* ns */
const unsigned fs_scl_low = 1300; /* ns */
const unsigned sda_hold = 1000; /* ns */
--
1.9.1
[PATCH v2] OMAPDSS: HDMI5: Fix AVI infoframe
From: Jim Lodes The AVI infoframe R0-R3 in the 2nd data byte represents the Active Format Aspect Ratio. It is four bits long not two bits. This fixes that mask used to extract the bits before writing the bits to the hardware registers. Signed-off-by: Jim Lodes Signed-off-by: J.D. Schroeder --- drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 2 +- drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c index d993f78..8ab2093 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c @@ -458,7 +458,7 @@ static void hdmi_core_write_avi_infoframe(struct hdmi_core_data *core, c = (ptr[1] >> 6) & 0x3; m = (ptr[1] >> 4) & 0x3; - r = (ptr[1] >> 0) & 0x3; + r = (ptr[1] >> 0) & 0xf; itc = (ptr[2] >> 7) & 0x1; ec = (ptr[2] >> 4) & 0x7; diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c index f3e4b81..bbfe7e2 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c @@ -442,7 +442,7 @@ static void hdmi_core_write_avi_infoframe(struct hdmi_core_data *core, c = (ptr[1] >> 6) & 0x3; m = (ptr[1] >> 4) & 0x3; - r = (ptr[1] >> 0) & 0x3; + r = (ptr[1] >> 0) & 0xf; itc = (ptr[2] >> 7) & 0x1; ec = (ptr[2] >> 4) & 0x7; -- 1.9.1
[PATCH] net: davinci_mdio: Set of_node in the mdio bus
From: "J.D. Schroeder"
Assigns the of_node from the platform device to the of_node of the
mdio bus so that it can be used in the mdio driver to properly match
a bus in the DT with a phandle in of_mdio_find_bus().
Signed-off-by: J.D. Schroeder
Signed-off-by: Ben McCauley
---
drivers/net/ethernet/ti/davinci_mdio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c
b/drivers/net/ethernet/ti/davinci_mdio.c
index 4e7c9b9..b5e5f37 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -343,6 +343,7 @@ static int davinci_mdio_probe(struct platform_device *pdev)
if (davinci_mdio_probe_dt(&data->pdata, pdev))
data->pdata = default_pdata;
snprintf(data->bus->id, MII_BUS_ID_SIZE, "%s", pdev->name);
+ data->bus->dev.of_node = dev->of_node;
} else {
data->pdata = pdata ? (*pdata) : default_pdata;
snprintf(data->bus->id, MII_BUS_ID_SIZE, "%s-%x",
--
1.9.1
[PATCH] ASoC: davinci-mcasp: Fix overwriting of ahclkx
From: Jim Lodes The mcasp davinci_mcasp_set_dai_fmt function was overriding ahclkx input/output status that had already been set by the davinci_mcasp_set_sysclk function. This commit removes clearing of the ahclkx input/output status from davinci_mcasp_set_dai_fmt. Signed-off-by: Jim Lodes Signed-off-by: J.D. Schroeder --- sound/soc/davinci/davinci-mcasp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index e132498..a1197ad 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -489,7 +489,7 @@ static int davinci_mcasp_set_dai_fmt(struct snd_soc_dai *cpu_dai, mcasp_clr_bits(mcasp, DAVINCI_MCASP_RXFMCTL_REG, AFSRE); mcasp_clr_bits(mcasp, DAVINCI_MCASP_PDIR_REG, - ACLKX | AHCLKX | AFSX | ACLKR | AHCLKR | AFSR); + ACLKX | AFSX | ACLKR | AHCLKR | AFSR); mcasp->bclk_master = 0; break; default: -- 1.9.1
[PATCH] ASoC: omap-pcm: Initialize DMA configuration
From: Jim Lodes Initialize the dma_slave_config for PCM DMA transfers, instead of leaving it uninitialized. Keeps previous data on the stack from giving us invalid values in uninitialized members of the config structure. Signed-off-by: Jim Lodes Signed-off-by: J.D. Schroeder --- sound/soc/omap/omap-pcm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index 99381a2..a84f677 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -82,6 +82,8 @@ static int omap_pcm_hw_params(struct snd_pcm_substream *substream, struct dma_chan *chan; int err = 0; + memset(&config, 0x00, sizeof(config)); + dma_data = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream); /* return if this is a bufferless transfer e.g. -- 1.9.1
[PATCH 1/3] DRA7: Fix clock data for gmac_gmii_ref_clk_div
From: "J.D. Schroeder"
This commit fixes the clock data inside the DRA7xx clocks device tree
structure for the gmac_gmii_ref_clk_div clock. This clock is actually
the GMAC_MAIN_CLK and has nothing to do with the register at address
0x4a0093d0. If CLKSEL_REF bit 24 inside of CM_GMAC_GMAC_CLKCTRL, is
set to 1 in order to use the GMAC_RMII_CLK instead of the
GMAC_RMII_HS_CLK, the kernel generates a clock divider warning:
WARNING: CPU: 0 PID: 0 at drivers/clk/clk-divider.c:129
clk_divider_recalc_rate+0xa8/0xe0()
gmac_gmii_ref_clk_div: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set
By properly configuring the gmac_gmii_ref_clk_div (GMAC_MAIN_CLK) to
have the parent of dpll_gmac_m2_ck always divided by 2 the warning is
resolved and the clock tree is fixed up.
Additionally, a new clock called rmii_50mhz_clk_mux is defined that
does utilize CM_GMAC_GMAC_CLKCTRL[24] CLKSEL_REF to configure the
source clock for the RMII_50MHZ_CLK.
Signed-off-by: J.D. Schroeder
Reviewed-by: Trenton Andres
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index d0bae06..9d1a583 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1710,13 +1710,20 @@
reg = <0x0c00>;
};
- gmac_gmii_ref_clk_div: gmac_gmii_ref_clk_div {
+ rmii_50mhz_clk_mux: rmii_50mhz_clk_mux {
#clock-cells = <0>;
- compatible = "ti,divider-clock";
- clocks = <&dpll_gmac_m2_ck>;
+ compatible = "ti,mux-clock";
+ clocks = <&dpll_gmac_h11x2_ck>, <&rmii_clk_ck>;
ti,bit-shift = <24>;
reg = <0x13d0>;
- ti,dividers = <2>;
+ };
+
+ gmac_gmii_ref_clk_div: gmac_gmii_ref_clk_div {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <&dpll_gmac_m2_ck>;
+ clock-mult = <1>;
+ clock-div = <2>;
};
gmac_rft_clk_mux: gmac_rft_clk_mux {
--
1.9.1
[PATCH 0/3] AM57/DRA7 Clock Tree DTSI Fix-ups
This series of patches fixes several discrepancies between the AM57/DRA7 clock tree description and the actual hardware behavior and frequencies. With these changes a more complete picture of the clock tree is represented for a few of the clocks and their resulting frequencies.
[PATCH 2/3] ARM: DRA7x: dts: Fix the 32kHz clock calculation
From: "J.D. Schroeder"
This commit fixes the 32kHz clock (sys_32k_ck) calculation to be
correctly based on the SYS_CLK1 (sys_clkin1) frequency. Based on the
TRM CTRL_CORE_BOOTSTRAP[9:8] SPEEDSELECT, set by the SYSBOOT[9:8]
board jumpers according to the SYS_CLK1 frequency, the frequency of
the 32kHz FUNC_32K_CLK is set to SYS_CLK1/610. The following
sys_32k_ck frequencies get used for different SYS_CLK1 frequencies:
0b00: Unknown -> 32768 Hz crystal from CLKIN_32K pin
0b01: 20 MHz -> 32787 Hz clock (SYS_CLK1/610)
0b10: 27 MHz -> 44262 Hz clock (SYS_CLK1/610)
0b11: 19.2 MHz -> 31475 Hz clock (SYS_CLK1/610)
Signed-off-by: J.D. Schroeder
Reviewed-by: Ben McCauley
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 9d1a583..a514fc3 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -98,12 +98,6 @@
clock-frequency = <32768>;
};
- sys_32k_ck: sys_32k_ck {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <32768>;
- };
-
virt_1200_ck: virt_1200_ck {
#clock-cells = <0>;
compatible = "fixed-clock";
@@ -2177,4 +2171,26 @@
ti,bit-shift = <22>;
reg = <0x0558>;
};
+
+ sys_32kin: sys_32kin {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ };
+
+ sys_clkin1_32k_div: sys_clkin1_32k_div {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <&sys_clkin1>;
+ clock-mult = <1>;
+ clock-div = <610>;
+ };
+
+ sys_32k_ck: sys_32k_ck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&sys_32kin>, <&sys_clkin1_32k_div>,
<&sys_clkin1_32k_div>, <&sys_clkin1_32k_div>;
+ ti,bit-shift = <8>;
+ reg = <0x06c4>;
+ };
};
--
1.9.1
[PATCH 3/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency
From: "J.D. Schroeder"
This commit updates the OSC_32K_CLK (secure_32k_clk_src_ck) frequency
from the precise 32kHz frequency (i.e., 32.768 kHz) to the more
accurate frequency of ~34.6 kHz. Actual measured frequencies of the
clock vary from board to board anywhere from 34.4 kHz up to 34.8 kHz.
Signed-off-by: J.D. Schroeder
Reviewed-by: Trenton Andres
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index a514fc3..4501140 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -95,7 +95,7 @@
secure_32k_clk_src_ck: secure_32k_clk_src_ck {
#clock-cells = <0>;
compatible = "fixed-clock";
- clock-frequency = <32768>;
+ clock-frequency = <34600>; /* approximate frequency */
};
virt_1200_ck: virt_1200_ck {
--
1.9.1
