Re: who maintains linux 4 the powerpc
Cort Dougan <[EMAIL PROTECTED]> wrote: > } Can somebody please tell me, who is currently maintaining > } arch/ppc? > } > } The link > } > } http://www.ppc.kernel.org/ > } > } in the MAINTAINERS file is dead. > } > } Regards, Till > It's unmaintained right now. The www.ppc.kernel.org site is gone. > Take a look at www.fsmlabs.com/linuxppcbk.html for the PPC tree. i think http://linuxppc.org/ is the central resource for linux on the ppc with pointers to various kernel trees (benh, paulus, fmlabs) t -- [EMAIL PROTECTED] technical director innominate AG clustering & securitynetworking people tel: +49.30.308806-13 fax: -77 http://innominate.de - 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: [ANNOUNCE] Darkstar Development Project
Larry McVoy <[EMAIL PROTECTED]> wrote: > On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote: >> > Err, "faster"? The following is the moral equiv of 4 kernel updates >> > which had nothing to do using BitKeeper instead of CVS. The local copy >> > was in San Francisco and the remote copy is Cort's machine in New Mexico >> > over a 384Kbits/sec link. All 4 updates in 5 seconds. Anyone have a >> > CVS tree they can try to get comparable numbers? >> >> Try: http://innominate.org/~tgr/projects/lksr/ > Thanks, that was helpful. Comparison numbers for a null update of the 2.3 > kernel, which means you update and then update again, timing the second update > to get some idea of the system's best case throughput, are: > CVS: 139.5 seconds > BK:1.6 seconds > The BK tree is the 2.3 kernel tree maintained by FSMlabs. larry - this one is a bit unfair i think: the innominate.org tree runs right now on a 200mhz pentium and is quite a bit worse connected to you than the bk tree - also it's a "synthetic" tree which contains for instance 100+ tags in the 2.3 tree which might make it a bit slow too ... but all that does not mean that bk is bad - haven't had a look at it so far - i just wanted to say: better avoid such comparisions - i think the mozilla idea (from some mails later) side by side will give a much better comparision t -- [EMAIL PROTECTED] technical director innominate AG clustering & securitynetworking people tel: +49.30.308806-13 fax: -77 http://innominate.de - 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: NFS problems - 2.2.16 (RedHat)
[EMAIL PROTECTED] wrote: > So, is this a known issue with 2.2.16 NFS? Does the NFS backport in 2.2.18 do > anything to resolve these problems? Is there a dedicated NFS mailing list that I > haven't found yet? yes there is one: [EMAIL PROTECTED] t - [EMAIL PROTECTED] technical director innominate AG clustering & securitynetworking people tel: +49.30.308806-13 fax: -77 http://innominate.de - 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: kapmd cpu usage
Stephen Rothwell <[EMAIL PROTECTED]> wrote: > Hi Rik, > Rik van Riel <[EMAIL PROTECTED]> writes: >> >> I have the idea we should really fix this dirty accounting >> thing and properly account kapmd time to idle time. > I got thinking about this and think I went slightly insane :-) > How does the following look ... it makes kapmd equivalent to > the idle processes as far as accounting for time is concerned. > Top looks funny - kapmd is getting 96% of the CPU, but the > CPU is 99.4% idle! :-) i think this together with renaming kapm to "kapmidle" or "apm-idle" should make an end to all this "kapm eats all of my cpu time" confusion ... t -- [EMAIL PROTECTED] technical director innominate AG clustering & securitynetworking people tel: +49.30.308806-13 fax: -77 http://innominate.de - 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: [PATCH] net: stmmac: dwmac-meson8b: ignore the second clock input
On Sat, Dec 19, 2020 at 2:52 PM Martin Blumenstingl
wrote:
>
> The dwmac glue registers on Amlogic Meson8b and newer SoCs has two clock
> inputs:
> - Meson8b and Meson8m2: MPLL2 and MPLL2 (the same parent is wired to
> both inputs)
> - GXBB, GXL, GXM, AXG, G12A, G12B, SM1: FCLK_DIV2 and MPLL2
>
> All known vendor kernels and u-boots are using the first input only. We
> let the common clock framework automatically choose the "right" parent.
> For some boards this causes a problem though, specificially with G12A and
> newer SoCs. The clock input is used for generating the 125MHz RGMII TX
> clock. For the two input clocks this means on G12A:
> - FCLK_DIV2: 99985Hz / 8 = 12498.125Hz
> - MPLL2: 49993Hz / 4 = 12498.25Hz
>
> In theory MPLL2 is the "better" clock input because it's gets us 0.125Hz
> closer to the requested frequency than FCLK_DIV2. In reality however
> there is a resource conflict because MPLL2 is needed to generate some of
> the audio clocks. dwmac-meson8b probes first and sets up the clock tree
> with MPLL2. This works fine until the audio driver comes and "steals"
> the MPLL2 clocks and configures it with it's own rate (294909637Hz). The
> common clock framework happily changes the MPLL2 rate but does not
> reconfigure our RGMII TX clock tree, which then ends up at 73727409Hz,
> which is more than 40% off the requested 125MHz.
>
> Don't use the second clock input for now to force the common clock
> framework to always select the first parent. This mimics the behavior
> from the vendor driver and fixes the clock resource conflict with the
> audio driver on G12A boards. Once the common clock framework can handle
> this situation this change can be reverted again.
>
> Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson
> 8b / GXBB DWMAC")
> Reported-by: Thomas Graichen
> Signed-off-by: Martin Blumenstingl
Tested-by: thomas graichen
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> index 459ae715b33d..f184b00f5116 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> @@ -135,7 +135,7 @@ static int meson8b_init_rgmii_tx_clk(struct meson8b_dwmac
> *dwmac)
> struct device *dev = dwmac->dev;
> static const struct clk_parent_data mux_parents[] = {
> { .fw_name = "clkin0", },
> - { .fw_name = "clkin1", },
> + { .index = -1, },
> };
> static const struct clk_div_table div_table[] = {
> { .div = 2, .val = 2, },
> --
> 2.29.2
>
Re: [PATCH 1/2] mmc: host: meson-mx-sdhc: fix manual RX FIFO flushing
On Mon, May 18, 2020 at 12:29 AM Martin Blumenstingl
wrote:
>
> For Meson8 and Meson8b SoCs the vendor driver follows the following
> pattern:
> - for eMMC and SD cards in .set_pdma it sets:
> pdma->rxfifo_manual_flush = 1;
> - for SDIO cards in .set_pdma it sets:
> pdma->rxfifo_manual_flush = 0;
> - before syncing the DMA read buffer is sets:
> pdma->rxfifo_manual_flush |= 0x02;
>
> Set the second bit of MESON_SDHC_PDMA_RXFIFO_MANUAL_FLUSH without
> clearing the first bit before syncing the DMA read buffer. This fixes a
> problem where Meson8 and Meson8b SoCs would read random garbage from SD
> cards. It is not clear why it worked for eMMC cards. This manifested in
> the following errors when plugging in an SD card:
> unrecognised SCR structure version
>
> Fixes: 53ded1b676d199 ("mmc: host: meson-mx-sdhc: new driver for the Amlogic
> Meson SDHC host")
> Cc: Thomas Graichen
> Signed-off-by: Martin Blumenstingl
Tested-by: thomas graichen
BEFORE: on my meson8 based mxiii i got the above error and the sd card
was not useable
AFTER: no more error and sd cards works fine
> ---
> drivers/mmc/host/meson-mx-sdhc.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/meson-mx-sdhc.c
> b/drivers/mmc/host/meson-mx-sdhc.c
> index 5c00958d7754..53e3f6a4245a 100644
> --- a/drivers/mmc/host/meson-mx-sdhc.c
> +++ b/drivers/mmc/host/meson-mx-sdhc.c
> @@ -586,10 +586,17 @@ static irqreturn_t meson_mx_sdhc_irq_thread(int irq,
> void *irq_data)
> cmd->data->flags & MMC_DATA_READ) {
> meson_mx_sdhc_wait_cmd_ready(host->mmc);
>
> + /*
> +* If MESON_SDHC_PDMA_RXFIFO_MANUAL_FLUSH was
> +* previously 0x1 then it has to be set to 0x3. If it
> +* was 0x0 before then it has to be set to 0x2.
> Without
> +* this reading SD cards sometimes transfers garbage,
> +* which results in cards not being detected due to:
> +* unrecognised SCR structure version number>
> +*/
> val = FIELD_PREP(MESON_SDHC_PDMA_RXFIFO_MANUAL_FLUSH,
> 2);
> - regmap_update_bits(host->regmap, MESON_SDHC_PDMA,
> -
> MESON_SDHC_PDMA_RXFIFO_MANUAL_FLUSH,
> + regmap_update_bits(host->regmap, MESON_SDHC_PDMA, val,
>val);
> }
>
> --
> 2.26.2
>
Re: [PATCH RESEND v1] ARM: dts: meson8: remove two invalid interrupt lines from the GPU node
On Sat, Aug 15, 2020 at 8:20 PM Martin Blumenstingl
wrote:
>
> The 3.10 vendor kernel defines the following GPU 20 interrupt lines:
> #define INT_MALI_GP AM_IRQ(160)
> #define INT_MALI_GP_MMU AM_IRQ(161)
> #define INT_MALI_PP AM_IRQ(162)
> #define INT_MALI_PMUAM_IRQ(163)
> #define INT_MALI_PP0AM_IRQ(164)
> #define INT_MALI_PP0_MMUAM_IRQ(165)
> #define INT_MALI_PP1AM_IRQ(166)
> #define INT_MALI_PP1_MMUAM_IRQ(167)
> #define INT_MALI_PP2AM_IRQ(168)
> #define INT_MALI_PP2_MMUAM_IRQ(169)
> #define INT_MALI_PP3AM_IRQ(170)
> #define INT_MALI_PP3_MMUAM_IRQ(171)
> #define INT_MALI_PP4AM_IRQ(172)
> #define INT_MALI_PP4_MMUAM_IRQ(173)
> #define INT_MALI_PP5AM_IRQ(174)
> #define INT_MALI_PP5_MMUAM_IRQ(175)
> #define INT_MALI_PP6AM_IRQ(176)
> #define INT_MALI_PP6_MMUAM_IRQ(177)
> #define INT_MALI_PP7AM_IRQ(178)
> #define INT_MALI_PP7_MMUAM_IRQ(179)
>
> However, the driver from the 3.10 vendor kernel does not use the
> following four interrupt lines:
> - INT_MALI_PP3
> - INT_MALI_PP3_MMU
> - INT_MALI_PP7
> - INT_MALI_PP7_MMU
>
> Drop the "pp3" and "ppmmu3" interrupt lines. This is also important
> because there is no matching entry in interrupt-names for it (meaning
> the "pp2" interrupt is actually assigned to the "pp3" interrupt line).
>
> Fixes: 7d3f6b536e72c9 ("ARM: dts: meson8: add the Mali-450 MP6 GPU")
> Reported-by: Thomas Graichen
> Signed-off-by: Martin Blumenstingl
Tested-by: thomas graichen
sorry - looks like i missed this one
> ---
> re-send of v1 from [0] because it was never picked up
>
>
> [0] https://patchwork.kernel.org/patch/11582619/
>
>
> arch/arm/boot/dts/meson8.dtsi | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
> index 277c0bb10453..04688e8abce2 100644
> --- a/arch/arm/boot/dts/meson8.dtsi
> +++ b/arch/arm/boot/dts/meson8.dtsi
> @@ -240,8 +240,6 @@ mali: gpu@c {
> ,
> ,
> ,
> -,
> -,
> ,
> ,
> ,
> --
> 2.28.0
>
