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 descri
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/
nderstand 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
mo
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/
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/
ling 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,
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
- Integrat
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
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 s
> -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 m
> -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
&g
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))
>>
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
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:
* Rebas
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/
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_GM
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
>&
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
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
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, s
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
>&
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
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
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.
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.
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
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
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
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
---
d
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
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
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_GM
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.
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 freque
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 t
35 matches
Mail list logo
