+0x14/0x1c
Signed-off-by: Steven J. Hill <steven.h...@cavium.com>
---
mm/vmstat.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 40b2db6..33581be 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1839,9 +1839,11 @@ static void vmstat_update(struct work_str
+0x14/0x1c
Signed-off-by: Steven J. Hill
---
mm/vmstat.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 40b2db6..33581be 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1839,9 +1839,11 @@ static void vmstat_update(struct work_struct *w
On 01/23/2018 07:40 PM, Florian Fainelli wrote:
[...]
>
> Florian Fainelli (2):
> MIPS: Allow including mach-generic/dma-coherence.h
> MIPS: Update dma-coherence.h files
>
I have tested these on our Octeon III platforms with PCIe and saw
no issues. Thanks.
Steve
Test
g eXtended KSEG0/1
> MIPS: BMIPS: Handshake with CFE
> MIPS: BMIPS: Add support for eXtended KSEG0/1 (XKS01)
>
I have tested these with your previous "MIPS: generic dma-coherence
inclusion" patchset on our Octeon III platforms with PCIe and saw
no issues. Thanks.
Steve
On 01/23/2018 07:40 PM, Florian Fainelli wrote:
[...]
>
> Florian Fainelli (2):
> MIPS: Allow including mach-generic/dma-coherence.h
> MIPS: Update dma-coherence.h files
>
I have tested these on our Octeon III platforms with PCIe and saw
no issues. Thanks.
Steve
Test
g eXtended KSEG0/1
> MIPS: BMIPS: Handshake with CFE
> MIPS: BMIPS: Add support for eXtended KSEG0/1 (XKS01)
>
I have tested these with your previous "MIPS: generic dma-coherence
inclusion" patchset on our Octeon III platforms with PCIe and saw
no issues. Thanks.
Steve
Tested-by: Steven J. Hill
;>
>> Signed-off-by: Rob Herring <r...@kernel.org>
>> Cc: Ulf Hansson <ulf.hans...@linaro.org>
>> Cc: Ludovic Desroches <ludovic.desroc...@microchip.com>
>> Cc: Jan Glauber <jglau...@cavium.com>
>> Cc: David Daney <david.da...@cavium.co
;>
>> Signed-off-by: Rob Herring
>> Cc: Ulf Hansson
>> Cc: Ludovic Desroches
>> Cc: Jan Glauber
>> Cc: David Daney
>> Cc: "Steven J. Hill"
>> Cc: linux-...@vger.kernel.org
>
> For the Cavium bits, I haven't tested them, but t
On 04/24/2017 02:56 PM, Ulf Hansson wrote:
[]
>
> Thanks, applied patch 1->3. Patch 4 is for the MIPS SoC maintainer,
> unless I get an ack for it.
>
Thanks Uffe.
Ralf, please take patch 4/4 into your -next branch. Cheers.
-Steve
On 04/24/2017 02:56 PM, Ulf Hansson wrote:
[]
>
> Thanks, applied patch 1->3. Patch 4 is for the MIPS SoC maintainer,
> unless I get an ack for it.
>
Thanks Uffe.
Ralf, please take patch 4/4 into your -next branch. Cheers.
-Steve
From: "Steven J. Hill" <steven.h...@cavium.com>
Add platform driver for Octeon SOCs.
Signed-off-by: Steven J. Hill <steven.h...@cavium.com>
Signed-off-by: David Daney <david.da...@cavium.com>
---
drivers/mmc/host/Kconfig | 10 ++
drivers/mmc/host/Makefile
From: "Steven J. Hill"
Add platform driver for Octeon SOCs.
Signed-off-by: Steven J. Hill
Signed-off-by: David Daney
---
drivers/mmc/host/Kconfig | 10 ++
drivers/mmc/host/Makefile| 2 +
drivers/mmc/host/cavium-octeon.c | 351
From: "Steven J. Hill" <steven.h...@cavium.com>
Enable the Octeon MMC driver in the defconfig.
Signed-off-by: Steven J. Hill <steven.h...@cavium.com>
---
arch/mips/configs/cavium_octeon_defconfig | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/mips/configs/c
From: "Steven J. Hill"
Enable the Octeon MMC driver in the defconfig.
Signed-off-by: Steven J. Hill
---
arch/mips/configs/cavium_octeon_defconfig | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/mips/configs/cavium_octeon_defconfig
b/arch/mips/configs/cavium_octeon
g>
Signed-off-by: Steven J. Hill <steven.h...@cavium.com>
Acked-by: David Daney <david.da...@cavium.com>
---
drivers/mmc/core/core.c | 6 ++
include/linux/mmc/card.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index
From: Ulf Hansson
Some hosts controllers, like Cavium, needs to know whether the card
operates in byte- or block-address mode. Therefore export a new API,
mmc_card_is_blockaddr(), which provides this information.
Signed-off-by: Ulf Hansson
Signed-off-by: Steven J. Hill
Acked-by: David Daney
From: "Steven J. Hill" <steven.h...@cavium.com>
Enable MMC support on Octeon SoCs. Tested on EdgeRouter Pro,
SFF7000, and SFF7800 platforms. This should be applied on top
of the "Cavium MMC driver" patch series from Jan Glauber.
Steven J. Hill (3):
mmc: cavium: Fix
From: "Steven J. Hill"
Enable MMC support on Octeon SoCs. Tested on EdgeRouter Pro,
SFF7000, and SFF7800 platforms. This should be applied on top
of the "Cavium MMC driver" patch series from Jan Glauber.
Steven J. Hill (3):
mmc: cavium: Fix detection of block or byte addre
From: "Steven J. Hill" <steven.h...@cavium.com>
Use the mmc_card_is_blockaddr() function to properly detect if the
card uses byte or block addressing.
Signed-off-by: Steven J. Hill <steven.h...@cavium.com>
Acked-by: David Daney <david.da...@cavium.com>
---
drivers
From: "Steven J. Hill"
Use the mmc_card_is_blockaddr() function to properly detect if the
card uses byte or block addressing.
Signed-off-by: Steven J. Hill
Acked-by: David Daney
---
drivers/mmc/host/cavium.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
On 04/20/2017 04:24 PM, Steven J. Hill wrote:
> On 04/20/2017 12:12 PM, David Daney wrote:
>>
>> Steven and Jan: Can we get around this requirement by:
>>
>> - Always set MIO_EMM_DMA[MULTI] = 1; This way by SECTOR mode may be
>> unimportant.
>
On 04/20/2017 04:24 PM, Steven J. Hill wrote:
> On 04/20/2017 12:12 PM, David Daney wrote:
>>
>> Steven and Jan: Can we get around this requirement by:
>>
>> - Always set MIO_EMM_DMA[MULTI] = 1; This way by SECTOR mode may be
>> unimportant.
>
On 04/20/2017 12:12 PM, David Daney wrote:
>
> Steven and Jan: Can we get around this requirement by:
>
> - Always set MIO_EMM_DMA[MULTI] = 1; This way by SECTOR mode may be
> unimportant.
>
> - Always set MIO_EMM_DMA[SECTOR] = SUITABLE_CONSTANT.
>
No, this does not work. The 1.88GB card
On 04/20/2017 12:12 PM, David Daney wrote:
>
> Steven and Jan: Can we get around this requirement by:
>
> - Always set MIO_EMM_DMA[MULTI] = 1; This way by SECTOR mode may be
> unimportant.
>
> - Always set MIO_EMM_DMA[SECTOR] = SUITABLE_CONSTANT.
>
No, this does not work. The 1.88GB card
On 04/20/2017 09:18 AM, Ulf Hansson wrote:
>>
>> The Cavium hardware requires knowledge of the card addressing mode.
>> We need to either restore mmc_card_blockaddr(), or create another
>> way to generate the same information. You previously suggested use
>> of the 'blksz' value, however, it has
On 04/20/2017 09:18 AM, Ulf Hansson wrote:
>>
>> The Cavium hardware requires knowledge of the card addressing mode.
>> We need to either restore mmc_card_blockaddr(), or create another
>> way to generate the same information. You previously suggested use
>> of the 'blksz' value, however, it has
Uffe,
The Cavium hardware requires knowledge of the card addressing mode.
We need to either restore mmc_card_blockaddr(), or create another
way to generate the same information. You previously suggested use
of the 'blksz' value, however, it has the same value regardless of
the card capacity. What
Uffe,
The Cavium hardware requires knowledge of the card addressing mode.
We need to either restore mmc_card_blockaddr(), or create another
way to generate the same information. You previously suggested use
of the 'blksz' value, however, it has the same value regardless of
the card capacity. What
On 04/12/2017 05:37 PM, Aaro Koskinen wrote:
>
> Please rather post a new version that also works with OCTEON. I don't
> think a partial driver should be merged; originally this driver was
> working fine with OCTEON so there should be no issue supporting that?!
>
Hey Aaro.
The difference is that
On 04/12/2017 05:37 PM, Aaro Koskinen wrote:
>
> Please rather post a new version that also works with OCTEON. I don't
> think a partial driver should be merged; originally this driver was
> working fine with OCTEON so there should be no issue supporting that?!
>
Hey Aaro.
The difference is that
step to add
> relocation information into vmlinux, and remove the additional steps
> tacked onto boot targets.
>
> Signed-off-by: Matt Redfearn <matt.redfe...@imgtec.com>
>
Tested on OCTEON III with relocatable kernel.
Tested-by: Steven J. Hill <steven.h...@cavium.com>
step to add
> relocation information into vmlinux, and remove the additional steps
> tacked onto boot targets.
>
> Signed-off-by: Matt Redfearn
>
Tested on OCTEON III with relocatable kernel.
Tested-by: Steven J. Hill
This patch adds support to parse probe data for
the dwc3-octeon driver using device tree. The
DWC3 IP core is found on OCTEON III processors.
Signed-off-by: Steven J. Hill <steven.h...@cavium.com>
Changes in v3:
- Massive simplification of glue logic. Almost all the
work is done in t
This patch adds support to parse probe data for
the dwc3-octeon driver using device tree. The
DWC3 IP core is found on OCTEON III processors.
Signed-off-by: Steven J. Hill
Changes in v3:
- Massive simplification of glue logic. Almost all the
work is done in the SoC platform code.
Changes
This patch adds support to parse the data for
the dwc3-octeon driver using device tree. The
DWC3 IP core is found on OCTEON III processors.
Signed-off-by: Steven J. Hill <steven.h...@cavium.com>
Changes in v2:
- Changed comment block to acurately describe why the DMA
properties are bei
This patch adds support to parse the data for
the dwc3-octeon driver using device tree. The
DWC3 IP core is found on OCTEON III processors.
Signed-off-by: Steven J. Hill
Changes in v2:
- Changed comment block to acurately describe why the DMA
properties are being set.
- Deleted
This patch adds support to parse probe data for
the dwc3-octeon driver using device tree. The
DWC3 IP core is found on OCTEON III processors.
Signed-off-by: Steven J. Hill <steven.h...@cavium.com>
---
drivers/usb/dwc3/Kconfig | 10 +
drivers/usb/dwc3/Makefile | 1 +
drive
This patch adds support to parse probe data for
the dwc3-octeon driver using device tree. The
DWC3 IP core is found on OCTEON III processors.
Signed-off-by: Steven J. Hill
---
drivers/usb/dwc3/Kconfig | 10 +
drivers/usb/dwc3/Makefile | 1 +
drivers/usb/dwc3/dwc3-octeon.c | 96
On 08/23/2016 03:36 PM, Aaro Koskinen wrote:
Hi,
gpio-leds fails to probe on OCTEON with v4.8-rc3 and when using
arch/mips/boot/dts/cavium-octeon/dlink_dsr-1000n.dts. Leds still
worked with v4.7.
I bisected this to:
commit 15cc2ed6dcf91a8658e084be4e140147161819d7
Author: Jon
On 08/23/2016 03:36 PM, Aaro Koskinen wrote:
Hi,
gpio-leds fails to probe on OCTEON with v4.8-rc3 and when using
arch/mips/boot/dts/cavium-octeon/dlink_dsr-1000n.dts. Leds still
worked with v4.7.
I bisected this to:
commit 15cc2ed6dcf91a8658e084be4e140147161819d7
Author: Jon
Hey Aaro.
I wanted to apologize for my earlier email that could have been much
shorter without being snarky. In short, we have a long test cycle and
that we are tracking LTS support kernels and will be doing regular
updates. A few months ago 3.10 was chosen as the next LTS version. We
Hey Aaro.
I wanted to apologize for my earlier email that could have been much
shorter without being snarky. In short, we have a long test cycle and
that we are tracking LTS support kernels and will be doing regular
updates. A few months ago 3.10 was chosen as the next LTS version. We
On 11/12/2013 03:02 PM, Aaro Koskinen wrote:
Hi,
On Tue, Nov 12, 2013 at 09:18:18AM -0600, Steven J. Hill wrote:
Imagination Technologies is pleased to announce the release of its
3.10 LTS (Long-Term Support) MIPS kernel. The changelog below is
based off the stable Linux 3.10.14 release done
On 11/12/2013 03:02 PM, Aaro Koskinen wrote:
Hi,
On Tue, Nov 12, 2013 at 09:18:18AM -0600, Steven J. Hill wrote:
Imagination Technologies is pleased to announce the release of its
3.10 LTS (Long-Term Support) MIPS kernel. The changelog below is
based off the stable Linux 3.10.14 release done
Imagination Technologies is pleased to announce the release of its 3.10
LTS (Long-Term Support) MIPS kernel. The changelog below is based off
the stable Linux 3.10.14 release done by Greg Kroah-Hartman in commit
8c15abc94c737f9120d3d4a550abbcbb9be121f6 back on October 1st. The code
repository
Imagination Technologies is pleased to announce the release of its 3.10
LTS (Long-Term Support) MIPS kernel. The changelog below is based off
the stable Linux 3.10.14 release done by Greg Kroah-Hartman in commit
8c15abc94c737f9120d3d4a550abbcbb9be121f6 back on October 1st. The code
repository
Imagination Technologies is pleased to announce the release of its 3.10
LTS (Long-Term Support) MIPS kernel. The changelog below is based off
the stable Linux 3.10.14 release done by Greg Kroah-Hartman in commit
8c15abc94c737f9120d3d4a550abbcbb9be121f6 back on October 1st. The code
repository
Imagination Technologies is pleased to announce the release of its 3.10
LTS (Long-Term Support) MIPS kernel. The changelog below is based off
the stable Linux 3.10.14 release done by Greg Kroah-Hartman in commit
8c15abc94c737f9120d3d4a550abbcbb9be121f6 back on October 1st. The code
repository
with your patches.
Acked-by: Steven J. Hill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
with your patches.
Acked-by: Steven J. Hill steven.h...@imgtec.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/30/2013 12:24 AM, Huacai Chen wrote:
> Loongson-3 maintains cache coherency by hardware. So we introduce a cpu
> feature named cpu_has_coherent_cache and use it to modify MIPS's cache
> flushing functions.
>
> Signed-off-by: Huacai Chen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/30/2013 12:24 AM, Huacai Chen wrote:
Loongson-3 maintains cache coherency by hardware. So we introduce a cpu
feature named cpu_has_coherent_cache and use it to modify MIPS's cache
flushing functions.
Signed-off-by: Huacai Chen
> I have written a loadble module ( which gets complied
> along with kernel) which does some floating point
> operation.
>
NO FLOATING POINT in the kernel PERIOD. Either use integer
operations, or redo your software architecture and do the
floating point in userspace.
-Steve
-
To unsubscribe
I have written a loadble module ( which gets complied
along with kernel) which does some floating point
operation.
NO FLOATING POINT in the kernel PERIOD. Either use integer
operations, or redo your software architecture and do the
floating point in userspace.
-Steve
-
To unsubscribe from
your own version of 'spia.c' and
>
> So the Config.in is wrong since I can select spia on x86
>
Indeed. That should be fixed now with this patch. Now onto the stuff
for ESR.
-Steve
--
Steven J. Hill - Embedded SW Engineer
spia.diff
ks on all of these for you. I won't clutter
up the mailing list with the complete descriptions.
-Steve
--
Steven J. Hill - Embedded SW Engineer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
added comments for how those various values should be
defined. Shame on me for forgetting to comment those months ago. Sorry.
I believe that fixes things now?
-Steve
--
Steven J. Hill - Embedded SW Engineer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
to comment those months ago. Sorry.
I believe that fixes things now?
-Steve
--
Steven J. Hill - Embedded SW Engineer
-
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
list with the complete descriptions.
-Steve
--
Steven J. Hill - Embedded SW Engineer
-
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
the Config.in is wrong since I can select spia on x86
Indeed. That should be fixed now with this patch. Now onto the stuff
for ESR.
-Steve
--
Steven J. Hill - Embedded SW Engineer
spia.diff
ia.c' and
"simply" fill in the addresses for the IO address and control
register address depending on your specific hardware. The above
symbols are only defined for my specific hardware. They should be
changed to values used on your hardware platform. Let me know if
you need further assi
and control
register address depending on your specific hardware. The above
symbols are only defined for my specific hardware. They should be
changed to values used on your hardware platform. Let me know if
you need further assistance.
-Steve
--
Steven J. Hill - Embedded SW Engineer
: Recovery SCB completes
May 9 21:12:57 ptecdev1 kernel: Recovery code awake
May 9 21:12:57 ptecdev1 kernel: aic7xxx_abort returns 8194
--
Steven J. Hill - Embedded SW Engineer
Public Key: 'http://www.cotw.com/pubkey.txt'
FPR1: E124 6E1C AF8E 7802 A815
FPR2: 7D72 829C 3386 4C4A E17D
: Recovery SCB completes
May 9 21:12:57 ptecdev1 kernel: Recovery code awake
May 9 21:12:57 ptecdev1 kernel: aic7xxx_abort returns 8194
--
Steven J. Hill - Embedded SW Engineer
Public Key: 'http://www.cotw.com/pubkey.txt'
FPR1: E124 6E1C AF8E 7802 A815
FPR2: 7D72 829C 3386 4C4A E17D
macro functions sprinkled in. Can someone
shed light on if this is bad or not and why it would be done
or necessary? Thanks.
-Steve
--
Steven J. Hill - Embedded SW Engineer
Public Key: 'http://www.cotw.com/pubkey.txt'
FPR1: E124 6E1C AF8E 7802 A815
FPR2: 7D72 829C 3386 4C4A E17D
-
To unsubscribe
macro functions sprinkled in. Can someone
shed light on if this is bad or not and why it would be done
or necessary? Thanks.
-Steve
--
Steven J. Hill - Embedded SW Engineer
Public Key: 'http://www.cotw.com/pubkey.txt'
FPR1: E124 6E1C AF8E 7802 A815
FPR2: 7D72 829C 3386 4C4A E17D
-
To unsubscribe
things work great. I knew it was
something simple, but I just don't pay attention to LILO much anymore.
Thanks everyone.
-Steve
--
Steven J. Hill - Embedded SW Engineer
Public Key: 'http://www.cotw.com/pubkey.txt'
FPR1: E124 6E1C AF8E 7802 A815
FPR2: 7D72 829C 3386 4C4A E17D
-
To unsubscrib
ILO were working just fine together and I have a newer BIOS that has
not problems detecting the driver properly. Go ahead, call me idiot :).
-Steve
--
Steven J. Hill - Embedded SW Engineer
Public Key: 'http://www.cotw.com/pubkey.txt'
FPR1: E124 6E1C AF8E 7802 A815
FPR2: 7D72 829C 3386 4C4A E
were working just fine together and I have a newer BIOS that has
not problems detecting the driver properly. Go ahead, call me idiot :).
-Steve
--
Steven J. Hill - Embedded SW Engineer
Public Key: 'http://www.cotw.com/pubkey.txt'
FPR1: E124 6E1C AF8E 7802 A815
FPR2: 7D72 829C 3386 4C4A E17D
attention to LILO much anymore.
Thanks everyone.
-Steve
--
Steven J. Hill - Embedded SW Engineer
Public Key: 'http://www.cotw.com/pubkey.txt'
FPR1: E124 6E1C AF8E 7802 A815
FPR2: 7D72 829C 3386 4C4A E17D
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
70 matches
Mail list logo
