Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1221069 > unrolled thread

Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel Petr Cvek <petr.cvek@tul.cz> - 2015-09-08 22:30 +0200
    Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel Petr Cvek <petr.cvek@tul.cz> - 2015-09-09 03:20 +0200
      Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel Robert Jarzmik <robert.jarzmik@free.fr> - 2015-09-09 08:40 +0200
        Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel Petr Cvek <petr.cvek@tul.cz> - 2015-09-10 08:20 +0200
          Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel Robert Jarzmik <robert.jarzmik@free.fr> - 2015-09-10 13:20 +0200
            Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel Petr Cvek <petr.cvek@tul.cz> - 2015-09-11 03:50 +0200
              Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel Robert Jarzmik <robert.jarzmik@free.fr> - 2015-09-11 08:30 +0200
                Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel Petr Cvek <petr.cvek@tul.cz> - 2015-09-12 06:20 +0200
                  Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel Robert Jarzmik <robert.jarzmik@free.fr> - 2015-09-12 13:10 +0200
                    Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel Petr Cvek <petr.cvek@tul.cz> - 2015-09-13 04:50 +0200

#1221069 — Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel

Dne 3.9.2015 v 08:20 Robert Jarzmik napsal(a):
> Convert the pxa IRDA driver to readl and writel primitives, and remove
> another set of direct registers access. This leaves only the DMA
> registers access, which will be dealt with dmaengine conversion.

Test on magician (nonvanilla, but there should not be any collision).

>  
> -	err = request_mem_region(__PREG(STUART), 0x24, "IrDA") ? 0 : -EBUSY;
> -	if (err)
> -		goto err_mem_1;
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	ficp = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(ficp)) {
> +		dev_err(&pdev->dev, "resource ficp not defined\n");

Fails around here with:

[ 4245.368764] pxa2xx-ir pxa2xx-ir: invalid resource
[ 4245.369191] pxa2xx-ir pxa2xx-ir: resource ficp not defined
[ 4245.369364] pxa2xx-ir: probe of pxa2xx-ir failed with error -22

Did you defined resources somewhere? Actual resources are in "pxa_ir_resources" variable at:

	http://lxr.free-electrons.com/source/arch/arm/mach-pxa/devices.c#L386

or this pdata should be moved into specific machine files?

Cheers,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1221171

Dne 8.9.2015 v 22:24 Petr Cvek napsal(a):
> 
> Did you defined resources somewhere? Actual resources are in "pxa_ir_resources" variable at:
> 
> 	http://lxr.free-electrons.com/source/arch/arm/mach-pxa/devices.c#L386
> 
> or this pdata should be moved into specific machine files?
> 

I tried to add following patch for new resources, but now it fails with:

[  141.534545] pxa2xx-ir pxa2xx-ir: can't request region for resource [mem 0x40700000-0x40700100]
[  141.534574] pxa2xx-ir pxa2xx-ir: resource stuart not defined
[  141.534656] pxa2xx-ir: probe of pxa2xx-ir failed with error -16

That's because STUART is allocated by normal UART driver at:

	http://lxr.free-electrons.com/source/arch/arm/mach-pxa/devices.c#L244

So somehow there must be configuration for STUART used with FICP and STUART alone (probably can be used for normal UART).


diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index 3543466..316ffa3 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -394,6 +394,26 @@ static struct resource pxa_ir_resources[] = {
 		.end    = IRQ_ICP,
 		.flags  = IORESOURCE_IRQ,
 	},
+	[2] = {
+		.start  = 0x40800000,
+		.end    = 0x40800000 + 0x100,
+		.flags  = IORESOURCE_MEM,
+	},
+	[3] = {
+		.start  = 0x40700000,
+		.end    = 0x40700000 + 0x100,
+		.flags  = IORESOURCE_MEM,
+	},
+	[4] = {
+		.start  = 17,
+		.end    = 17,
+		.flags  = IORESOURCE_DMA,
+	},
+	[5] = {
+		.start  = 18,
+		.end    = 18,
+		.flags  = IORESOURCE_DMA,
+	},
 };
 
 struct platform_device pxa_device_ficp = {
-- 
1.7.12.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1221272

Petr Cvek <petr.cvek@tul.cz> writes:

> Dne 8.9.2015 v 22:24 Petr Cvek napsal(a):
>> 
>> Did you defined resources somewhere? Actual resources are in
>> "pxa_ir_resources" variable at:
I have them in patch [1], which is exactly the patch you have made yourself.

> I tried to add following patch for new resources, but now it fails with:
>
> [  141.534545] pxa2xx-ir pxa2xx-ir: can't request region for resource [mem 0x40700000-0x40700100]
> [  141.534574] pxa2xx-ir pxa2xx-ir: resource stuart not defined
> [  141.534656] pxa2xx-ir: probe of pxa2xx-ir failed with error -16
>
> That's because STUART is allocated by normal UART driver at:
>
> 	http://lxr.free-electrons.com/source/arch/arm/mach-pxa/devices.c#L244
>
> So somehow there must be configuration for STUART used with FICP and STUART
> alone (probably can be used for normal UART).
That's because you have to remove from magician.c:
	pxa_set_stuart_info(NULL);

Cheers.

--
Robert

[1]
From ea242c5b1c4dcdf2a99ea604ee542ded5e6384b9 Mon Sep 17 00:00:00 2001
From: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Sat, 29 Aug 2015 00:37:51 +0200
Subject: [PATCH] ARM: pxa: add resources to pxaficp_ir

Add io memory and dma requestor lines to the irda pxa device. This is
part of the conversion of pxaficp_ir to dmaengine, and to shrink its
adherence to 'mach' includes.

Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
 arch/arm/mach-pxa/devices.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index e6ce669b54af..6d5ab8199536 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -395,6 +395,26 @@ static struct resource pxa_ir_resources[] = {
 		.end    = IRQ_ICP,
 		.flags  = IORESOURCE_IRQ,
 	},
+	[3] = {
+		.start  = 0x40800000,
+		.end	= 0x4080001b,
+		.flags  = IORESOURCE_MEM,
+	},
+	[4] = {
+		.start  = 0x40700000,
+		.end	= 0x40700023,
+		.flags  = IORESOURCE_MEM,
+	},
+	[5] = {
+		.start  = 17,
+		.end	= 17,
+		.flags  = IORESOURCE_DMA,
+	},
+	[6] = {
+		.start  = 18,
+		.end	= 18,
+		.flags  = IORESOURCE_DMA,
+	},
 };
 
 struct platform_device pxa_device_ficp = {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1221941

Dne 9.9.2015 v 08:25 Robert Jarzmik napsal(a):
> Petr Cvek <petr.cvek@tul.cz> writes:
> 
>> Dne 8.9.2015 v 22:24 Petr Cvek napsal(a):
>>>
>>> Did you defined resources somewhere? Actual resources are in
>>> "pxa_ir_resources" variable at:
> I have them in patch [1], which is exactly the patch you have made yourself.

Is there a mailing list for this specific patch? It seems I did not get any mail with it.

> 
>> I tried to add following patch for new resources, but now it fails with:
>>
>> [  141.534545] pxa2xx-ir pxa2xx-ir: can't request region for resource [mem 0x40700000-0x40700100]
>> [  141.534574] pxa2xx-ir pxa2xx-ir: resource stuart not defined
>> [  141.534656] pxa2xx-ir: probe of pxa2xx-ir failed with error -16
>>
>> That's because STUART is allocated by normal UART driver at:
>>
>> 	http://lxr.free-electrons.com/source/arch/arm/mach-pxa/devices.c#L244
>>
>> So somehow there must be configuration for STUART used with FICP and STUART
>> alone (probably can be used for normal UART).
> That's because you have to remove from magician.c:
> 	pxa_set_stuart_info(NULL);
> 

Thanks, I missed that.

BTW This patch required update of my kernel repo. It seems that my:

	magician.c patches + ficp patch + new dma engine

does not work for me at all. Kernel throws some panic about interrupts and then it ends in an infinite stack dumping loop. Fault occurs before rootfs is mounted, so probably around MMC init (with removed SD card it fails normally with no rootfs found error).

Is it required to change something in the mach-pxa machine specific files?

Which hardware was used for testing new dma engine implementation? Notably MMC driver part, probably commit:

	6464b71409511939efce1ae4fb4ec6e3483b11b2

Best regards,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222125

Petr Cvek <petr.cvek@tul.cz> writes:

> Dne 9.9.2015 v 08:25 Robert Jarzmik napsal(a):
>> Petr Cvek <petr.cvek@tul.cz> writes:
>> 
>>> Dne 8.9.2015 v 22:24 Petr Cvek napsal(a):
>>>>
>>>> Did you defined resources somewhere? Actual resources are in
>>>> "pxa_ir_resources" variable at:
>> I have them in patch [1], which is exactly the patch you have made yourself.
>
> Is there a mailing list for this specific patch? It seems I did not get any
> mail with it.
Should have been posted to linux arm kernel mailing list, unless my mailer
failed ...

> BTW This patch required update of my kernel repo. It seems that my:
>
> 	magician.c patches + ficp patch + new dma engine
>
> does not work for me at all. Kernel throws some panic about interrupts and then
> it ends in an infinite stack dumping loop. Fault occurs before rootfs is
> mounted, so probably around MMC init (with removed SD card it fails normally
> with no rootfs found error).
Could you send me (privately) the stack you're getting please. This is something
I'd like to catch up early in the -rc releases.

> Is it required to change something in the mach-pxa machine specific files?
Nope. As long as CONFIG_PXA_DMA is set, it's alright. Building on top of
linux-next of the future v4.3-rc1 would be better, as the dmaengine support
should be consistent across drivers/dma and arch/arm/mach-pxa in there.

> Which hardware was used for testing new dma engine implementation? Notably MMC
> driver part, probably commit:
Mioa701 (pxa270), cm-x300 (pxa310), zylonite (pxa310). The MMC was specificaly
tested on mioa701, on top of linux-next a week ago (about the day v4.2 was released).

Now with your stack, could you also give me the upstream commit id of the tip of
the tree you're using (before your patches) please ?

And it is true I have not tested the rootfs special case, where drivers are not
yet initialized (and more specifically gpio and interrupt chip). Your backtrace
should tell me if you fall into this category of issues ... but I digress, this
has no link with pxaficp.

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222472

Dne 10.9.2015 v 13:14 Robert Jarzmik napsal(a):
> Petr Cvek <petr.cvek@tul.cz> writes:
> 
>> Dne 9.9.2015 v 08:25 Robert Jarzmik napsal(a):
>>> Petr Cvek <petr.cvek@tul.cz> writes:
>>>
>>>> Dne 8.9.2015 v 22:24 Petr Cvek napsal(a):
>>>>>
>>>>> Did you defined resources somewhere? Actual resources are in
>>>>> "pxa_ir_resources" variable at:
>>> I have them in patch [1], which is exactly the patch you have made yourself.
>>
>> Is there a mailing list for this specific patch? It seems I did not get any
>> mail with it.
> Should have been posted to linux arm kernel mailing list, unless my mailer
> failed ...
> 
Searching for:

	"ARM: pxa: add resources to pxaficp_ir"

did not found anything, same was for "ficp" in the linux-arm-kernel/netdev/linux-kernel
mailing list archive.

>> BTW This patch required update of my kernel repo. It seems that my:
>>
>> 	magician.c patches + ficp patch + new dma engine
>>
>> does not work for me at all. Kernel throws some panic about interrupts and then
>> it ends in an infinite stack dumping loop. Fault occurs before rootfs is
>> mounted, so probably around MMC init (with removed SD card it fails normally
>> with no rootfs found error).
> Could you send me (privately) the stack you're getting please. This is something
> I'd like to catch up early in the -rc releases.

Well this will be problem as I cannot save anything to an SD card after and during the failure.
Only viable interfaces would be earlycon on an infraport or high speed camera on LCD :-). 

But I was able to revert this commit:

	6464b71409511939efce1ae4fb4ec6e3483b11b2	mmc: pxamci: switch over to dmaengine use

and after that I am able to boot.

> 
> Now with your stack, could you also give me the upstream commit id of the tip of
> the tree you're using (before your patches) please ?

It is probably irelevant now, but for complete information:

Discovered on my working repo: mainline b8889c4fc6ba03e289cec6a4d692f6f080a55e53
Still present on fresh downloaded: linux-next 22dc312d56ba077db27a9798b340e7d161f1df05

> 
> And it is true I have not tested the rootfs special case, where drivers are not
> yet initialized (and more specifically gpio and interrupt chip). Your backtrace
> should tell me if you fall into this category of issues ... but I digress, this
> has no link with pxaficp.

Should I start new thread? (same bug can be present in the FICP too)

I will try to configure an initrd rootfs this should create more ways to save kernel log.


Anyway after mmc dma revert I was still not able to start FICP. There is an error:

	Unable to handle kernel paging request at virtual address 32e00004

from pxa_irda_startup() and it seems it is caused by register definitions. For example:

	writel_relaxed((val), (irda)->stuart_base + (off));

is called by

	stuart_writel(si, 0, STIER);

but STIER is not just an offset, but full register address:
	
	__REG(0x40700004)

So the definition should be changed, unless there is another patch I did not received (in that case, send me full patchset again please) :-).


Best regards,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222551

Petr Cvek <petr.cvek@tul.cz> writes:

>> Should have been posted to linux arm kernel mailing list, unless my mailer
>> failed ...
>> 
> Searching for:
>
> 	"ARM: pxa: add resources to pxaficp_ir"
>
> did not found anything, same was for "ficp" in the linux-arm-kernel/netdev/linux-kernel
> mailing list archive.
Ah ok, I'll resend it then.

>>> BTW This patch required update of my kernel repo. It seems that my:
>>>
>>> 	magician.c patches + ficp patch + new dma engine
>>>
>>> does not work for me at all. Kernel throws some panic about interrupts and then
>>> it ends in an infinite stack dumping loop. Fault occurs before rootfs is
>>> mounted, so probably around MMC init (with removed SD card it fails normally
>>> with no rootfs found error).
>> Could you send me (privately) the stack you're getting please. This is something
>> I'd like to catch up early in the -rc releases.
>
> Well this will be problem as I cannot save anything to an SD card after and
> during the failure.  Only viable interfaces would be earlycon on an infraport
> or high speed camera on LCD :-).
Ah just as on my mioa701. I ended up soldering a JTAG cable :)

> But I was able to revert this commit:
>
> 	6464b71409511939efce1ae4fb4ec6e3483b11b2	mmc: pxamci: switch over to dmaengine use
>
> and after that I am able to boot.
Okay. I'll try to reproduce this failure then. If I fail, well, before using the
JTAG cable, I used another trick: I was taking a movie from the LCD with a
smartphone, and it worked. It was an horrible thing to decrypt ... Let's hope
I'll be lucky on one of my platforms.

>> Now with your stack, could you also give me the upstream commit id of the tip of
>> the tree you're using (before your patches) please ?
>
> It is probably irelevant now, but for complete information:
>
> Discovered on my working repo: mainline b8889c4fc6ba03e289cec6a4d692f6f080a55e53
> Still present on fresh downloaded: linux-next
> 22dc312d56ba077db27a9798b340e7d161f1df05
Ok, thanks.

>> And it is true I have not tested the rootfs special case, where drivers are not
>> yet initialized (and more specifically gpio and interrupt chip). Your backtrace
>> should tell me if you fall into this category of issues ... but I digress, this
>> has no link with pxaficp.
>
> Should I start new thread? (same bug can be present in the FICP too)
Yes, this pxamci bothers me, it deserves a thread.

> I will try to configure an initrd rootfs this should create more ways to save
> kernel log.
Great idea.

>
> Anyway after mmc dma revert I was still not able to start FICP. There is an error:
>
> 	Unable to handle kernel paging request at virtual address 32e00004
>
> from pxa_irda_startup() and it seems it is caused by register definitions. For example:
>
> 	writel_relaxed((val), (irda)->stuart_base + (off));
>
> is called by
>
> 	stuart_writel(si, 0, STIER);
>
> but STIER is not just an offset, but full register address:
> 	
> 	__REG(0x40700004)
>
> So the definition should be changed, unless there is another patch I did not
> received (in that case, send me full patchset again please) :-).
Agreed, this is a bug in this patch. With this fix, is the pxaficp working or do
you need a bit more time to experiment ?

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223295

Dne 11.9.2015 v 08:18 Robert Jarzmik napsal(a):
> Petr Cvek <petr.cvek@tul.cz> writes:
> 
>>> Should have been posted to linux arm kernel mailing list, unless my mailer
>>> failed ...
>>>
>> Searching for:
>>
>> 	"ARM: pxa: add resources to pxaficp_ir"
>>
>> did not found anything, same was for "ficp" in the linux-arm-kernel/netdev/linux-kernel
>> mailing list archive.
> Ah ok, I'll resend it then.
> 
>>>> BTW This patch required update of my kernel repo. It seems that my:
>>>>
>>>> 	magician.c patches + ficp patch + new dma engine
>>>>
>>>> does not work for me at all. Kernel throws some panic about interrupts and then
>>>> it ends in an infinite stack dumping loop. Fault occurs before rootfs is
>>>> mounted, so probably around MMC init (with removed SD card it fails normally
>>>> with no rootfs found error).
>>> Could you send me (privately) the stack you're getting please. This is something
>>> I'd like to catch up early in the -rc releases.
>>
>> Well this will be problem as I cannot save anything to an SD card after and
>> during the failure.  Only viable interfaces would be earlycon on an infraport
>> or high speed camera on LCD :-).
> Ah just as on my mioa701. I ended up soldering a JTAG cable :)
Rather not :-D.

> 
>>> And it is true I have not tested the rootfs special case, where drivers are not
>>> yet initialized (and more specifically gpio and interrupt chip). Your backtrace
>>> should tell me if you fall into this category of issues ... but I digress, this
>>> has no link with pxaficp.
>>
>> Should I start new thread? (same bug can be present in the FICP too)
> Yes, this pxamci bothers me, it deserves a thread.

Will start soon.

>>
>> Anyway after mmc dma revert I was still not able to start FICP. There is an error:
>>
>> 	Unable to handle kernel paging request at virtual address 32e00004
>>
>> from pxa_irda_startup() and it seems it is caused by register definitions. For example:
>>
>> 	writel_relaxed((val), (irda)->stuart_base + (off));
>>
>> is called by
>>
>> 	stuart_writel(si, 0, STIER);
>>
>> but STIER is not just an offset, but full register address:
>> 	
>> 	__REG(0x40700004)
>>
>> So the definition should be changed, unless there is another patch I did not
>> received (in that case, send me full patchset again please) :-).
> Agreed, this is a bug in this patch. With this fix, is the pxaficp working or do
> you need a bit more time to experiment ?

I have tried with a nasty hack (use only lower part of address, it should equal with reg offset):
	#undef __REG
	-#define __REG(x) (x)
	+#define __REG(x) (x & 0xffff)

and it seems to work. The module inits and I am able to see IrDA traffic and ping other machine. FIR mode (mostly impacted by DMA) is still untested as magician unfortunately supports only SIR mode.

Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223384

Petr Cvek <petr.cvek@tul.cz> writes:

>>>> And it is true I have not tested the rootfs special case, where drivers are not
>>>> yet initialized (and more specifically gpio and interrupt chip). Your backtrace
>>>> should tell me if you fall into this category of issues ... but I digress, this
>>>> has no link with pxaficp.
>>>
>>> Should I start new thread? (same bug can be present in the FICP too)
>> Yes, this pxamci bothers me, it deserves a thread.
>
> Will start soon.
And I think I see your problem now :
  (a) there is a regression from the commit 8c8fe97b2b8a, for which the fix is
  here: https://lkml.org/lkml/2015/9/6/112
  (b) for gpio expanders, another fix is here :
  https://lkml.org/lkml/2015/9/12/62

The regression is on dmaengine, that's where the thread belongs I think, at
least if that fixes your issue.

>>> but STIER is not just an offset, but full register address:
>>> 	
>>> 	__REG(0x40700004)
>>>
>>> So the definition should be changed, unless there is another patch I did not
>>> received (in that case, send me full patchset again please) :-).
>> Agreed, this is a bug in this patch. With this fix, is the pxaficp working or do
>> you need a bit more time to experiment ?
>
> I have tried with a nasty hack (use only lower part of address, it should equal with reg offset):
> 	#undef __REG
> 	-#define __REG(x) (x)
> 	+#define __REG(x) (x & 0xffff)
>
> and it seems to work. The module inits and I am able to see IrDA traffic and
> ping other machine. FIR mode (mostly impacted by DMA) is still untested as
> magician unfortunately supports only SIR mode.
Okay, I'll add a fix in the next iteration, thanks for finding this.

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223541

Dne 12.9.2015 v 13:03 Robert Jarzmik napsal(a):
> Petr Cvek <petr.cvek@tul.cz> writes:
> 
>>>>> And it is true I have not tested the rootfs special case, where drivers are not
>>>>> yet initialized (and more specifically gpio and interrupt chip). Your backtrace
>>>>> should tell me if you fall into this category of issues ... but I digress, this
>>>>> has no link with pxaficp.
>>>>
>>>> Should I start new thread? (same bug can be present in the FICP too)
>>> Yes, this pxamci bothers me, it deserves a thread.
>>
>> Will start soon.
> And I think I see your problem now :
>   (a) there is a regression from the commit 8c8fe97b2b8a, for which the fix is
>   here: https://lkml.org/lkml/2015/9/6/112
>   (b) for gpio expanders, another fix is here :
>   https://lkml.org/lkml/2015/9/12/62
> 
> The regression is on dmaengine, that's where the thread belongs I think, at
> least if that fixes your issue.
> 
Great now it finally boots. Thanks.

Petr

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web