Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile

[Jon Ringle]

> On Oct 6, 2015, at 6:13 AM, Mark Brown  wrote:
> 
>> On Mon, Oct 05, 2015 at 11:29:56PM -0700, David Miller wrote:
>> From: Mark Brown 
> 
>>> Dave, to be clear please do *not* apply this patch at least for the time
>>> being - I've not reviewed it or the one from Thursday that you applied
>>> this morning.
> 
>> It's applied, it's pushed out to my tree, and therefore this will need to
>> be fixed up with a relative patch of some sort.
> 
> This appears to be an incremental change, not the initial commit which
> you already applied.  I'm asking you to stop applying changes to regmap
> which have not been reviewed.
> 
>> What you don't seem to understand is that my GIT tree is never rebased
>> or mangled because many people depend upon it.  So once a patch is
>> applied, that commit lives on forever.
> 
> I'm not *so* concerned if the patch lives in history, I'm concerned with
> having something I can sensibly review and ideally getting the code into
> my tree.

I would suggest the following course of action:

1) David, revert the following from net-next:
$ git revert 9886ce2b9d4e5a8bb3d78d0f7eff3c0f1ed58d67
$ git revert 04fbfce7a222327b97ca165294ef19f0faa45960
$ git revert 7741c373cf3ea1f5383fa97fb7a640a429d3dd7c

2) Mark, please use the patch titled "[PATCH net-next v3 1/2] regmap:
Allow installing custom". It will apply cleanly to the regmap for-next
branch
3) Once Mark has accepted this patch into the regmap tree, I will make
any adjustments needed to the net-next patch.
4) David should then merge the regmap for-next branch into net-next
5) I will submit a new patch to net-next for the encx24j600 driver
that should build against the regmap changes

Sound like a good plan?

-Jon
--
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/

Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile

[Jon Ringle]

> On Oct 6, 2015, at 6:13 AM, Mark Brown  wrote:
> 
>> On Mon, Oct 05, 2015 at 11:29:56PM -0700, David Miller wrote:
>> From: Mark Brown 
> 
>>> Dave, to be clear please do *not* apply this patch at least for the time
>>> being - I've not reviewed it or the one from Thursday that you applied
>>> this morning.
> 
>> It's applied, it's pushed out to my tree, and therefore this will need to
>> be fixed up with a relative patch of some sort.
> 
> This appears to be an incremental change, not the initial commit which
> you already applied.  I'm asking you to stop applying changes to regmap
> which have not been reviewed.
> 
>> What you don't seem to understand is that my GIT tree is never rebased
>> or mangled because many people depend upon it.  So once a patch is
>> applied, that commit lives on forever.
> 
> I'm not *so* concerned if the patch lives in history, I'm concerned with
> having something I can sensibly review and ideally getting the code into
> my tree.

I would suggest the following course of action:

1) David, revert the following from net-next:
$ git revert 9886ce2b9d4e5a8bb3d78d0f7eff3c0f1ed58d67
$ git revert 04fbfce7a222327b97ca165294ef19f0faa45960
$ git revert 7741c373cf3ea1f5383fa97fb7a640a429d3dd7c

2) Mark, please use the patch titled "[PATCH net-next v3 1/2] regmap:
Allow installing custom". It will apply cleanly to the regmap for-next
branch
3) Once Mark has accepted this patch into the regmap tree, I will make
any adjustments needed to the net-next patch.
4) David should then merge the regmap for-next branch into net-next
5) I will submit a new patch to net-next for the encx24j600 driver
that should build against the regmap changes

Sound like a good plan?

-Jon
--
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/

Re: [PATCH net-next v2 1/2] regmap: Allow installing custom reg_update_bits function

[Jon Ringle]

On Mon, 5 Oct 2015, David Miller wrote:

> From: j...@ringle.org
> Date: Thu,  1 Oct 2015 07:43:20 -0400
> 
> > From: Jon Ringle 
> > 
> > This commit allows installing a custom reg_update_bits function for cases 
> > where
> > the hardware provides a mechanism to set or clear register bits without a
> > read/modify/write cycle. Such is the case with the Microchip ENCX24J600.
> > 
> > Signed-off-by: Jon Ringle 
> 
> Applied.

Thanks David. However, I've sent a v3 patch, and also expecting feedback 
from Mark Brown on the regmap portion of it.

-Jon

--
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/

Re: [PATCH net-next v2 1/2] regmap: Allow installing custom reg_update_bits function

[Jon Ringle]

On Mon, 5 Oct 2015, David Miller wrote:

> From: j...@ringle.org
> Date: Thu,  1 Oct 2015 07:43:20 -0400
> 
> > From: Jon Ringle <jrin...@gridpoint.com>
> > 
> > This commit allows installing a custom reg_update_bits function for cases 
> > where
> > the hardware provides a mechanism to set or clear register bits without a
> > read/modify/write cycle. Such is the case with the Microchip ENCX24J600.
> > 
> > Signed-off-by: Jon Ringle <jrin...@gridpoint.com>
> 
> Applied.

Thanks David. However, I've sent a v3 patch, and also expecting feedback 
from Mark Brown on the regmap portion of it.

-Jon

--
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/

Re: [PATCH 1/2] regmap: Allow installing custom reg_update_bits function

[Jon Ringle]

On Thu, 1 Oct 2015, Mark Brown wrote:

> On Thu, Oct 01, 2015 at 02:33:06AM -0400, j...@ringle.org wrote:
> 
> > @@ -2509,6 +2510,10 @@ static int _regmap_update_bits(struct regmap *map, 
> > unsigned int reg,
> > int ret;
> > unsigned int tmp, orig;
> >  
> > +   if (map->reg_update_bits)
> > +   return map->reg_update_bits(map->bus_context, reg, mask, val,
> > +   change, force_write);
> > +
> > ret = _regmap_read(map, reg, );
> > if (ret != 0)
> > return ret;
> 
> This completely bypasses and therefore breaks the cache infrastructure.
> 

Hi Mark,

Right after sending the v2 patch, I realized that calling the 
custom reg_update_bits would only be applicable for registers that are 
marked as volatile. Would the following solution be acceptable (it would 
also simplify the regmap_update_bits in the encx24j600 driver):

if (regmap_volatile(map, reg) && map->reg_update_bits) {
return map->reg_update_bits(map->bus_context, reg, mask, 
val, change, force_write);

The cache state should not matter for volatile registers, right?

-Jon
--
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/

Re: [PATCH 1/2] regmap: Allow installing custom reg_update_bits function

[Jon Ringle]

On Thu, 1 Oct 2015, Mark Brown wrote:

> On Thu, Oct 01, 2015 at 02:33:06AM -0400, j...@ringle.org wrote:
> 
> > @@ -2509,6 +2510,10 @@ static int _regmap_update_bits(struct regmap *map, 
> > unsigned int reg,
> > int ret;
> > unsigned int tmp, orig;
> >  
> > +   if (map->reg_update_bits)
> > +   return map->reg_update_bits(map->bus_context, reg, mask, val,
> > +   change, force_write);
> > +
> > ret = _regmap_read(map, reg, );
> > if (ret != 0)
> > return ret;
> 
> This completely bypasses and therefore breaks the cache infrastructure.
> 

Hi Mark,

Right after sending the v2 patch, I realized that calling the 
custom reg_update_bits would only be applicable for registers that are 
marked as volatile. Would the following solution be acceptable (it would 
also simplify the regmap_update_bits in the encx24j600 driver):

if (regmap_volatile(map, reg) && map->reg_update_bits) {
return map->reg_update_bits(map->bus_context, reg, mask, 
val, change, force_write);

The cache state should not matter for volatile registers, right?

-Jon
--
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/

Re: USB_MUSB_DA8XX with g_multi.ko

[Jon Ringle]

On Thu, Jun 26, 2014 at 2:29 AM, Christian Riesch
 wrote:
> Hi Jon,
>
> On Thu, Jun 26, 2014 at 4:46 AM, Jon Ringle  wrote:
>> The only thing I needed to do was to remove the
>> BROKEN dependency on USB_MUSB_DA8XX. Is there anything else I would
>> have to do besides just removing BROKEN to get this accepted back into
>> the kernel source tree?
>
> I tried to remove the BROKEN dependency in [1], but without success.
> See Felipe's response to my patch for more info. There was also
> another discussion about this, see [2].
> Christian
>
> [1] http://marc.info/?t=1394061=1=2
> [2] http://marc.info/?t=13952576757=1=2

Thanks for the additional info.
Since my primary interest is in getting this working on the 3.12 tree,
and the drivers/phy/ source directory had not been added yet at this
point in the history, I am not motivated enough to implement Felipe's
suggestion of moving phy_on()/phy_off() to a drivers/usb/phy-da8xx.c.
If sometime down the road, we decided to move to a newer kernel
release, and the work hasn't been done yet, then I'll have a greater
motivation to implement something along those lines. For now I will
live with just removing BROKEN from our local kernel tree.

Jon
--
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/

Re: USB_MUSB_DA8XX with g_multi.ko

[Jon Ringle]

On Thu, Jun 26, 2014 at 2:29 AM, Christian Riesch
christian.rie...@omicron.at wrote:
 Hi Jon,

 On Thu, Jun 26, 2014 at 4:46 AM, Jon Ringle j...@ringle.org wrote:
 The only thing I needed to do was to remove the
 BROKEN dependency on USB_MUSB_DA8XX. Is there anything else I would
 have to do besides just removing BROKEN to get this accepted back into
 the kernel source tree?

 I tried to remove the BROKEN dependency in [1], but without success.
 See Felipe's response to my patch for more info. There was also
 another discussion about this, see [2].
 Christian

 [1] http://marc.info/?t=1394061r=1w=2
 [2] http://marc.info/?t=13952576757r=1w=2

Thanks for the additional info.
Since my primary interest is in getting this working on the 3.12 tree,
and the drivers/phy/ source directory had not been added yet at this
point in the history, I am not motivated enough to implement Felipe's
suggestion of moving phy_on()/phy_off() to a drivers/usb/phy-da8xx.c.
If sometime down the road, we decided to move to a newer kernel
release, and the work hasn't been done yet, then I'll have a greater
motivation to implement something along those lines. For now I will
live with just removing BROKEN from our local kernel tree.

Jon
--
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/

Re: USB_MUSB_DA8XX with g_multi.ko

[Jon Ringle]

On Wed, Jun 25, 2014 at 11:52 AM, Jon Ringle  wrote:
> On Wed, Jun 25, 2014 at 11:35 AM, Andrzej Pietrasiewicz
>  wrote:
>> W dniu 25.06.2014 17:13, Jon Ringle pisze:
>>
>>> In commit 787f5627bec80094db487bfcb401e9744f181aed
>>> usb: musb: make davinci and da8xx glues depend on BROKEN
>>>
>>> USB_MUSB_DA8XX was marked as BROKEN
>>>
>>> A few months ago, we updated the linux kernel on our AM1808 SoC based
>>> embedded board from Linux 2.6.33 to the latest long term 3.12.
>>>
>>> I am interested in having the USB gadget support on my board, so I
>>> removed BROKEN on USB_MUSB_DA8XX. I found that when I modprobe
>>> g_ether, g_serial, and g_mass_storage (by themselves), they all appear
>>> to work as expected, but if I try to use g_multi to have a composite
>>> device supporting all three simultaneously, I run into failure during
>>> initialization.
>>>
>>
>> 
>>
>>
>>>
>>>> From this I can see that it's failing on the following call in
>>>> fsg_bind():
>>>
>>> ep = usb_ep_autoconfig(gadget, _fs_bulk_in_desc);
>>>
>>
>> Just a random guess (I don't know your hardware): how many bulk,
>> iso and interrupt endpoints does your hardware provide? Perhaps you
>> just run out of endpoints?
>
> Perhaps... From the documentation it appears that I can have 4
> simultaneous RX/TX endpoints... Is this not enough?

I now see that each function seems to require 2 endpoints, so with 4
endpoints available, I can only have two functions with this hardware.
I tested this successfully with g_adm_ms.ko having both serial and
mass storage working. The only thing I needed to do was to remove the
BROKEN dependency on USB_MUSB_DA8XX. Is there anything else I would
have to do besides just removing BROKEN to get this accepted back into
the kernel source tree?

Jon
--
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/

Re: USB_MUSB_DA8XX with g_multi.ko

[Jon Ringle]

On Wed, Jun 25, 2014 at 11:35 AM, Andrzej Pietrasiewicz
 wrote:
> W dniu 25.06.2014 17:13, Jon Ringle pisze:
>
>> In commit 787f5627bec80094db487bfcb401e9744f181aed
>> usb: musb: make davinci and da8xx glues depend on BROKEN
>>
>> USB_MUSB_DA8XX was marked as BROKEN
>>
>> A few months ago, we updated the linux kernel on our AM1808 SoC based
>> embedded board from Linux 2.6.33 to the latest long term 3.12.
>>
>> I am interested in having the USB gadget support on my board, so I
>> removed BROKEN on USB_MUSB_DA8XX. I found that when I modprobe
>> g_ether, g_serial, and g_mass_storage (by themselves), they all appear
>> to work as expected, but if I try to use g_multi to have a composite
>> device supporting all three simultaneously, I run into failure during
>> initialization.
>>
>
> 
>
>
>>
>>> From this I can see that it's failing on the following call in
>>> fsg_bind():
>>
>> ep = usb_ep_autoconfig(gadget, _fs_bulk_in_desc);
>>
>
> Just a random guess (I don't know your hardware): how many bulk,
> iso and interrupt endpoints does your hardware provide? Perhaps you
> just run out of endpoints?

Perhaps... From the documentation it appears that I can have 4
simultaneous RX/TX endpoints... Is this not enough?

34.1.2 Features
The USB has the following features:
• Operating as a host, it complies with the USB 2.0 standard for
high-speed (480 Mbps), full-speed
(12 Mbps), and low-speed (1.5 Mbps) operations with a peripheral
• Operating as a peripheral, it complies with the USB 2.0 standard for
high-speed (480 Mbps) and
full-speed (12 Mbps) operation with a host.
• Supports USB extensions for Session Request (SRP) and Host
Negotiation (HNP) – OTG
• Supports 4 simultaneous RX and TX endpoints, in addition to control
endpoint, more devices can be
supported by dynamically switching endpoints states
• Each endpoint (other than endpoint 0) can support all transfer types
(control, bulk, interrupt, and
isochronous)
• Includes a 4K endpoint FIFO RAM, and supports programmable FIFO sizes
• External 5V power supply for VBUS, when operating as host, enabled
directly by the USB controller
through a dedicated signal
• Includes a DMA controller that supports 4 TX and 4 RX DMA channels
• Includes four types of Communications Port Programming Interface
(CPPI) 4.1 DMA compliant transfer
modes, Transparent, Generic RNDIS, RNDIS, and Linux CDC mode of DMA
for accelerating RNDIS
type protocols using short packet termination over USB.
• DMA supports single data transfer size up to 4Mbytes
--
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/

USB_MUSB_DA8XX with g_multi.ko

[Jon Ringle]

In commit 787f5627bec80094db487bfcb401e9744f181aed
usb: musb: make davinci and da8xx glues depend on BROKEN

USB_MUSB_DA8XX was marked as BROKEN

A few months ago, we updated the linux kernel on our AM1808 SoC based
embedded board from Linux 2.6.33 to the latest long term 3.12.

I am interested in having the USB gadget support on my board, so I
removed BROKEN on USB_MUSB_DA8XX. I found that when I modprobe
g_ether, g_serial, and g_mass_storage (by themselves), they all appear
to work as expected, but if I try to use g_multi to have a composite
device supporting all three simultaneously, I run into failure during
initialization.

Here is the USB related config:
# zcat /proc/config.gz |grep "^CONFIG_USB"
CONFIG_USB_HID=y
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_DEFAULT_PERSIST=y
CONFIG_USB_OTG=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_MUSB_DUAL_ROLE=y
CONFIG_USB_MUSB_DA8XX=y
CONFIG_USB_STORAGE=y
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_CONSOLE=y
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_FTDI_SIO=y
CONFIG_USB_SERIAL_PL2303=y
CONFIG_USB_PHY=y
CONFIG_USB_ULPI=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_DEBUG=y
CONFIG_USB_GADGET_DEBUG_FILES=y
CONFIG_USB_GADGET_DEBUG_FS=y
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
CONFIG_USB_LIBCOMPOSITE=m
CONFIG_USB_F_ACM=m
CONFIG_USB_U_SERIAL=m
CONFIG_USB_U_ETHER=m
CONFIG_USB_U_RNDIS=m
CONFIG_USB_F_SERIAL=m
CONFIG_USB_F_OBEX=m
CONFIG_USB_F_ECM=m
CONFIG_USB_F_SUBSET=m
CONFIG_USB_F_RNDIS=m
CONFIG_USB_ETH=m
CONFIG_USB_ETH_RNDIS=y
CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_G_MULTI=m
CONFIG_USB_G_MULTI_RNDIS=y

# modprobe g_multi file=/root/backing_file
modprobe: can't load module g_multi
(kernel/drivers/usb/gadget/g_multi.ko): Unknown error 524

I added a couple of debug message to identify where I was failing in:

diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index a01d7d3..3e7a22a 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -2899,14 +2899,18 @@ static int fsg_bind(struct usb_configuration
*c, struct usb_function *f)

/* Find all the endpoints we will use */
ep = usb_ep_autoconfig(gadget, _fs_bulk_in_desc);
-   if (!ep)
+   if (!ep) {
+   ERROR(fsg, "usb_ep_autoconfig in failed\n");
goto autoconf_fail;
+   }
ep->driver_data = fsg->common;  /* claim the endpoint */
fsg->bulk_in = ep;

ep = usb_ep_autoconfig(gadget, _fs_bulk_out_desc);
-   if (!ep)
+   if (!ep) {
+   ERROR(fsg, "usb_ep_autoconfig out failed\n");
goto autoconf_fail;
+   }
ep->driver_data = fsg->common;  /* claim the endpoint */
fsg->bulk_out = ep;

@@ -2929,8 +2933,10 @@ static int fsg_bind(struct usb_configuration
*c, struct usb_function *f)

ret = usb_assign_descriptors(f, fsg_fs_function, fsg_hs_function,
fsg_ss_function);
-   if (ret)
+   if (ret) {
+   ERROR(fsg, "usb_assign_descriptors failed\n");
goto autoconf_fail;
+   }

return 0;

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index c258a97..5172b00 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -67,7 +67,6 @@ config USB_MUSB_DAVINCI
 config USB_MUSB_DA8XX
tristate "DA8xx/OMAP-L1x"
depends on ARCH_DAVINCI_DA8XX
-   depends on BROKEN

 config USB_MUSB_TUSB6010
tristate "TUSB6010"

This is the kernel log I get from journalctl -f:

Jun 25 14:36:00 Ringle1 kernel: calling  multi_init+0x0/0xc [g_multi] @ 957
Jun 25 14:36:01 Ringle1 kernel: udc musb-hdrc.0.auto: registering UDC
driver [g_multi]
Jun 25 14:36:01 Ringle1 kernel: g_multi gadget: using random self
ethernet address
Jun 25 14:36:01 Ringle1 kernel: g_multi gadget: using random host
ethernet address
Jun 25 14:36:01 Ringle1 kernel: usb0: MAC 22:34:67:82:df:aa
Jun 25 14:36:01 Ringle1 kernel: usb0: HOST MAC 0e:a8:d1:26:29:37
Jun 25 14:36:01 Ringle1 kernel: calling  userial_init+0x0/0x180 [u_serial] @ 963
Jun 25 14:36:01 Ringle1 kernel: userial_init: registered 4 ttyGS* devices
Jun 25 14:36:01 Ringle1 kernel: initcall userial_init+0x0/0x180
[u_serial] returned 0 after 87 usecs
Jun 25 14:36:01 Ringle1 kernel: calling  acmmod_init+0x0/0xc [usb_f_acm] @ 963
Jun 25 14:36:01 Ringle1 kernel: initcall acmmod_init+0x0/0xc
[usb_f_acm] returned 0 after 10 usecs
Jun 25 14:36:01 Ringle1 kernel:  lun0: open backing file: /root/backing_file
Jun 25 14:36:01 Ringle1 kernel: g_multi gadget: Mass Storage Function,
version: 2009/09/11
Jun 25 14:36:01 Ringle1 kernel: g_multi gadget: Number of LUNs=1
Jun 25 14:36:01 Ringle1 kernel:  lun0: LUN: file: /root/backing_file
Jun 25 14:36:01 Ringle1 kernel: g_multi gadget: I/O thread pid: 969
Jun 25 14:36:01 Ringle1 kernel: g_multi gadget: adding 

USB_MUSB_DA8XX with g_multi.ko

[Jon Ringle]

In commit 787f5627bec80094db487bfcb401e9744f181aed
usb: musb: make davinci and da8xx glues depend on BROKEN

USB_MUSB_DA8XX was marked as BROKEN

A few months ago, we updated the linux kernel on our AM1808 SoC based
embedded board from Linux 2.6.33 to the latest long term 3.12.

I am interested in having the USB gadget support on my board, so I
removed BROKEN on USB_MUSB_DA8XX. I found that when I modprobe
g_ether, g_serial, and g_mass_storage (by themselves), they all appear
to work as expected, but if I try to use g_multi to have a composite
device supporting all three simultaneously, I run into failure during
initialization.

Here is the USB related config:
# zcat /proc/config.gz |grep ^CONFIG_USB
CONFIG_USB_HID=y
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_DEFAULT_PERSIST=y
CONFIG_USB_OTG=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_MUSB_DUAL_ROLE=y
CONFIG_USB_MUSB_DA8XX=y
CONFIG_USB_STORAGE=y
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_CONSOLE=y
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_FTDI_SIO=y
CONFIG_USB_SERIAL_PL2303=y
CONFIG_USB_PHY=y
CONFIG_USB_ULPI=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_DEBUG=y
CONFIG_USB_GADGET_DEBUG_FILES=y
CONFIG_USB_GADGET_DEBUG_FS=y
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
CONFIG_USB_LIBCOMPOSITE=m
CONFIG_USB_F_ACM=m
CONFIG_USB_U_SERIAL=m
CONFIG_USB_U_ETHER=m
CONFIG_USB_U_RNDIS=m
CONFIG_USB_F_SERIAL=m
CONFIG_USB_F_OBEX=m
CONFIG_USB_F_ECM=m
CONFIG_USB_F_SUBSET=m
CONFIG_USB_F_RNDIS=m
CONFIG_USB_ETH=m
CONFIG_USB_ETH_RNDIS=y
CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_G_MULTI=m
CONFIG_USB_G_MULTI_RNDIS=y

# modprobe g_multi file=/root/backing_file
modprobe: can't load module g_multi
(kernel/drivers/usb/gadget/g_multi.ko): Unknown error 524

I added a couple of debug message to identify where I was failing in:

diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index a01d7d3..3e7a22a 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -2899,14 +2899,18 @@ static int fsg_bind(struct usb_configuration
*c, struct usb_function *f)

/* Find all the endpoints we will use */
ep = usb_ep_autoconfig(gadget, fsg_fs_bulk_in_desc);
-   if (!ep)
+   if (!ep) {
+   ERROR(fsg, usb_ep_autoconfig in failed\n);
goto autoconf_fail;
+   }
ep-driver_data = fsg-common;  /* claim the endpoint */
fsg-bulk_in = ep;

ep = usb_ep_autoconfig(gadget, fsg_fs_bulk_out_desc);
-   if (!ep)
+   if (!ep) {
+   ERROR(fsg, usb_ep_autoconfig out failed\n);
goto autoconf_fail;
+   }
ep-driver_data = fsg-common;  /* claim the endpoint */
fsg-bulk_out = ep;

@@ -2929,8 +2933,10 @@ static int fsg_bind(struct usb_configuration
*c, struct usb_function *f)

ret = usb_assign_descriptors(f, fsg_fs_function, fsg_hs_function,
fsg_ss_function);
-   if (ret)
+   if (ret) {
+   ERROR(fsg, usb_assign_descriptors failed\n);
goto autoconf_fail;
+   }

return 0;

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index c258a97..5172b00 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -67,7 +67,6 @@ config USB_MUSB_DAVINCI
 config USB_MUSB_DA8XX
tristate DA8xx/OMAP-L1x
depends on ARCH_DAVINCI_DA8XX
-   depends on BROKEN

 config USB_MUSB_TUSB6010
tristate TUSB6010

This is the kernel log I get from journalctl -f:

Jun 25 14:36:00 Ringle1 kernel: calling  multi_init+0x0/0xc [g_multi] @ 957
Jun 25 14:36:01 Ringle1 kernel: udc musb-hdrc.0.auto: registering UDC
driver [g_multi]
Jun 25 14:36:01 Ringle1 kernel: g_multi gadget: using random self
ethernet address
Jun 25 14:36:01 Ringle1 kernel: g_multi gadget: using random host
ethernet address
Jun 25 14:36:01 Ringle1 kernel: usb0: MAC 22:34:67:82:df:aa
Jun 25 14:36:01 Ringle1 kernel: usb0: HOST MAC 0e:a8:d1:26:29:37
Jun 25 14:36:01 Ringle1 kernel: calling  userial_init+0x0/0x180 [u_serial] @ 963
Jun 25 14:36:01 Ringle1 kernel: userial_init: registered 4 ttyGS* devices
Jun 25 14:36:01 Ringle1 kernel: initcall userial_init+0x0/0x180
[u_serial] returned 0 after 87 usecs
Jun 25 14:36:01 Ringle1 kernel: calling  acmmod_init+0x0/0xc [usb_f_acm] @ 963
Jun 25 14:36:01 Ringle1 kernel: initcall acmmod_init+0x0/0xc
[usb_f_acm] returned 0 after 10 usecs
Jun 25 14:36:01 Ringle1 kernel:  lun0: open backing file: /root/backing_file
Jun 25 14:36:01 Ringle1 kernel: g_multi gadget: Mass Storage Function,
version: 2009/09/11
Jun 25 14:36:01 Ringle1 kernel: g_multi gadget: Number of LUNs=1
Jun 25 14:36:01 Ringle1 kernel:  lun0: LUN: file: /root/backing_file
Jun 25 14:36:01 Ringle1 kernel: g_multi gadget: I/O thread pid: 969
Jun 25 14:36:01 Ringle1 kernel: g_multi gadget: adding config #1

Re: USB_MUSB_DA8XX with g_multi.ko

[Jon Ringle]

On Wed, Jun 25, 2014 at 11:35 AM, Andrzej Pietrasiewicz
andrze...@samsung.com wrote:
 W dniu 25.06.2014 17:13, Jon Ringle pisze:

 In commit 787f5627bec80094db487bfcb401e9744f181aed
 usb: musb: make davinci and da8xx glues depend on BROKEN

 USB_MUSB_DA8XX was marked as BROKEN

 A few months ago, we updated the linux kernel on our AM1808 SoC based
 embedded board from Linux 2.6.33 to the latest long term 3.12.

 I am interested in having the USB gadget support on my board, so I
 removed BROKEN on USB_MUSB_DA8XX. I found that when I modprobe
 g_ether, g_serial, and g_mass_storage (by themselves), they all appear
 to work as expected, but if I try to use g_multi to have a composite
 device supporting all three simultaneously, I run into failure during
 initialization.


 snip



 From this I can see that it's failing on the following call in
 fsg_bind():

 ep = usb_ep_autoconfig(gadget, fsg_fs_bulk_in_desc);


 Just a random guess (I don't know your hardware): how many bulk,
 iso and interrupt endpoints does your hardware provide? Perhaps you
 just run out of endpoints?

Perhaps... From the documentation it appears that I can have 4
simultaneous RX/TX endpoints... Is this not enough?

34.1.2 Features
The USB has the following features:
• Operating as a host, it complies with the USB 2.0 standard for
high-speed (480 Mbps), full-speed
(12 Mbps), and low-speed (1.5 Mbps) operations with a peripheral
• Operating as a peripheral, it complies with the USB 2.0 standard for
high-speed (480 Mbps) and
full-speed (12 Mbps) operation with a host.
• Supports USB extensions for Session Request (SRP) and Host
Negotiation (HNP) – OTG
• Supports 4 simultaneous RX and TX endpoints, in addition to control
endpoint, more devices can be
supported by dynamically switching endpoints states
• Each endpoint (other than endpoint 0) can support all transfer types
(control, bulk, interrupt, and
isochronous)
• Includes a 4K endpoint FIFO RAM, and supports programmable FIFO sizes
• External 5V power supply for VBUS, when operating as host, enabled
directly by the USB controller
through a dedicated signal
• Includes a DMA controller that supports 4 TX and 4 RX DMA channels
• Includes four types of Communications Port Programming Interface
(CPPI) 4.1 DMA compliant transfer
modes, Transparent, Generic RNDIS, RNDIS, and Linux CDC mode of DMA
for accelerating RNDIS
type protocols using short packet termination over USB.
• DMA supports single data transfer size up to 4Mbytes
--
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/

Re: USB_MUSB_DA8XX with g_multi.ko

[Jon Ringle]

On Wed, Jun 25, 2014 at 11:52 AM, Jon Ringle j...@ringle.org wrote:
 On Wed, Jun 25, 2014 at 11:35 AM, Andrzej Pietrasiewicz
 andrze...@samsung.com wrote:
 W dniu 25.06.2014 17:13, Jon Ringle pisze:

 In commit 787f5627bec80094db487bfcb401e9744f181aed
 usb: musb: make davinci and da8xx glues depend on BROKEN

 USB_MUSB_DA8XX was marked as BROKEN

 A few months ago, we updated the linux kernel on our AM1808 SoC based
 embedded board from Linux 2.6.33 to the latest long term 3.12.

 I am interested in having the USB gadget support on my board, so I
 removed BROKEN on USB_MUSB_DA8XX. I found that when I modprobe
 g_ether, g_serial, and g_mass_storage (by themselves), they all appear
 to work as expected, but if I try to use g_multi to have a composite
 device supporting all three simultaneously, I run into failure during
 initialization.


 snip



 From this I can see that it's failing on the following call in
 fsg_bind():

 ep = usb_ep_autoconfig(gadget, fsg_fs_bulk_in_desc);


 Just a random guess (I don't know your hardware): how many bulk,
 iso and interrupt endpoints does your hardware provide? Perhaps you
 just run out of endpoints?

 Perhaps... From the documentation it appears that I can have 4
 simultaneous RX/TX endpoints... Is this not enough?

I now see that each function seems to require 2 endpoints, so with 4
endpoints available, I can only have two functions with this hardware.
I tested this successfully with g_adm_ms.ko having both serial and
mass storage working. The only thing I needed to do was to remove the
BROKEN dependency on USB_MUSB_DA8XX. Is there anything else I would
have to do besides just removing BROKEN to get this accepted back into
the kernel source tree?

Jon
--
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/

Re: [PATCH v7 1/2] serial: sc16is7xx

[Jon Ringle]

On Fri, Apr 25, 2014 at 1:40 PM, Alexander Shiyan  wrote:
> Fri, 25 Apr 2014 10:26:40 -0700 от Greg KH :
>> On Thu, Apr 24, 2014 at 08:56:06PM -0400, j...@ringle.org wrote:
>> > From: Jon Ringle 
>> >
>> > The SC16IS7xx is a slave I2C-bus/SPI interface to a single-channel
>> > high performance UART. The SC16IS7xx's internal register set is
>> > backward-compatible with the widely used and widely popular 16C450.
>> >
>> > The SC16IS7xx also provides additional advanced features such as
>> > auto hardware and software flow control, automatic RS-485 support, and
>> > software reset.
>> >
>> > Signed-off-by: Jon Ringle 
>> > ---
>> >  drivers/tty/serial/Kconfig   |9 +
>> >  drivers/tty/serial/Makefile  |1 +
>> >  drivers/tty/serial/sc16is7xx.c   | 1279 
>> > ++
>> >  include/uapi/linux/serial_core.h |3 +
>> >  4 files changed, 1292 insertions(+)
>> >  create mode 100644 drivers/tty/serial/sc16is7xx.c
>>
>> I get a few build warnings with this patch applied:
>>
>> drivers/tty/serial/sc16is7xx.c:1059:12: warning: ‘sc16is7xx_probe’ defined 
>> but not used [-Wunused-function]
>>  static int sc16is7xx_probe(struct device *dev,
>> ^
>> drivers/tty/serial/sc16is7xx.c:1175:12: warning: ‘sc16is7xx_remove’ defined 
>> but not used [-Wunused-function]
>>  static int sc16is7xx_remove(struct device *dev)
>> ^
>> drivers/tty/serial/sc16is7xx.c:1214:29: warning: ‘regcfg’ defined but not 
>> used [-Wunused-variable]
>>  static struct regmap_config regcfg = {
>>  ^
>>
>> Can you send a follow-on patch to fix them?
>
> Seems this just should contain: "depends on I2C" in the Kconfig.

I can add "depends on I2C" in Kconfig for now, but I'm just wondering
how would this be dealt with when sometime in the future this driver
supports either I2C or SPI? Can the "depends on" be conditional
somehow?

Jon
--
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/

Re: [PATCH v7 1/2] serial: sc16is7xx

[Jon Ringle]

On Fri, Apr 25, 2014 at 10:24 AM, Charles Coldwell  wrote:
> On Fri, 25 Apr 2014, Jon Ringle wrote:
>
>> On Fri, Apr 25, 2014 at 9:44 AM, Charles Coldwell  wrote:
>> > On Fri, 25 Apr 2014, Charles Coldwell wrote:
>> >
>> >> On Thu, 24 Apr 2014, j...@ringle.org wrote:
>> >>
>> >> > diff --git a/drivers/tty/serial/sc16is7xx.c 
>> >> > b/drivers/tty/serial/sc16is7xx.c
>> >>
>> >> Isn't this a lot of duplication?
>> >
>> > Actually, the whole thing seems like duplication to me.
>>
>> The fact that we need to reach over the SPI/I2C bus makes a big
>> difference in the way access is handled.
>>
>> To achieve acceptable throughput, it is necessary to use threaded irq
>> and also bulk i2c transfers for RX and TX using
>> regmap_raw_{read,write}() to optimize the use of the i2c bus.
>
> Fair enough, but the 8250 framework does allow you to insert your own
> irq service routine. "serial8250_default_handle_irq" is the default
> (unsurprisingly), but if the uart_port has a non-NULL "handle_irq"
> method it will be faithfully copied into the uart_8250_port
> "handle_irq" method in 8250_core.c:early_serial_setup.

However, serial8250_interrupt() which is where port->handle_irq() is
called is not a threaded irq.

>
>> This is not a good fit for 8250.
>
> If that's really true, then I would say it argues in favor of a
> revision of the 8250 code.  Certainly, this is not the last time that
> a 16550-compatible UART will appear on a non-PCI, non-ISA bus.

I have re-written this driver 4 times already to get to the version
that is being presented. I don't have the time or energy to undergo
yet another rewrite of this driver. If you'd like to take on this
task, be my guest. I'd be happy to test what you come up with on my
hardware.

Jon
--
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/

Re: [PATCH v7 1/2] serial: sc16is7xx

[Jon Ringle]

On Fri, Apr 25, 2014 at 9:35 AM, Alexander Shiyan  wrote:
> And it would be nice to have a small changelog,
> because it is unclear what has changed with version 6.

v7 was created at Greg's request to refresh the patch. The only
conflict that required code change was in serial_core.h changing
#define PORT_SC16IS7XX 107
to
#define PORT_SC16IS7XX 108

Jon
--
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/

Re: [PATCH v7 1/2] serial: sc16is7xx

[Jon Ringle]

On Fri, Apr 25, 2014 at 9:44 AM, Charles Coldwell  wrote:
> On Fri, 25 Apr 2014, Charles Coldwell wrote:
>
>> On Thu, 24 Apr 2014, j...@ringle.org wrote:
>>
>> > diff --git a/drivers/tty/serial/sc16is7xx.c 
>> > b/drivers/tty/serial/sc16is7xx.c
>> > new file mode 100644
>> > index 000..ed139f5
>> > --- /dev/null
>> > +++ b/drivers/tty/serial/sc16is7xx.c
>>
>> > +
>> > +/* SC16IS7XX register definitions */
>> > +#define SC16IS7XX_RHR_REG  (0x00) /* RX FIFO */
>> > +#define SC16IS7XX_THR_REG  (0x00) /* TX FIFO */
>> > +#define SC16IS7XX_IER_REG  (0x01) /* Interrupt enable */
>> > +#define SC16IS7XX_IIR_REG  (0x02) /* Interrupt Identification */
>> > +#define SC16IS7XX_FCR_REG  (0x02) /* FIFO control */
>> > +#define SC16IS7XX_LCR_REG  (0x03) /* Line Control */
>> > +#define SC16IS7XX_MCR_REG  (0x04) /* Modem Control */
>> > +#define SC16IS7XX_LSR_REG  (0x05) /* Line Status */
>> > +#define SC16IS7XX_MSR_REG  (0x06) /* Modem Status */
>> > +#define SC16IS7XX_SPR_REG  (0x07) /* Scratch Pad */
>>
>> Isn't this a lot of duplication?

I started off doing that, but got frustrated enough by
incompatibilities between the register bit definitions that I
abandoned that and decided to make the driver self contained regarding
the register and bit definitions. For example:

serial_reg.h defines:
#define UART_MCR_TCRTLR0x40 /* Access TCR/TLR (TI16C752, EFR[4]=1) */

but this is wrong for sc16is7xx. I need:

#define SC16IS7XX_MCR_TCRTLR_BIT(1 << 2) /* TCR/TLR register enable */

>
> Actually, the whole thing seems like duplication to me.  The SC16IS7X0
> parts are designed to be 16550-compatible (hence the duplication in the
> register map), and so I would vote for putting the driver into the
> drivers/tty/serial/8250 framework.  There's really not much difference
> between these parts and other 16550 parts except that they are reached
> over the SPI/I2C bus.

The fact that we need to reach over the SPI/I2C bus makes a big
difference in the way access is handled.

To achieve acceptable throughput, it is necessary to use threaded irq
and also bulk i2c transfers for RX and TX using
regmap_raw_{read,write}() to optimize the use of the i2c bus.

This is not a good fit for 8250.

Jon
--
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/

Re: [PATCH v7 1/2] serial: sc16is7xx

[Jon Ringle]

On Fri, Apr 25, 2014 at 9:44 AM, Charles Coldwell coldw...@gmail.com wrote:
 On Fri, 25 Apr 2014, Charles Coldwell wrote:

 On Thu, 24 Apr 2014, j...@ringle.org wrote:

  diff --git a/drivers/tty/serial/sc16is7xx.c 
  b/drivers/tty/serial/sc16is7xx.c
  new file mode 100644
  index 000..ed139f5
  --- /dev/null
  +++ b/drivers/tty/serial/sc16is7xx.c

  +
  +/* SC16IS7XX register definitions */
  +#define SC16IS7XX_RHR_REG  (0x00) /* RX FIFO */
  +#define SC16IS7XX_THR_REG  (0x00) /* TX FIFO */
  +#define SC16IS7XX_IER_REG  (0x01) /* Interrupt enable */
  +#define SC16IS7XX_IIR_REG  (0x02) /* Interrupt Identification */
  +#define SC16IS7XX_FCR_REG  (0x02) /* FIFO control */
  +#define SC16IS7XX_LCR_REG  (0x03) /* Line Control */
  +#define SC16IS7XX_MCR_REG  (0x04) /* Modem Control */
  +#define SC16IS7XX_LSR_REG  (0x05) /* Line Status */
  +#define SC16IS7XX_MSR_REG  (0x06) /* Modem Status */
  +#define SC16IS7XX_SPR_REG  (0x07) /* Scratch Pad */

 Isn't this a lot of duplication?

I started off doing that, but got frustrated enough by
incompatibilities between the register bit definitions that I
abandoned that and decided to make the driver self contained regarding
the register and bit definitions. For example:

serial_reg.h defines:
#define UART_MCR_TCRTLR0x40 /* Access TCR/TLR (TI16C752, EFR[4]=1) */

but this is wrong for sc16is7xx. I need:

#define SC16IS7XX_MCR_TCRTLR_BIT(1  2) /* TCR/TLR register enable */


 Actually, the whole thing seems like duplication to me.  The SC16IS7X0
 parts are designed to be 16550-compatible (hence the duplication in the
 register map), and so I would vote for putting the driver into the
 drivers/tty/serial/8250 framework.  There's really not much difference
 between these parts and other 16550 parts except that they are reached
 over the SPI/I2C bus.

The fact that we need to reach over the SPI/I2C bus makes a big
difference in the way access is handled.

To achieve acceptable throughput, it is necessary to use threaded irq
and also bulk i2c transfers for RX and TX using
regmap_raw_{read,write}() to optimize the use of the i2c bus.

This is not a good fit for 8250.

Jon
--
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/

Re: [PATCH v7 1/2] serial: sc16is7xx

[Jon Ringle]

On Fri, Apr 25, 2014 at 9:35 AM, Alexander Shiyan shc_w...@mail.ru wrote:
 And it would be nice to have a small changelog,
 because it is unclear what has changed with version 6.

v7 was created at Greg's request to refresh the patch. The only
conflict that required code change was in serial_core.h changing
#define PORT_SC16IS7XX 107
to
#define PORT_SC16IS7XX 108

Jon
--
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/

Re: [PATCH v7 1/2] serial: sc16is7xx

[Jon Ringle]

On Fri, Apr 25, 2014 at 10:24 AM, Charles Coldwell coldw...@gmail.com wrote:
 On Fri, 25 Apr 2014, Jon Ringle wrote:

 On Fri, Apr 25, 2014 at 9:44 AM, Charles Coldwell coldw...@gmail.com wrote:
  On Fri, 25 Apr 2014, Charles Coldwell wrote:
 
  On Thu, 24 Apr 2014, j...@ringle.org wrote:
 
   diff --git a/drivers/tty/serial/sc16is7xx.c 
   b/drivers/tty/serial/sc16is7xx.c
 
  Isn't this a lot of duplication?
 
  Actually, the whole thing seems like duplication to me.

 The fact that we need to reach over the SPI/I2C bus makes a big
 difference in the way access is handled.

 To achieve acceptable throughput, it is necessary to use threaded irq
 and also bulk i2c transfers for RX and TX using
 regmap_raw_{read,write}() to optimize the use of the i2c bus.

 Fair enough, but the 8250 framework does allow you to insert your own
 irq service routine. serial8250_default_handle_irq is the default
 (unsurprisingly), but if the uart_port has a non-NULL handle_irq
 method it will be faithfully copied into the uart_8250_port
 handle_irq method in 8250_core.c:early_serial_setup.

However, serial8250_interrupt() which is where port-handle_irq() is
called is not a threaded irq.


 This is not a good fit for 8250.

 If that's really true, then I would say it argues in favor of a
 revision of the 8250 code.  Certainly, this is not the last time that
 a 16550-compatible UART will appear on a non-PCI, non-ISA bus.

I have re-written this driver 4 times already to get to the version
that is being presented. I don't have the time or energy to undergo
yet another rewrite of this driver. If you'd like to take on this
task, be my guest. I'd be happy to test what you come up with on my
hardware.

Jon
--
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/

Re: [PATCH v7 1/2] serial: sc16is7xx

[Jon Ringle]

On Fri, Apr 25, 2014 at 1:40 PM, Alexander Shiyan shc_w...@mail.ru wrote:
 Fri, 25 Apr 2014 10:26:40 -0700 от Greg KH gre...@linuxfoundation.org:
 On Thu, Apr 24, 2014 at 08:56:06PM -0400, j...@ringle.org wrote:
  From: Jon Ringle jrin...@gridpoint.com
 
  The SC16IS7xx is a slave I2C-bus/SPI interface to a single-channel
  high performance UART. The SC16IS7xx's internal register set is
  backward-compatible with the widely used and widely popular 16C450.
 
  The SC16IS7xx also provides additional advanced features such as
  auto hardware and software flow control, automatic RS-485 support, and
  software reset.
 
  Signed-off-by: Jon Ringle jrin...@gridpoint.com
  ---
   drivers/tty/serial/Kconfig   |9 +
   drivers/tty/serial/Makefile  |1 +
   drivers/tty/serial/sc16is7xx.c   | 1279 
  ++
   include/uapi/linux/serial_core.h |3 +
   4 files changed, 1292 insertions(+)
   create mode 100644 drivers/tty/serial/sc16is7xx.c

 I get a few build warnings with this patch applied:

 drivers/tty/serial/sc16is7xx.c:1059:12: warning: ‘sc16is7xx_probe’ defined 
 but not used [-Wunused-function]
  static int sc16is7xx_probe(struct device *dev,
 ^
 drivers/tty/serial/sc16is7xx.c:1175:12: warning: ‘sc16is7xx_remove’ defined 
 but not used [-Wunused-function]
  static int sc16is7xx_remove(struct device *dev)
 ^
 drivers/tty/serial/sc16is7xx.c:1214:29: warning: ‘regcfg’ defined but not 
 used [-Wunused-variable]
  static struct regmap_config regcfg = {
  ^

 Can you send a follow-on patch to fix them?

 Seems this just should contain: depends on I2C in the Kconfig.

I can add depends on I2C in Kconfig for now, but I'm just wondering
how would this be dealt with when sometime in the future this driver
supports either I2C or SPI? Can the depends on be conditional
somehow?

Jon
--
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/

Re: [PATCH v5 1/2] serial: sc16is7xx

[Jon Ringle]

On Thu, Apr 3, 2014 at 11:23 AM,   wrote:
> From: Jon Ringle 
>
> The SC16IS7xx is a slave I2C-bus/SPI interface to a single-channel
> high performance UART. The SC16IS7xx's internal register set is
> backward-compatible with the widely used and widely popular 16C450.
>
> The SC16IS7xx also provides additional advanced features such as
> auto hardware and software flow control, automatic RS-485 support, and
> software reset.
>
> Signed-off-by: Jon Ringle 
> ---
>  drivers/tty/serial/Kconfig   |9 +
>  drivers/tty/serial/Makefile  |1 +
>  drivers/tty/serial/sc16is7xx.c   | 1302 
> ++
>  include/uapi/linux/serial_core.h |3 +
>  4 files changed, 1315 insertions(+)
>  create mode 100644 drivers/tty/serial/sc16is7xx.c
>
[snip]

> diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
> new file mode 100644
> index 000..20d96cc
> --- /dev/null
> +++ b/drivers/tty/serial/sc16is7xx.c
[snip]

> +static bool sc16is7xx_regmap_writeable(struct device *dev, unsigned int reg)
> +{
> +   switch (reg >> SC16IS7XX_REG_SHIFT) {
> +   case SC16IS7XX_THR_REG:
> +   case SC16IS7XX_IER_REG:
> +   case SC16IS7XX_FCR_REG:
> +   case SC16IS7XX_LCR_REG:
> +   case SC16IS7XX_MCR_REG:
> +   case SC16IS7XX_SPR_REG:
> +   case SC16IS7XX_IODIR_REG:
> +   case SC16IS7XX_IOSTATE_REG:
> +   case SC16IS7XX_IOINTENA_REG:
> +   case SC16IS7XX_IOCONTROL_REG:
> +   case SC16IS7XX_EFCR_REG:
> +   return true;
> +   default:
> +   break;
> +   }
> +
> +   return false;
> +}

Having the above regmap_writeable callback causes problem with the
bulk I2C write (via regmap_raw_write()) that is done in
sc16is7xx_handle_tx(). Removing this callback fixes the issue.


[snip]
> +static void sc16is7xx_handle_tx(struct uart_port *port)
> +{
> +   struct sc16is7xx_port *s = dev_get_drvdata(port->dev);
> +   struct circ_buf *xmit = >state->xmit;
> +   unsigned int txlen, to_send, i;
> +   u8 buf[port->fifosize];
> +
> +   if (unlikely(port->x_char)) {
> +   sc16is7xx_port_write(port, SC16IS7XX_THR_REG, port->x_char);
> +   port->icount.tx++;
> +   port->x_char = 0;
> +   return;
> +   }
> +
> +   if (uart_circ_empty(xmit) || uart_tx_stopped(port))
> +   return;
> +
> +   /* Get length of data pending in circular buffer */
> +   to_send = uart_circ_chars_pending(xmit);
> +   if (likely(to_send)) {
> +   /* Limit to size of TX FIFO */
> +   txlen = sc16is7xx_port_read(port, SC16IS7XX_TXLVL_REG);
> +   to_send = (to_send > txlen) ? txlen : to_send;
> +
> +   /* Add data to send */
> +   port->icount.tx += to_send;
> +
> +   /* Convert to linear buffer */
> +   for (i = 0; i < to_send; ++i) {
> +   buf[i] = xmit->buf[xmit->tail];
> +   xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
> +   }
> +   regcache_cache_bypass(s->regmap, true);
> +   regmap_raw_write(s->regmap, SC16IS7XX_THR_REG, buf, to_send);

This call fails with -EINVAL if to_send is > 20 because it assumes
that we are writing to consecutive registers rather than writing to a
single register over and over.

> +   regcache_cache_bypass(s->regmap, false);
> +   }
> +
> +   if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
> +   uart_write_wakeup(port);
> +}

[snip]

> +static struct regmap_config regcfg = {
> +   .reg_bits = 7,
> +   .pad_bits = 1,
> +   .val_bits = 8,
> +   .cache_type = REGCACHE_RBTREE,
> +   .writeable_reg = sc16is7xx_regmap_writeable,
Removing writeable_reg

New patch forthcoming that removes the regmap writeable_reg callback.
But, I also wonder if there is a way to keep it, but teach regcache
that regmap_raw_write/read() done necessariy increment the register
being written to or read from. Then I probably wouldn't have to do the
regcach_cache_bypass business I am doing either.

Jon
--
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/

Re: [PATCH v5 1/2] serial: sc16is7xx

[Jon Ringle]

On Thu, Apr 3, 2014 at 11:23 AM,  j...@ringle.org wrote:
 From: Jon Ringle jrin...@gridpoint.com

 The SC16IS7xx is a slave I2C-bus/SPI interface to a single-channel
 high performance UART. The SC16IS7xx's internal register set is
 backward-compatible with the widely used and widely popular 16C450.

 The SC16IS7xx also provides additional advanced features such as
 auto hardware and software flow control, automatic RS-485 support, and
 software reset.

 Signed-off-by: Jon Ringle jrin...@gridpoint.com
 ---
  drivers/tty/serial/Kconfig   |9 +
  drivers/tty/serial/Makefile  |1 +
  drivers/tty/serial/sc16is7xx.c   | 1302 
 ++
  include/uapi/linux/serial_core.h |3 +
  4 files changed, 1315 insertions(+)
  create mode 100644 drivers/tty/serial/sc16is7xx.c

[snip]

 diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
 new file mode 100644
 index 000..20d96cc
 --- /dev/null
 +++ b/drivers/tty/serial/sc16is7xx.c
[snip]

 +static bool sc16is7xx_regmap_writeable(struct device *dev, unsigned int reg)
 +{
 +   switch (reg  SC16IS7XX_REG_SHIFT) {
 +   case SC16IS7XX_THR_REG:
 +   case SC16IS7XX_IER_REG:
 +   case SC16IS7XX_FCR_REG:
 +   case SC16IS7XX_LCR_REG:
 +   case SC16IS7XX_MCR_REG:
 +   case SC16IS7XX_SPR_REG:
 +   case SC16IS7XX_IODIR_REG:
 +   case SC16IS7XX_IOSTATE_REG:
 +   case SC16IS7XX_IOINTENA_REG:
 +   case SC16IS7XX_IOCONTROL_REG:
 +   case SC16IS7XX_EFCR_REG:
 +   return true;
 +   default:
 +   break;
 +   }
 +
 +   return false;
 +}

Having the above regmap_writeable callback causes problem with the
bulk I2C write (via regmap_raw_write()) that is done in
sc16is7xx_handle_tx(). Removing this callback fixes the issue.


[snip]
 +static void sc16is7xx_handle_tx(struct uart_port *port)
 +{
 +   struct sc16is7xx_port *s = dev_get_drvdata(port-dev);
 +   struct circ_buf *xmit = port-state-xmit;
 +   unsigned int txlen, to_send, i;
 +   u8 buf[port-fifosize];
 +
 +   if (unlikely(port-x_char)) {
 +   sc16is7xx_port_write(port, SC16IS7XX_THR_REG, port-x_char);
 +   port-icount.tx++;
 +   port-x_char = 0;
 +   return;
 +   }
 +
 +   if (uart_circ_empty(xmit) || uart_tx_stopped(port))
 +   return;
 +
 +   /* Get length of data pending in circular buffer */
 +   to_send = uart_circ_chars_pending(xmit);
 +   if (likely(to_send)) {
 +   /* Limit to size of TX FIFO */
 +   txlen = sc16is7xx_port_read(port, SC16IS7XX_TXLVL_REG);
 +   to_send = (to_send  txlen) ? txlen : to_send;
 +
 +   /* Add data to send */
 +   port-icount.tx += to_send;
 +
 +   /* Convert to linear buffer */
 +   for (i = 0; i  to_send; ++i) {
 +   buf[i] = xmit-buf[xmit-tail];
 +   xmit-tail = (xmit-tail + 1)  (UART_XMIT_SIZE - 1);
 +   }
 +   regcache_cache_bypass(s-regmap, true);
 +   regmap_raw_write(s-regmap, SC16IS7XX_THR_REG, buf, to_send);

This call fails with -EINVAL if to_send is  20 because it assumes
that we are writing to consecutive registers rather than writing to a
single register over and over.

 +   regcache_cache_bypass(s-regmap, false);
 +   }
 +
 +   if (uart_circ_chars_pending(xmit)  WAKEUP_CHARS)
 +   uart_write_wakeup(port);
 +}

[snip]

 +static struct regmap_config regcfg = {
 +   .reg_bits = 7,
 +   .pad_bits = 1,
 +   .val_bits = 8,
 +   .cache_type = REGCACHE_RBTREE,
 +   .writeable_reg = sc16is7xx_regmap_writeable,
Removing writeable_reg

New patch forthcoming that removes the regmap writeable_reg callback.
But, I also wonder if there is a way to keep it, but teach regcache
that regmap_raw_write/read() done necessariy increment the register
being written to or read from. Then I probably wouldn't have to do the
regcach_cache_bypass business I am doing either.

Jon
--
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/

Re: [PATCH v2 1/2] video: da8xx-fb: Add support for Densitron 84-0023-001T

[Jon Ringle]

On Tue, Apr 1, 2014 at 8:33 AM,   wrote:
> From: Jon Ringle 
>
> Signed-off-by: Jon Ringle 
> ---
>  drivers/video/da8xx-fb.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index e030e17..d042624 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -243,6 +243,20 @@ static struct fb_videomode known_lcd_panels[] = {
> .sync   = FB_SYNC_HOR_HIGH_ACT | 
> FB_SYNC_VERT_HIGH_ACT,
> .flag   = 0,
> },
> +   [3] = {
> +   /* Densitron 84-0023-001T */
> +   .name   = "Densitron_LCD",

Crap. I'm sorry. I will resend again. with the correct patch with the
name Tomi suggested

Jon
--
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/

Re: [PATCH v2 1/2] video: da8xx-fb: Add support for Densitron 84-0023-001T

[Jon Ringle]

On Tue, Apr 1, 2014 at 8:33 AM,  j...@ringle.org wrote:
 From: Jon Ringle jrin...@gridpoint.com

 Signed-off-by: Jon Ringle jrin...@gridpoint.com
 ---
  drivers/video/da8xx-fb.c | 14 ++
  1 file changed, 14 insertions(+)

 diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
 index e030e17..d042624 100644
 --- a/drivers/video/da8xx-fb.c
 +++ b/drivers/video/da8xx-fb.c
 @@ -243,6 +243,20 @@ static struct fb_videomode known_lcd_panels[] = {
 .sync   = FB_SYNC_HOR_HIGH_ACT | 
 FB_SYNC_VERT_HIGH_ACT,
 .flag   = 0,
 },
 +   [3] = {
 +   /* Densitron 84-0023-001T */
 +   .name   = Densitron_LCD,

Crap. I'm sorry. I will resend again. with the correct patch with the
name Tomi suggested

Jon
--
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/

Re: [PATCH] video: da8xx-fb: Fix casting of info->pseudo_palette

[Jon Ringle]

I've not heard anything regarding this patch. I just want to make sure
it's not lost :)

Jon


On Wed, Mar 5, 2014 at 3:19 AM,   wrote:
> From: Jon Ringle 
>
> (Resending without corporate disclaimer in email footer)
>
> The casting to (u16 *) on info->pseudo_palette is wrong and causes the
> display to show a blue (garbage) vertical line on every other pixel column
>
> Signed-off-by: Jon Ringle 
> ---
>  drivers/video/da8xx-fb.c | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index d042624..83c43b2 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -678,15 +678,7 @@ static int fb_setcolreg(unsigned regno, unsigned red, 
> unsigned green,
> (green << info->var.green.offset) |
> (blue << info->var.blue.offset);
>
> -   switch (info->var.bits_per_pixel) {
> -   case 16:
> -   ((u16 *) (info->pseudo_palette))[regno] = v;
> -   break;
> -   case 24:
> -   case 32:
> -   ((u32 *) (info->pseudo_palette))[regno] = v;
> -   break;
> -   }
> +   ((u32 *) (info->pseudo_palette))[regno] = v;
> if (palette[0] != 0x4000) {
> update_hw = 1;
> palette[0] = 0x4000;
> --
> 1.8.5.4
>
--
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/

Re: [PATCH] video: da8xx-fb: Add support for Densitron 84-0023-001T

[Jon Ringle]

I've not heard anything regarding this patch. I just want to make sure
it's not lost :)

Jon


On Wed, Mar 5, 2014 at 1:05 PM,   wrote:
> From: Jon Ringle 
>
> Signed-off-by: Jon Ringle 
> ---
>  drivers/video/da8xx-fb.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index e7f5937..83c43b2 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -243,6 +243,20 @@ static struct fb_videomode known_lcd_panels[] = {
> .sync   = FB_SYNC_HOR_HIGH_ACT | 
> FB_SYNC_VERT_HIGH_ACT,
> .flag   = 0,
> },
> +   [3] = {
> +   /* Densitron 84-0023-001T */
> +   .name   = "Densitron_LCD",
> +   .xres   = 320,
> +   .yres   = 240,
> +   .pixclock   = KHZ2PICOS(6400),
> +   .left_margin= 0,
> +   .right_margin   = 0,
> +   .upper_margin   = 0,
> +   .lower_margin   = 0,
> +   .hsync_len  = 30,
> +   .vsync_len  = 3,
> +   .sync   = 0,
> +   },
>  };
>
>  static bool da8xx_fb_is_raster_enabled(void)
> --
> 1.8.5.4
>
--
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/

Re: [PATCH v3] touchscreen: tps6507x-ts: only poll while touch event is occurring

[Jon Ringle]

I've not heard anything regarding this patch. I just want to make sure
it doesn't get lost :)

Jon

On Wed, Mar 5, 2014 at 3:09 AM,   wrote:
> From: Jon Ringle 
>
> (Resending without corporate dislaimer in email footer)
>
> We only need to poll for touch events after an interrupt occurs due to the
> user touching the screen. We continue to poll until the user stops touching
> the screen
>
> Signed-off-by: Jon Ringle 
> ---
>  drivers/input/touchscreen/tps6507x-ts.c | 189 
> +---
>  include/linux/input/tps6507x-ts.h   |   1 +
>  include/linux/mfd/tps6507x.h|   1 +
>  3 files changed, 151 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/input/touchscreen/tps6507x-ts.c 
> b/drivers/input/touchscreen/tps6507x-ts.c
> index 94cde2c..c051419 100644
> --- a/drivers/input/touchscreen/tps6507x-ts.c
> +++ b/drivers/input/touchscreen/tps6507x-ts.c
> @@ -17,11 +17,14 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
>
>  #define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
>  #define TPS_DEFAULT_MIN_PRESSURE 0x30
> @@ -39,13 +42,17 @@ struct ts_event {
>  };
>
>  struct tps6507x_ts {
> +   struct input_dev*input_dev;
> struct device   *dev;
> -   struct input_polled_dev *poll_dev;
> struct tps6507x_dev *mfd;
> charphys[32];
> +   struct delayed_work work;
> struct ts_event tc;
> +   int irq;
> +   unsigned long   poll_period;/* ms */
> u16 min_pressure;
> boolpendown;
> +   int open_count;
>  };
>
>  static int tps6507x_read_u8(struct tps6507x_ts *tsc, u8 reg, u8 *data)
> @@ -155,13 +162,20 @@ static s32 tps6507x_adc_standby(struct tps6507x_ts *tsc)
> return ret;
>  }
>
> -static void tps6507x_ts_poll(struct input_polled_dev *poll_dev)
> +static void tps6507x_ts_handler(struct work_struct *work)
>  {
> -   struct tps6507x_ts *tsc = poll_dev->private;
> -   struct input_dev *input_dev = poll_dev->input;
> +   struct tps6507x_ts *tsc =  container_of(work, struct tps6507x_ts, 
> work.work);
> +   struct input_dev *input_dev = tsc->input_dev;
> bool pendown;
> +   int schd;
> +   int poll = 0;
> s32 ret;
>
> +   if (tsc->irq) {
> +   // Disable the touch interrupt
> +   tps6507x_write_u8(tsc, TPS6507X_REG_INT, 0);
> +   }
> +
> ret = tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_PRESSURE,
>   >tc.pressure);
> if (ret)
> @@ -178,10 +192,11 @@ static void tps6507x_ts_poll(struct input_polled_dev 
> *poll_dev)
> }
>
> if (pendown) {
> +   int report_pendown = 0;
>
> if (!tsc->pendown) {
> dev_dbg(tsc->dev, "DOWN\n");
> -   input_report_key(input_dev, BTN_TOUCH, 1);
> +   report_pendown = 1;
> } else
> dev_dbg(tsc->dev, "still down\n");
>
> @@ -195,15 +210,86 @@ static void tps6507x_ts_poll(struct input_polled_dev 
> *poll_dev)
> if (ret)
> goto done;
>
> -   input_report_abs(input_dev, ABS_X, tsc->tc.x);
> -   input_report_abs(input_dev, ABS_Y, tsc->tc.y);
> -   input_report_abs(input_dev, ABS_PRESSURE, tsc->tc.pressure);
> -   input_sync(input_dev);
> -   tsc->pendown = true;
> +   if (tsc->tc.x && tsc->tc.y) {
> +   if (report_pendown)
> +   input_report_key(input_dev, BTN_TOUCH, 1);
> +
> +   input_report_abs(input_dev, ABS_X, tsc->tc.x);
> +   input_report_abs(input_dev, ABS_Y, tsc->tc.y);
> +   input_report_abs(input_dev, ABS_PRESSURE, 
> tsc->tc.pressure);
> +   input_sync(input_dev);
> +   tsc->pendown = true;
> +   } else {
> +   dev_dbg(tsc->dev, "discarding bogus read x=%d, y=%d, 
> pressure=%d\n", tsc->tc.x, tsc->tc.y, tsc->tc.pressure);
> +   }
> +   poll = 1;
> }
>
>  done:
> tps6507x_adc_standby(tsc);
> +   if (tsc->irq && !poll) {
> +

Re: [PATCH v2 2/2] serial: sc16is7xx: Add bindings documentation for the SC16IS7XX UARTs

[Jon Ringle]

On Wed, Mar 26, 2014 at 5:08 AM, Mark Rutland  wrote:
> On Tue, Mar 25, 2014 at 06:19:24PM +, j...@ringle.org wrote:
>> +- interrupt-parent: The phandle for the interrupt controller that
>> +  services interrupts for this IC.
>> +- interrupts: Specifies the interrupt source of the parent interrupt
>> +  controller. The format of the interrupt specifier depends on the
>> +  parent interrupt controller.
>
> Just describe what the device-specific interrupt logically is, not what
> the interrupts property means in general.
>

Something like this ok?:

-interrupts: Should contain the UART interrupt

>> +- clocks: phandle to the IC source clock.
>
> Nit: clocks aren't just referred to with phandles; there's a clock
> specifier too.
>
> Either correct the type here or don't mention the type at all, given
> this is a common property.
>

I'm not sure what to do here. Many of the other
devicetree/bindings/serial/*.txt use phandle verbage and also the
devicetree/bindings/clock-bindings.txt documentation for clocks refers
the type as phandle too:

==Clock consumers==

Required properties:
clocks: List of phandle and clock specifier pairs, one pair
for each clock input to the device.  Note: if the
clock provider specifies '0' for #clock-cells, then
only the phandle portion of the pair will appear.

Is something like this ok?:

clocks: reference to the source clock

Jon
--
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/

Re: [PATCH v2 2/2] serial: sc16is7xx: Add bindings documentation for the SC16IS7XX UARTs

[Jon Ringle]

On Wed, Mar 26, 2014 at 5:08 AM, Mark Rutland mark.rutl...@arm.com wrote:
 On Tue, Mar 25, 2014 at 06:19:24PM +, j...@ringle.org wrote:
 +- interrupt-parent: The phandle for the interrupt controller that
 +  services interrupts for this IC.
 +- interrupts: Specifies the interrupt source of the parent interrupt
 +  controller. The format of the interrupt specifier depends on the
 +  parent interrupt controller.

 Just describe what the device-specific interrupt logically is, not what
 the interrupts property means in general.


Something like this ok?:

-interrupts: Should contain the UART interrupt

 +- clocks: phandle to the IC source clock.

 Nit: clocks aren't just referred to with phandles; there's a clock
 specifier too.

 Either correct the type here or don't mention the type at all, given
 this is a common property.


I'm not sure what to do here. Many of the other
devicetree/bindings/serial/*.txt use phandle verbage and also the
devicetree/bindings/clock-bindings.txt documentation for clocks refers
the type as phandle too:

==Clock consumers==

Required properties:
clocks: List of phandle and clock specifier pairs, one pair
for each clock input to the device.  Note: if the
clock provider specifies '0' for #clock-cells, then
only the phandle portion of the pair will appear.

Is something like this ok?:

clocks: reference to the source clock

Jon
--
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/

Re: [PATCH v3] touchscreen: tps6507x-ts: only poll while touch event is occurring

[Jon Ringle]

I've not heard anything regarding this patch. I just want to make sure
it doesn't get lost :)

Jon

On Wed, Mar 5, 2014 at 3:09 AM,  j...@ringle.org wrote:
 From: Jon Ringle jrin...@gridpoint.com

 (Resending without corporate dislaimer in email footer)

 We only need to poll for touch events after an interrupt occurs due to the
 user touching the screen. We continue to poll until the user stops touching
 the screen

 Signed-off-by: Jon Ringle jrin...@gridpoint.com
 ---
  drivers/input/touchscreen/tps6507x-ts.c | 189 
 +---
  include/linux/input/tps6507x-ts.h   |   1 +
  include/linux/mfd/tps6507x.h|   1 +
  3 files changed, 151 insertions(+), 40 deletions(-)

 diff --git a/drivers/input/touchscreen/tps6507x-ts.c 
 b/drivers/input/touchscreen/tps6507x-ts.c
 index 94cde2c..c051419 100644
 --- a/drivers/input/touchscreen/tps6507x-ts.c
 +++ b/drivers/input/touchscreen/tps6507x-ts.c
 @@ -17,11 +17,14 @@
  #include linux/workqueue.h
  #include linux/slab.h
  #include linux/input.h
 -#include linux/input-polldev.h
  #include linux/platform_device.h
  #include linux/mfd/tps6507x.h
  #include linux/input/tps6507x-ts.h
  #include linux/delay.h
 +#include linux/gpio.h
 +#include linux/i2c.h
 +#include linux/irq.h
 +#include linux/interrupt.h

  #define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
  #define TPS_DEFAULT_MIN_PRESSURE 0x30
 @@ -39,13 +42,17 @@ struct ts_event {
  };

  struct tps6507x_ts {
 +   struct input_dev*input_dev;
 struct device   *dev;
 -   struct input_polled_dev *poll_dev;
 struct tps6507x_dev *mfd;
 charphys[32];
 +   struct delayed_work work;
 struct ts_event tc;
 +   int irq;
 +   unsigned long   poll_period;/* ms */
 u16 min_pressure;
 boolpendown;
 +   int open_count;
  };

  static int tps6507x_read_u8(struct tps6507x_ts *tsc, u8 reg, u8 *data)
 @@ -155,13 +162,20 @@ static s32 tps6507x_adc_standby(struct tps6507x_ts *tsc)
 return ret;
  }

 -static void tps6507x_ts_poll(struct input_polled_dev *poll_dev)
 +static void tps6507x_ts_handler(struct work_struct *work)
  {
 -   struct tps6507x_ts *tsc = poll_dev-private;
 -   struct input_dev *input_dev = poll_dev-input;
 +   struct tps6507x_ts *tsc =  container_of(work, struct tps6507x_ts, 
 work.work);
 +   struct input_dev *input_dev = tsc-input_dev;
 bool pendown;
 +   int schd;
 +   int poll = 0;
 s32 ret;

 +   if (tsc-irq) {
 +   // Disable the touch interrupt
 +   tps6507x_write_u8(tsc, TPS6507X_REG_INT, 0);
 +   }
 +
 ret = tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_PRESSURE,
   tsc-tc.pressure);
 if (ret)
 @@ -178,10 +192,11 @@ static void tps6507x_ts_poll(struct input_polled_dev 
 *poll_dev)
 }

 if (pendown) {
 +   int report_pendown = 0;

 if (!tsc-pendown) {
 dev_dbg(tsc-dev, DOWN\n);
 -   input_report_key(input_dev, BTN_TOUCH, 1);
 +   report_pendown = 1;
 } else
 dev_dbg(tsc-dev, still down\n);

 @@ -195,15 +210,86 @@ static void tps6507x_ts_poll(struct input_polled_dev 
 *poll_dev)
 if (ret)
 goto done;

 -   input_report_abs(input_dev, ABS_X, tsc-tc.x);
 -   input_report_abs(input_dev, ABS_Y, tsc-tc.y);
 -   input_report_abs(input_dev, ABS_PRESSURE, tsc-tc.pressure);
 -   input_sync(input_dev);
 -   tsc-pendown = true;
 +   if (tsc-tc.x  tsc-tc.y) {
 +   if (report_pendown)
 +   input_report_key(input_dev, BTN_TOUCH, 1);
 +
 +   input_report_abs(input_dev, ABS_X, tsc-tc.x);
 +   input_report_abs(input_dev, ABS_Y, tsc-tc.y);
 +   input_report_abs(input_dev, ABS_PRESSURE, 
 tsc-tc.pressure);
 +   input_sync(input_dev);
 +   tsc-pendown = true;
 +   } else {
 +   dev_dbg(tsc-dev, discarding bogus read x=%d, y=%d, 
 pressure=%d\n, tsc-tc.x, tsc-tc.y, tsc-tc.pressure);
 +   }
 +   poll = 1;
 }

  done:
 tps6507x_adc_standby(tsc);
 +   if (tsc-irq  !poll) {
 +   // Re-enable the interrupt
 +   tps6507x_write_u8(tsc, TPS6507X_REG_INT, 
 TPS6507X_REG_MASK_TSC);
 +   } else {
 +   /* always poll if not using interrupts */
 +   schd = schedule_delayed_work(tsc-work,
 +
 msecs_to_jiffies(tsc-poll_period));
 +   }
 +}
 +
 +static irqreturn_t tps6507x_ts_irq(int irq, void * dev_id

Re: [PATCH] video: da8xx-fb: Add support for Densitron 84-0023-001T

[Jon Ringle]

I've not heard anything regarding this patch. I just want to make sure
it's not lost :)

Jon


On Wed, Mar 5, 2014 at 1:05 PM,  j...@ringle.org wrote:
 From: Jon Ringle jrin...@gridpoint.com

 Signed-off-by: Jon Ringle jrin...@gridpoint.com
 ---
  drivers/video/da8xx-fb.c | 14 ++
  1 file changed, 14 insertions(+)

 diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
 index e7f5937..83c43b2 100644
 --- a/drivers/video/da8xx-fb.c
 +++ b/drivers/video/da8xx-fb.c
 @@ -243,6 +243,20 @@ static struct fb_videomode known_lcd_panels[] = {
 .sync   = FB_SYNC_HOR_HIGH_ACT | 
 FB_SYNC_VERT_HIGH_ACT,
 .flag   = 0,
 },
 +   [3] = {
 +   /* Densitron 84-0023-001T */
 +   .name   = Densitron_LCD,
 +   .xres   = 320,
 +   .yres   = 240,
 +   .pixclock   = KHZ2PICOS(6400),
 +   .left_margin= 0,
 +   .right_margin   = 0,
 +   .upper_margin   = 0,
 +   .lower_margin   = 0,
 +   .hsync_len  = 30,
 +   .vsync_len  = 3,
 +   .sync   = 0,
 +   },
  };

  static bool da8xx_fb_is_raster_enabled(void)
 --
 1.8.5.4

--
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/

Re: [PATCH] video: da8xx-fb: Fix casting of info-pseudo_palette

[Jon Ringle]

I've not heard anything regarding this patch. I just want to make sure
it's not lost :)

Jon


On Wed, Mar 5, 2014 at 3:19 AM,  j...@ringle.org wrote:
 From: Jon Ringle jrin...@gridpoint.com

 (Resending without corporate disclaimer in email footer)

 The casting to (u16 *) on info-pseudo_palette is wrong and causes the
 display to show a blue (garbage) vertical line on every other pixel column

 Signed-off-by: Jon Ringle jrin...@gridpoint.com
 ---
  drivers/video/da8xx-fb.c | 10 +-
  1 file changed, 1 insertion(+), 9 deletions(-)

 diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
 index d042624..83c43b2 100644
 --- a/drivers/video/da8xx-fb.c
 +++ b/drivers/video/da8xx-fb.c
 @@ -678,15 +678,7 @@ static int fb_setcolreg(unsigned regno, unsigned red, 
 unsigned green,
 (green  info-var.green.offset) |
 (blue  info-var.blue.offset);

 -   switch (info-var.bits_per_pixel) {
 -   case 16:
 -   ((u16 *) (info-pseudo_palette))[regno] = v;
 -   break;
 -   case 24:
 -   case 32:
 -   ((u32 *) (info-pseudo_palette))[regno] = v;
 -   break;
 -   }
 +   ((u32 *) (info-pseudo_palette))[regno] = v;
 if (palette[0] != 0x4000) {
 update_hw = 1;
 palette[0] = 0x4000;
 --
 1.8.5.4

--
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/

Re: [PATCH v2] tty: serial: sc16is7xx

[Jon Ringle]

On Fri, Mar 21, 2014 at 4:26 AM, Heikki Krogerus
 wrote:
> Hi,
>
> On Thu, Mar 20, 2014 at 10:05:33AM -0400, j...@ringle.org wrote:
>> From: Jon Ringle 
>>
>> The SC16IS7xx is a slave I2C-bus/SPI interface to a single-channel
>> high performance UART. The SC16IS7xx's internal register set is
>> backward-compatible with the widely used and widely popular 16C450.
>
> So couldn't this be just a probe driver for 8250?

8250 UART has a MMIO-access, but this driver communicate through I2C
bus (and potentially SPI bus, if anyone cares to add that support,
which should be fairly easy to do). This is completely different
handling.

To achieve acceptable throughput, it is necessary to use threaded irq
and also bulk i2c transfers for RX and TX using
regmap_raw_{read,write}() to optimize the use of the i2c bus.

This is not a good fit for 8250.

>
>> +/* SC16IS7XX register definitions */
>> +#define SC16IS7XX_RHR_REG(0x00) /* RX FIFO */
>> +#define SC16IS7XX_THR_REG(0x00) /* TX FIFO */
>> +#define SC16IS7XX_IER_REG(0x01) /* Interrupt enable */
>> +#define SC16IS7XX_IIR_REG(0x02) /* Interrupt Identification */
>> +#define SC16IS7XX_FCR_REG(0x02) /* FIFO control */
>> +#define SC16IS7XX_LCR_REG(0x03) /* Line Control */
>> +#define SC16IS7XX_MCR_REG(0x04) /* Modem Control */
>> +#define SC16IS7XX_LSR_REG(0x05) /* Line Status */
>> +#define SC16IS7XX_MSR_REG(0x06) /* Modem Status */
>> +#define SC16IS7XX_SPR_REG(0x07) /* Scratch Pad */
>
> At least there should not be any need to redefine those register or
> their bits. Just include serial_reg.h.

I started off doing that, but got frustrated enough by
incompatibilities between the register bit definitions that I
abandoned that and decided to make the driver self contained regarding
the register and bit definitions. For example:

serial_reg.h defines:
#define UART_MCR_TCRTLR0x40 /* Access TCR/TLR (TI16C752, EFR[4]=1) */

but this is wrong for sc16is7xx. I need:
#define SC16IS7XX_MCR_TCRTLR_BIT(1 << 2) /* TCR/TLR register enable */

Jon
--
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/

Re: [PATCH v2] tty: serial: sc16is7xx

[Jon Ringle]

On Fri, Mar 21, 2014 at 4:26 AM, Heikki Krogerus
heikki.kroge...@linux.intel.com wrote:
 Hi,

 On Thu, Mar 20, 2014 at 10:05:33AM -0400, j...@ringle.org wrote:
 From: Jon Ringle jrin...@gridpoint.com

 The SC16IS7xx is a slave I2C-bus/SPI interface to a single-channel
 high performance UART. The SC16IS7xx's internal register set is
 backward-compatible with the widely used and widely popular 16C450.

 So couldn't this be just a probe driver for 8250?

8250 UART has a MMIO-access, but this driver communicate through I2C
bus (and potentially SPI bus, if anyone cares to add that support,
which should be fairly easy to do). This is completely different
handling.

To achieve acceptable throughput, it is necessary to use threaded irq
and also bulk i2c transfers for RX and TX using
regmap_raw_{read,write}() to optimize the use of the i2c bus.

This is not a good fit for 8250.


 +/* SC16IS7XX register definitions */
 +#define SC16IS7XX_RHR_REG(0x00) /* RX FIFO */
 +#define SC16IS7XX_THR_REG(0x00) /* TX FIFO */
 +#define SC16IS7XX_IER_REG(0x01) /* Interrupt enable */
 +#define SC16IS7XX_IIR_REG(0x02) /* Interrupt Identification */
 +#define SC16IS7XX_FCR_REG(0x02) /* FIFO control */
 +#define SC16IS7XX_LCR_REG(0x03) /* Line Control */
 +#define SC16IS7XX_MCR_REG(0x04) /* Modem Control */
 +#define SC16IS7XX_LSR_REG(0x05) /* Line Status */
 +#define SC16IS7XX_MSR_REG(0x06) /* Modem Status */
 +#define SC16IS7XX_SPR_REG(0x07) /* Scratch Pad */

 At least there should not be any need to redefine those register or
 their bits. Just include serial_reg.h.

I started off doing that, but got frustrated enough by
incompatibilities between the register bit definitions that I
abandoned that and decided to make the driver self contained regarding
the register and bit definitions. For example:

serial_reg.h defines:
#define UART_MCR_TCRTLR0x40 /* Access TCR/TLR (TI16C752, EFR[4]=1) */

but this is wrong for sc16is7xx. I need:
#define SC16IS7XX_MCR_TCRTLR_BIT(1  2) /* TCR/TLR register enable */

Jon
--
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/

Re: [PATCH] RFC: WIP: sc16is7xx [v0.4]

[Jon Ringle]

I left out some relevant functions (sc16is7xx_port_read(), 
sc16is7xx_port_write(), sc16is7xx_port_update()) in my previous email...

On Mon, 10 Mar 2014, Alexander Shiyan wrote:

> Понедельник, 10 марта 2014, 7:50 -04:00 от Jon Ringle :
> > 
> > On Mon, 10 Mar 2014, Alexander Shiyan wrote:
> I do not understand why you chose the sccnxp driver as a template.
> Use as a template max310x driver from linux-next branch.
> I'm sure it will be better.

I followed your advice on using max310x as a template. One thing that I'm 
struggling to get right is the regmap. The datasheet[1] specifies the 
register bits as follows:

Table 33. Register address byte (I2C)
Bit NameFunction
7   -   not used
6:3 A[3:0]  UART's internal register select
2:1 CH1,0   channel select: CH1 = 0, CH0 = 0
Other values are reserved and should not be used.
0   -   not used

So, I need to shift the register address by 3. Here is how I have defined 
the regmap stuff:

-->8 [relevant code] >8---
/* SC16IS7XX register definitions */
#define SC16IS7XX_RHR_REG   (0x00) /* RX FIFO */
#define SC16IS7XX_THR_REG   (0x00) /* TX FIFO */
#define SC16IS7XX_IER_REG   (0x01) /* Interrupt enable */
#define SC16IS7XX_IIR_REG   (0x02) /* Interrupt Ident */
#define SC16IS7XX_FCR_REG   (0x02) /* FIFO control */
#define SC16IS7XX_LCR_REG   (0x03) /* Line Control */
#define SC16IS7XX_MCR_REG   (0x04) /* Modem Control */
#define SC16IS7XX_LSR_REG   (0x05) /* Line Status */
#define SC16IS7XX_MSR_REG   (0x06) /* Modem Status */
#define SC16IS7XX_SPR_REG   (0x07) /* Scratch Pad */
#define SC16IS7XX_TXLVL_REG (0x08) /* TX FIFO level */
#define SC16IS7XX_RXLVL_REG (0x09) /* RX FIFO level */
#define SC16IS7XX_IODIR_REG (0x0a) /* I/O Dir (750/760) */
#define SC16IS7XX_IOSTATE_REG   (0x0b) /* I/O State (750/760) */
#define SC16IS7XX_IOINTENA_REG  (0x0c) /* I/O Int Enable (750/760) */
#define SC16IS7XX_IOCONTROL_REG (0x0e) /* I/O Control (750/760) */
#define SC16IS7XX_EFCR_REG  (0x0f) /* Extra Feature Control */

/* TX/Trigger Registers: Only if ((MCR[2] == 0) && (EFR[4] == 1)) */
#define SC16IS7XX_TCR_REG   (0x06) /* Transmit control */
#define SC16IS7XX_TLR_REG   (0x07) /* Trigger level */

/* Special Register set: Only if ((LCR[7] == 1) && (LCR != 0xBF)) */
#define SC16IS7XX_DLL_REG   (0x00) /* Divisor Latch Low */
#define SC16IS7XX_DLH_REG   (0x01) /* Divisor Latch High */

/* Enhanced Register set: Only if (LCR == 0xBF) */
#define SC16IS7XX_EFR_REG   (0x02) /* Enhanced Features */
#define SC16IS7XX_XON1_REG  (0x04) /* Xon1 word */
#define SC16IS7XX_XON2_REG  (0x05) /* Xon2 word */
#define SC16IS7XX_XOFF1_REG (0x06) /* Xoff1 word */
#define SC16IS7XX_XOFF2_REG (0x07) /* Xoff2 word */

#define SC16IS7XX_REG_SHIFT 3

static u8 sc16is7xx_port_read(struct uart_port *port, u8 reg)
{
struct sc16is7xx_port *s = dev_get_drvdata(port->dev);
unsigned int val = 0;

regmap_read(s->regmap, reg << SC16IS7XX_REG_SHIFT, );

return val;
}

static void sc16is7xx_port_write(struct uart_port *port, u8 reg, u8 val)
{
struct sc16is7xx_port *s = dev_get_drvdata(port->dev);

regmap_write(s->regmap, reg << SC16IS7XX_REG_SHIFT, val);
}

static void sc16is7xx_port_update(struct uart_port *port, u8 reg, u8 mask, u8 
val)
{
struct sc16is7xx_port *s = dev_get_drvdata(port->dev);

regmap_update_bits(s->regmap, reg << SC16IS7XX_REG_SHIFT, mask, val);
}

static bool sc16is7xx_reg_writeable(struct device *dev, unsigned int reg)
{
switch ((reg >> SC16IS7XX_REG_SHIFT) & 0xf) {
case SC16IS7XX_LSR_REG:
case SC16IS7XX_MSR_REG:
case SC16IS7XX_TXLVL_REG:
case SC16IS7XX_RXLVL_REG:
return false;
default:
break;
}

return true;
}

static bool sc16is7xx_reg_volatile(struct device *dev, unsigned int reg)
{
switch ((reg >> SC16IS7XX_REG_SHIFT) & 0xf) {
case SC16IS7XX_RHR_REG:
case SC16IS7XX_IIR_REG:
case SC16IS7XX_LSR_REG:
case SC16IS7XX_MSR_REG:
case SC16IS7XX_TXLVL_REG:
case SC16IS7XX_RXLVL_REG:
case SC16IS7XX_IOSTATE_REG:
return true;
default:
break;
}

return false;
}

static bool sc16is7xx_reg_precious(struct device *dev, unsigned int reg)
{
switch ((reg >> SC16IS7XX_REG_SHIFT) & 0xf) {
case SC16IS7XX_RHR_REG:
case SC16IS7XX_IIR_REG:
case SC16IS7XX_MSR_REG:
  

Re: [PATCH] RFC: WIP: sc16is7xx [v0.4]

[Jon Ringle]

On Mon, 10 Mar 2014, Alexander Shiyan wrote:

> Понедельник, 10 марта 2014, 7:50 -04:00 от Jon Ringle :
> > 
> > On Mon, 10 Mar 2014, Alexander Shiyan wrote:
> > 
> > > Понедельник, 10 марта 2014, 2:26 -04:00 от j...@ringle.org:
> > > > From: Jon Ringle 
> > > ...
> > > > +config SERIAL_SC16IS7XX
> > > > +   tristate "SC16IS7xx RS485 serial support"
> > > > + select SERIAL_CORE
> > > > + default n
> > > > + help
> > > > + This selects support for SC16IS7xx for use as a RS485 serial 
> > > > port
> > > 
> > > Documentation says:
> > > The SC16IS740/750/760 is a slave I²C-bus/SPI interface to a single-channel
> > > high performance UART.
> > > ...
> > > The SC16IS740/750/760 also provides additional advanced features such
> > > as auto hardware and software flow control, automatic RS-485 support...
> > > 
> > > So why do you position this chip as RS485 only? Automatic direction for
> > > RS485 is just a feature as an addition for standart UART.
> > 
> > You're right. This is just how we are using the chip in our board. Would a 
> > configuration flag in platform_data make sense to use the auto rs485 
> > direction?
> 
> You don't need a flag, just use IOCTLs.
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/tty/serial/max310x.c?id=55367c620aed6bc27a82bb1763366931d7f2ee66
> 
> > Any thoughts as to the latency issue I report?
> 
> I do not understand why you chose the sccnxp driver as a template.
> Use as a template max310x driver from linux-next branch.
> I'm sure it will be better.

I followed your advice on using max310x as a template. One thing that I'm 
struggling to get right is the regmap. The datasheet[1] specifies the 
register bits as follows:

Table 33. Register address byte (I2C)
Bit NameFunction
7   -   not used
6:3 A[3:0]  UART's internal register select
2:1 CH1,0   channel select: CH1 = 0, CH0 = 0
Other values are reserved and should not be used.
0   -   not used

So, I need to shift the register address by 3. Here is how I have defined 
the regmap stuff:

-->8 [relevant code] >8---
/* SC16IS7XX register definitions */
#define SC16IS7XX_RHR_REG   (0x00) /* RX FIFO */
#define SC16IS7XX_THR_REG   (0x00) /* TX FIFO */
#define SC16IS7XX_IER_REG   (0x01) /* Interrupt enable */
#define SC16IS7XX_IIR_REG   (0x02) /* Interrupt Ident */
#define SC16IS7XX_FCR_REG   (0x02) /* FIFO control */
#define SC16IS7XX_LCR_REG   (0x03) /* Line Control */
#define SC16IS7XX_MCR_REG   (0x04) /* Modem Control */
#define SC16IS7XX_LSR_REG   (0x05) /* Line Status */
#define SC16IS7XX_MSR_REG   (0x06) /* Modem Status */
#define SC16IS7XX_SPR_REG   (0x07) /* Scratch Pad */
#define SC16IS7XX_TXLVL_REG (0x08) /* TX FIFO level */
#define SC16IS7XX_RXLVL_REG (0x09) /* RX FIFO level */
#define SC16IS7XX_IODIR_REG (0x0a) /* I/O Dir (750/760) */
#define SC16IS7XX_IOSTATE_REG   (0x0b) /* I/O State (750/760) */
#define SC16IS7XX_IOINTENA_REG  (0x0c) /* I/O Int Enable (750/760) */
#define SC16IS7XX_IOCONTROL_REG (0x0e) /* I/O Control (750/760) */
#define SC16IS7XX_EFCR_REG  (0x0f) /* Extra Feature Control */

/* TX/Trigger Registers: Only if ((MCR[2] == 0) && (EFR[4] == 1)) */
#define SC16IS7XX_TCR_REG   (0x06) /* Transmit control */
#define SC16IS7XX_TLR_REG   (0x07) /* Trigger level */

/* Special Register set: Only if ((LCR[7] == 1) && (LCR != 0xBF)) */
#define SC16IS7XX_DLL_REG   (0x00) /* Divisor Latch Low */
#define SC16IS7XX_DLH_REG   (0x01) /* Divisor Latch High */

/* Enhanced Register set: Only if (LCR == 0xBF) */
#define SC16IS7XX_EFR_REG   (0x02) /* Enhanced Features */
#define SC16IS7XX_XON1_REG  (0x04) /* Xon1 word */
#define SC16IS7XX_XON2_REG  (0x05) /* Xon2 word */
#define SC16IS7XX_XOFF1_REG (0x06) /* Xoff1 word */
#define SC16IS7XX_XOFF2_REG (0x07) /* Xoff2 word */

#define SC16IS7XX_REG_SHIFT 3

static bool sc16is7xx_reg_writeable(struct device *dev, unsigned int reg)
{
switch ((reg >> SC16IS7XX_REG_SHIFT) & 0xf) {
case SC16IS7XX_LSR_REG:
case SC16IS7XX_MSR_REG:
case SC16IS7XX_TXLVL_REG:
case SC16IS7XX_RXLVL_REG:
return false;
default:
break;
}

return true;
}

static bool sc16is7xx_reg_volatile(str

Re: [PATCH] RFC: WIP: sc16is7xx [v0.4]

[Jon Ringle]

On Mon, 10 Mar 2014, Alexander Shiyan wrote:

 Понедельник, 10 марта 2014, 7:50 -04:00 от Jon Ringle j...@ringle.org:
  
  On Mon, 10 Mar 2014, Alexander Shiyan wrote:
  
   Понедельник, 10 марта 2014, 2:26 -04:00 от j...@ringle.org:
From: Jon Ringle jrin...@gridpoint.com
   ...
+config SERIAL_SC16IS7XX
+   tristate SC16IS7xx RS485 serial support
+ select SERIAL_CORE
+ default n
+ help
+ This selects support for SC16IS7xx for use as a RS485 serial 
port
   
   Documentation says:
   The SC16IS740/750/760 is a slave I²C-bus/SPI interface to a single-channel
   high performance UART.
   ...
   The SC16IS740/750/760 also provides additional advanced features such
   as auto hardware and software flow control, automatic RS-485 support...
   
   So why do you position this chip as RS485 only? Automatic direction for
   RS485 is just a feature as an addition for standart UART.
  
  You're right. This is just how we are using the chip in our board. Would a 
  configuration flag in platform_data make sense to use the auto rs485 
  direction?
 
 You don't need a flag, just use IOCTLs.
 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/tty/serial/max310x.c?id=55367c620aed6bc27a82bb1763366931d7f2ee66
 
  Any thoughts as to the latency issue I report?
 
 I do not understand why you chose the sccnxp driver as a template.
 Use as a template max310x driver from linux-next branch.
 I'm sure it will be better.

I followed your advice on using max310x as a template. One thing that I'm 
struggling to get right is the regmap. The datasheet[1] specifies the 
register bits as follows:

Table 33. Register address byte (I2C)
Bit NameFunction
7   -   not used
6:3 A[3:0]  UART's internal register select
2:1 CH1,0   channel select: CH1 = 0, CH0 = 0
Other values are reserved and should not be used.
0   -   not used

So, I need to shift the register address by 3. Here is how I have defined 
the regmap stuff:

--8 [relevant code] 8---
/* SC16IS7XX register definitions */
#define SC16IS7XX_RHR_REG   (0x00) /* RX FIFO */
#define SC16IS7XX_THR_REG   (0x00) /* TX FIFO */
#define SC16IS7XX_IER_REG   (0x01) /* Interrupt enable */
#define SC16IS7XX_IIR_REG   (0x02) /* Interrupt Ident */
#define SC16IS7XX_FCR_REG   (0x02) /* FIFO control */
#define SC16IS7XX_LCR_REG   (0x03) /* Line Control */
#define SC16IS7XX_MCR_REG   (0x04) /* Modem Control */
#define SC16IS7XX_LSR_REG   (0x05) /* Line Status */
#define SC16IS7XX_MSR_REG   (0x06) /* Modem Status */
#define SC16IS7XX_SPR_REG   (0x07) /* Scratch Pad */
#define SC16IS7XX_TXLVL_REG (0x08) /* TX FIFO level */
#define SC16IS7XX_RXLVL_REG (0x09) /* RX FIFO level */
#define SC16IS7XX_IODIR_REG (0x0a) /* I/O Dir (750/760) */
#define SC16IS7XX_IOSTATE_REG   (0x0b) /* I/O State (750/760) */
#define SC16IS7XX_IOINTENA_REG  (0x0c) /* I/O Int Enable (750/760) */
#define SC16IS7XX_IOCONTROL_REG (0x0e) /* I/O Control (750/760) */
#define SC16IS7XX_EFCR_REG  (0x0f) /* Extra Feature Control */

/* TX/Trigger Registers: Only if ((MCR[2] == 0)  (EFR[4] == 1)) */
#define SC16IS7XX_TCR_REG   (0x06) /* Transmit control */
#define SC16IS7XX_TLR_REG   (0x07) /* Trigger level */

/* Special Register set: Only if ((LCR[7] == 1)  (LCR != 0xBF)) */
#define SC16IS7XX_DLL_REG   (0x00) /* Divisor Latch Low */
#define SC16IS7XX_DLH_REG   (0x01) /* Divisor Latch High */

/* Enhanced Register set: Only if (LCR == 0xBF) */
#define SC16IS7XX_EFR_REG   (0x02) /* Enhanced Features */
#define SC16IS7XX_XON1_REG  (0x04) /* Xon1 word */
#define SC16IS7XX_XON2_REG  (0x05) /* Xon2 word */
#define SC16IS7XX_XOFF1_REG (0x06) /* Xoff1 word */
#define SC16IS7XX_XOFF2_REG (0x07) /* Xoff2 word */

#define SC16IS7XX_REG_SHIFT 3

static bool sc16is7xx_reg_writeable(struct device *dev, unsigned int reg)
{
switch ((reg  SC16IS7XX_REG_SHIFT)  0xf) {
case SC16IS7XX_LSR_REG:
case SC16IS7XX_MSR_REG:
case SC16IS7XX_TXLVL_REG:
case SC16IS7XX_RXLVL_REG:
return false;
default:
break;
}

return true;
}

static bool sc16is7xx_reg_volatile(struct device *dev, unsigned int reg)
{
switch ((reg  SC16IS7XX_REG_SHIFT)  0xf) {
case SC16IS7XX_RHR_REG:
case SC16IS7XX_IIR_REG:
case SC16IS7XX_LSR_REG:
case SC16IS7XX_MSR_REG:
case SC16IS7XX_TXLVL_REG:
case SC16IS7XX_RXLVL_REG:
case SC16IS7XX_IOSTATE_REG:
return true;
default:
break

Re: [PATCH] RFC: WIP: sc16is7xx [v0.4]

[Jon Ringle]

I left out some relevant functions (sc16is7xx_port_read(), 
sc16is7xx_port_write(), sc16is7xx_port_update()) in my previous email...

On Mon, 10 Mar 2014, Alexander Shiyan wrote:

 Понедельник, 10 марта 2014, 7:50 -04:00 от Jon Ringle j...@ringle.org:
  
  On Mon, 10 Mar 2014, Alexander Shiyan wrote:
 I do not understand why you chose the sccnxp driver as a template.
 Use as a template max310x driver from linux-next branch.
 I'm sure it will be better.

I followed your advice on using max310x as a template. One thing that I'm 
struggling to get right is the regmap. The datasheet[1] specifies the 
register bits as follows:

Table 33. Register address byte (I2C)
Bit NameFunction
7   -   not used
6:3 A[3:0]  UART's internal register select
2:1 CH1,0   channel select: CH1 = 0, CH0 = 0
Other values are reserved and should not be used.
0   -   not used

So, I need to shift the register address by 3. Here is how I have defined 
the regmap stuff:

--8 [relevant code] 8---
/* SC16IS7XX register definitions */
#define SC16IS7XX_RHR_REG   (0x00) /* RX FIFO */
#define SC16IS7XX_THR_REG   (0x00) /* TX FIFO */
#define SC16IS7XX_IER_REG   (0x01) /* Interrupt enable */
#define SC16IS7XX_IIR_REG   (0x02) /* Interrupt Ident */
#define SC16IS7XX_FCR_REG   (0x02) /* FIFO control */
#define SC16IS7XX_LCR_REG   (0x03) /* Line Control */
#define SC16IS7XX_MCR_REG   (0x04) /* Modem Control */
#define SC16IS7XX_LSR_REG   (0x05) /* Line Status */
#define SC16IS7XX_MSR_REG   (0x06) /* Modem Status */
#define SC16IS7XX_SPR_REG   (0x07) /* Scratch Pad */
#define SC16IS7XX_TXLVL_REG (0x08) /* TX FIFO level */
#define SC16IS7XX_RXLVL_REG (0x09) /* RX FIFO level */
#define SC16IS7XX_IODIR_REG (0x0a) /* I/O Dir (750/760) */
#define SC16IS7XX_IOSTATE_REG   (0x0b) /* I/O State (750/760) */
#define SC16IS7XX_IOINTENA_REG  (0x0c) /* I/O Int Enable (750/760) */
#define SC16IS7XX_IOCONTROL_REG (0x0e) /* I/O Control (750/760) */
#define SC16IS7XX_EFCR_REG  (0x0f) /* Extra Feature Control */

/* TX/Trigger Registers: Only if ((MCR[2] == 0)  (EFR[4] == 1)) */
#define SC16IS7XX_TCR_REG   (0x06) /* Transmit control */
#define SC16IS7XX_TLR_REG   (0x07) /* Trigger level */

/* Special Register set: Only if ((LCR[7] == 1)  (LCR != 0xBF)) */
#define SC16IS7XX_DLL_REG   (0x00) /* Divisor Latch Low */
#define SC16IS7XX_DLH_REG   (0x01) /* Divisor Latch High */

/* Enhanced Register set: Only if (LCR == 0xBF) */
#define SC16IS7XX_EFR_REG   (0x02) /* Enhanced Features */
#define SC16IS7XX_XON1_REG  (0x04) /* Xon1 word */
#define SC16IS7XX_XON2_REG  (0x05) /* Xon2 word */
#define SC16IS7XX_XOFF1_REG (0x06) /* Xoff1 word */
#define SC16IS7XX_XOFF2_REG (0x07) /* Xoff2 word */

#define SC16IS7XX_REG_SHIFT 3

static u8 sc16is7xx_port_read(struct uart_port *port, u8 reg)
{
struct sc16is7xx_port *s = dev_get_drvdata(port-dev);
unsigned int val = 0;

regmap_read(s-regmap, reg  SC16IS7XX_REG_SHIFT, val);

return val;
}

static void sc16is7xx_port_write(struct uart_port *port, u8 reg, u8 val)
{
struct sc16is7xx_port *s = dev_get_drvdata(port-dev);

regmap_write(s-regmap, reg  SC16IS7XX_REG_SHIFT, val);
}

static void sc16is7xx_port_update(struct uart_port *port, u8 reg, u8 mask, u8 
val)
{
struct sc16is7xx_port *s = dev_get_drvdata(port-dev);

regmap_update_bits(s-regmap, reg  SC16IS7XX_REG_SHIFT, mask, val);
}

static bool sc16is7xx_reg_writeable(struct device *dev, unsigned int reg)
{
switch ((reg  SC16IS7XX_REG_SHIFT)  0xf) {
case SC16IS7XX_LSR_REG:
case SC16IS7XX_MSR_REG:
case SC16IS7XX_TXLVL_REG:
case SC16IS7XX_RXLVL_REG:
return false;
default:
break;
}

return true;
}

static bool sc16is7xx_reg_volatile(struct device *dev, unsigned int reg)
{
switch ((reg  SC16IS7XX_REG_SHIFT)  0xf) {
case SC16IS7XX_RHR_REG:
case SC16IS7XX_IIR_REG:
case SC16IS7XX_LSR_REG:
case SC16IS7XX_MSR_REG:
case SC16IS7XX_TXLVL_REG:
case SC16IS7XX_RXLVL_REG:
case SC16IS7XX_IOSTATE_REG:
return true;
default:
break;
}

return false;
}

static bool sc16is7xx_reg_precious(struct device *dev, unsigned int reg)
{
switch ((reg  SC16IS7XX_REG_SHIFT)  0xf) {
case SC16IS7XX_RHR_REG:
case SC16IS7XX_IIR_REG:
case SC16IS7XX_MSR_REG:
return true;
default:
break;
}

return false;
}

static struct regmap_config regcfg

Re: [PATCH] RFC: WIP: sc16is7xx [v0.4]

[Jon Ringle]

On Mon, 10 Mar 2014, Alexander Shiyan wrote:

> Понедельник, 10 марта 2014, 2:26 -04:00 от j...@ringle.org:
> > From: Jon Ringle 
> ...
> > +config SERIAL_SC16IS7XX
> > +   tristate "SC16IS7xx RS485 serial support"
> > + select SERIAL_CORE
> > + default n
> > + help
> > + This selects support for SC16IS7xx for use as a RS485 serial port
> 
> Documentation says:
> The SC16IS740/750/760 is a slave I²C-bus/SPI interface to a single-channel
> high performance UART.
> ...
> The SC16IS740/750/760 also provides additional advanced features such
> as auto hardware and software flow control, automatic RS-485 support...
> 
> So why do you position this chip as RS485 only? Automatic direction for
> RS485 is just a feature as an addition for standart UART.

You're right. This is just how we are using the chip in our board. Would a 
configuration flag in platform_data make sense to use the auto rs485 
direction?

Any thoughts as to the latency issue I report?

Thanks.

Regards,
Jon

Re: [PATCH] RFC: WIP: sc16is7xx [v0.4]

[Jon Ringle]

On Mon, 10 Mar 2014, Alexander Shiyan wrote:

 Понедельник, 10 марта 2014, 2:26 -04:00 от j...@ringle.org:
  From: Jon Ringle jrin...@gridpoint.com
 ...
  +config SERIAL_SC16IS7XX
  +   tristate SC16IS7xx RS485 serial support
  + select SERIAL_CORE
  + default n
  + help
  + This selects support for SC16IS7xx for use as a RS485 serial port
 
 Documentation says:
 The SC16IS740/750/760 is a slave I²C-bus/SPI interface to a single-channel
 high performance UART.
 ...
 The SC16IS740/750/760 also provides additional advanced features such
 as auto hardware and software flow control, automatic RS-485 support...
 
 So why do you position this chip as RS485 only? Automatic direction for
 RS485 is just a feature as an addition for standart UART.

You're right. This is just how we are using the chip in our board. Would a 
configuration flag in platform_data make sense to use the auto rs485 
direction?

Any thoughts as to the latency issue I report?

Thanks.

Regards,
Jon

Re: [PATCH] Add option to build with -O3

[Jon Ringle]

On Wed, 5 Mar 2014, Greg KH wrote:

> On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote:
> > +config CC_OPTIMIZE_FOR_SPEED
> > +bool "Optimze for speed (-O3)"
> > +help
> > +  Enabling this option will pass "-O3" to gcc
> > +  resulting in a larger kernel (but possibly faster)
> 
> Are you sure about that?  Have you measured it?

(Resending this message, since it was "destroyed". Hopefully, this is now 
an an acceptable form :)

I do know that there is an improvement performance-wise for my particular 
use-case.

My target is an ARM board being built with gcc-4.8.2. My board has on it a 
sc16is740 that is used as an RS-485 port. The sc16is740 is on the i2c bus, 
so when an interrupt comes in to indicate that there is data available to 
be read, I need to get the data over the i2c bus. I do this on a kthread 
to do this work. The i2c transactions (using i2c-davinci driver) are also 
interrupt driven. I was seeing a lot of lost packets when receiving data 
at only 19200. Adding the -O3 compile option helped in this regard in that 
I am now rarely seeing packet loss.

Jon
 
--
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/

Re: [PATCH] Add option to build with -O3

[Jon Ringle]

On Wed, 5 Mar 2014, Greg KH wrote:

> On Wed, Mar 05, 2014 at 12:37:56AM -0500, Jon Ringle wrote:
> > The information contained in this transmission may contain confidential 
> > information.  If the reader of this message is not the intended recipient, 
> > you are hereby notified that any review, dissemination, distribution or 
> > duplication of this communication is strictly prohibited.  If you are not 
> > the intended recipient, please contact the sender by reply email and 
> > destroy all copies of the original message.
>
> Because of this footer, I must destroy this message, kernel development
> is not confidental.
>

Obviously, this is a footer that is not added by me, but rather the mail
server I am sending this message through. Besides, the footer indates it
"may contain confidential information". The key word being *may*. Of
course kernel development is never confidential and the content of any
transmission done to the lkml is of public record. You and anyone who
cares to read/comment this message on lkml is indeed the inteded
recipient, therefore there is no need to destroy this message :)

I sure hope your response was just in jest :)

Jon

The information contained in this transmission may contain confidential 
information.  If the reader of this message is not the intended recipient, you 
are hereby notified that any review, dissemination, distribution or duplication 
of this communication is strictly prohibited.  If you are not the intended 
recipient, please contact the sender by reply email and destroy all copies of 
the original message.
--
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/

Re: [PATCH] Add option to build with -O3

[Jon Ringle]

On Wed, 5 Mar 2014, Greg KH wrote:

> On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote:
> > +config CC_OPTIMIZE_FOR_SPEED
> > +bool "Optimze for speed (-O3)"
> > +help
> > +  Enabling this option will pass "-O3" to gcc
> > +  resulting in a larger kernel (but possibly faster)
>
> Are you sure about that?  Have you measured it?

I do know that there is an improvement performance-wise for my particular
use-case.

My target is an ARM board being built with gcc-4.8.2. My board has on it a
sc16is740 that is used as an RS-485 port. The sc16is740 is on the i2c bus,
so when an interrupt comes in to indicate that there is data available to
be read, I need to get the data over the i2c bus. I do this on a kthread
to do this work. The i2c transactions (using i2c-davinci driver) are also
interrupt driven. I was seeing a lot of lost packets when receiving data
at only 19200. Adding the -O3 compile option helped in this regard in that
I am now rarely seeing packet loss.

Jon

The information contained in this transmission may contain confidential 
information.  If the reader of this message is not the intended recipient, you 
are hereby notified that any review, dissemination, distribution or duplication 
of this communication is strictly prohibited.  If you are not the intended 
recipient, please contact the sender by reply email and destroy all copies of 
the original message.
--
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/

[PATCH] Add option to build with -O3

[Jon Ringle]

Signed-off-by: Jon Ringle 
---
 Makefile |  2 ++
 init/Kconfig | 19 ---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 78209ee..e7f0b3c 100644
--- a/Makefile
+++ b/Makefile
@@ -581,6 +581,8 @@ all: vmlinux

 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
 KBUILD_CFLAGS  += -Os $(call cc-disable-warning,maybe-uninitialized,)
+else ifdef CONFIG_CC_OPTIMIZE_FOR_SPEED
+KBUILD_CFLAGS   += -O3
 else
 KBUILD_CFLAGS  += -O2
 endif
diff --git a/init/Kconfig b/init/Kconfig
index 009a797..17d4c62 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1233,13 +1233,26 @@ source "usr/Kconfig"

 endif

+choice
+prompt "Optimize"
+
+config CC_OPTIMIZE_NORMAL
+bool "Optimize Normal (-O2)"
+help
+  Enabling this option will pass "-O2" to gcc
 config CC_OPTIMIZE_FOR_SIZE
-   bool "Optimize for size"
+   bool "Optimize for size (-Os)"
help
- Enabling this option will pass "-Os" instead of "-O2" to gcc
+ Enabling this option will pass "-Os" to gcc
  resulting in a smaller kernel.

- If unsure, say N.
+config CC_OPTIMIZE_FOR_SPEED
+bool "Optimze for speed (-O3)"
+help
+  Enabling this option will pass "-O3" to gcc
+  resulting in a larger kernel (but possibly faster)
+
+endchoice

 config SYSCTL
bool
--
1.8.5.4


The information contained in this transmission may contain confidential 
information.  If the reader of this message is not the intended recipient, you 
are hereby notified that any review, dissemination, distribution or duplication 
of this communication is strictly prohibited.  If you are not the intended 
recipient, please contact the sender by reply email and destroy all copies of 
the original message.
--
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/

[PATCH v2] touchscreen: tps6507x-ts: only poll while touch event is occurring

[Jon Ringle]

We only need to poll for touch events after an interrupt occurs due to the
user touching the screen. We continue to poll until the user stops touching
the screen

Signed-off-by: Jon Ringle 
---
 drivers/input/touchscreen/tps6507x-ts.c | 188 +---
 include/linux/input/tps6507x-ts.h   |   1 +
 include/linux/mfd/tps6507x.h|   1 +
 3 files changed, 151 insertions(+), 39 deletions(-)

diff --git a/drivers/input/touchscreen/tps6507x-ts.c 
b/drivers/input/touchscreen/tps6507x-ts.c
index 94cde2c..24043ff 100644
--- a/drivers/input/touchscreen/tps6507x-ts.c
+++ b/drivers/input/touchscreen/tps6507x-ts.c
@@ -17,11 +17,14 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 

 #define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
 #define TPS_DEFAULT_MIN_PRESSURE 0x30
@@ -39,13 +42,17 @@ struct ts_event {
 };

 struct tps6507x_ts {
+   struct input_dev*input_dev;
struct device   *dev;
-   struct input_polled_dev *poll_dev;
struct tps6507x_dev *mfd;
charphys[32];
+   struct delayed_work work;
struct ts_event tc;
+   int irq;
+   unsigned long   poll_period;/* ms */
u16 min_pressure;
boolpendown;
+   int open_count;
 };

 static int tps6507x_read_u8(struct tps6507x_ts *tsc, u8 reg, u8 *data)
@@ -155,13 +162,20 @@ static s32 tps6507x_adc_standby(struct tps6507x_ts *tsc)
return ret;
 }

-static void tps6507x_ts_poll(struct input_polled_dev *poll_dev)
+static void tps6507x_ts_handler(struct work_struct *work)
 {
-   struct tps6507x_ts *tsc = poll_dev->private;
-   struct input_dev *input_dev = poll_dev->input;
+   struct tps6507x_ts *tsc =  container_of(work, struct tps6507x_ts, 
work.work);
+   struct input_dev *input_dev = tsc->input_dev;
bool pendown;
+   int schd;
+   int poll = 0;
s32 ret;

+   if (tsc->irq) {
+   // Disable the touch interrupt
+   tps6507x_write_u8(tsc, TPS6507X_REG_INT, 0);
+   }
+
ret = tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_PRESSURE,
  >tc.pressure);
if (ret)
@@ -178,9 +192,11 @@ static void tps6507x_ts_poll(struct input_polled_dev 
*poll_dev)
}

if (pendown) {
+   int report_pendown = 0;

if (!tsc->pendown) {
dev_dbg(tsc->dev, "DOWN\n");
+   report_pendown = 1;
input_report_key(input_dev, BTN_TOUCH, 1);
} else
dev_dbg(tsc->dev, "still down\n");
@@ -195,15 +211,86 @@ static void tps6507x_ts_poll(struct input_polled_dev 
*poll_dev)
if (ret)
goto done;

-   input_report_abs(input_dev, ABS_X, tsc->tc.x);
-   input_report_abs(input_dev, ABS_Y, tsc->tc.y);
-   input_report_abs(input_dev, ABS_PRESSURE, tsc->tc.pressure);
-   input_sync(input_dev);
-   tsc->pendown = true;
+   if (tsc->tc.x && tsc->tc.y) {
+   if (report_pendown)
+   input_report_key(input_dev, BTN_TOUCH, 1);
+
+   input_report_abs(input_dev, ABS_X, tsc->tc.x);
+   input_report_abs(input_dev, ABS_Y, tsc->tc.y);
+   input_report_abs(input_dev, ABS_PRESSURE, 
tsc->tc.pressure);
+   input_sync(input_dev);
+   tsc->pendown = true;
+   } else {
+   dev_dbg(tsc->dev, "discarding bogus read x=%d, y=%d, 
pressure=%d\n", tsc->tc.x, tsc->tc.y, tsc->tc.pressure);
+   }
+   poll = 1;
}

 done:
tps6507x_adc_standby(tsc);
+   if (tsc->irq && !poll) {
+   // Re-enable the interrupt
+   tps6507x_write_u8(tsc, TPS6507X_REG_INT, TPS6507X_REG_MASK_TSC);
+   } else {
+   /* always poll if not using interrupts */
+   schd = schedule_delayed_work(>work,
+
msecs_to_jiffies(tsc->poll_period));
+   }
+}
+
+static irqreturn_t tps6507x_ts_irq(int irq, void * dev_id)
+{
+   struct tps6507x_ts * tsc = (struct tps6507x_ts *)dev_id;
+
+   schedule_delayed_work(>work, 0);
+
+   return IRQ_HANDLED;
+}
+
+static int tps6507x_ts_open(struct input_dev *input_dev)
+{
+   int ret;
+   struct tps6507x_ts *tsc = input_get_drvdata(input_dev);
+
+   tsc->open_count++;
+
+   if (tsc->irq) {
+
+   tps6507x_write_u8(tsc, TPS6507X_REG_INT, 0);
+   tps6507

[PATCH] touchscreen: tps6507x-ts: only poll while touch event is occurring

[Jon Ringle]

We only need to poll for touch events after an interrupt occurs due to the
user touching the screen. We continue to poll until the user stops touching
the screen

Signed-off-by: Jon Ringle 
---
 drivers/input/touchscreen/tps6507x-ts.c | 191 +---
 include/linux/mfd/tps6507x.h|   1 +
 2 files changed, 153 insertions(+), 39 deletions(-)

diff --git a/drivers/input/touchscreen/tps6507x-ts.c 
b/drivers/input/touchscreen/tps6507x-ts.c
index 94cde2c..fa1fb24 100644
--- a/drivers/input/touchscreen/tps6507x-ts.c
+++ b/drivers/input/touchscreen/tps6507x-ts.c
@@ -17,11 +17,14 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 

 #define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
 #define TPS_DEFAULT_MIN_PRESSURE 0x30
@@ -39,13 +42,17 @@ struct ts_event {
 };

 struct tps6507x_ts {
+   struct input_dev*input_dev;
struct device   *dev;
-   struct input_polled_dev *poll_dev;
struct tps6507x_dev *mfd;
charphys[32];
+   struct delayed_work work;
struct ts_event tc;
+   int irq;
+   unsigned long   poll_period;/* ms */
u16 min_pressure;
boolpendown;
+   int open_count;
 };

 static int tps6507x_read_u8(struct tps6507x_ts *tsc, u8 reg, u8 *data)
@@ -155,13 +162,20 @@ static s32 tps6507x_adc_standby(struct tps6507x_ts *tsc)
return ret;
 }

-static void tps6507x_ts_poll(struct input_polled_dev *poll_dev)
+static void tps6507x_ts_handler(struct work_struct *work)
 {
-   struct tps6507x_ts *tsc = poll_dev->private;
-   struct input_dev *input_dev = poll_dev->input;
+   struct tps6507x_ts *tsc =  container_of(work, struct tps6507x_ts, 
work.work);
+   struct input_dev *input_dev = tsc->input_dev;
bool pendown;
+   int schd;
+   int poll = 0;
s32 ret;

+   if (tsc->irq) {
+   // Disable the touch interrupt
+   tps6507x_write_u8(tsc, TPS6507X_REG_INT, 0);
+   }
+
ret = tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_PRESSURE,
  >tc.pressure);
if (ret)
@@ -178,9 +192,11 @@ static void tps6507x_ts_poll(struct input_polled_dev 
*poll_dev)
}

if (pendown) {
+   int report_pendown = 0;

if (!tsc->pendown) {
dev_dbg(tsc->dev, "DOWN\n");
+   report_pendown = 1;
input_report_key(input_dev, BTN_TOUCH, 1);
} else
dev_dbg(tsc->dev, "still down\n");
@@ -195,15 +211,89 @@ static void tps6507x_ts_poll(struct input_polled_dev 
*poll_dev)
if (ret)
goto done;

-   input_report_abs(input_dev, ABS_X, tsc->tc.x);
-   input_report_abs(input_dev, ABS_Y, tsc->tc.y);
-   input_report_abs(input_dev, ABS_PRESSURE, tsc->tc.pressure);
-   input_sync(input_dev);
-   tsc->pendown = true;
+   if (tsc->tc.x && tsc->tc.y) {
+   if (report_pendown)
+   input_report_key(input_dev, BTN_TOUCH, 1);
+
+   input_report_abs(input_dev, ABS_X, tsc->tc.x);
+   input_report_abs(input_dev, ABS_Y, tsc->tc.y);
+   input_report_abs(input_dev, ABS_PRESSURE, 
tsc->tc.pressure);
+   input_sync(input_dev);
+   tsc->pendown = true;
+   } else {
+   dev_dbg(tsc->dev, "discarding bogus read x=%d, y=%d, 
pressure=%d\n", tsc->tc.x, tsc->tc.y, tsc->tc.pressure);
+   }
+   poll = 1;
}

 done:
tps6507x_adc_standby(tsc);
+   if (tsc->irq && !poll) {
+   // Re-enable the interrupt
+   tps6507x_write_u8(tsc, TPS6507X_REG_INT, TPS6507X_REG_MASK_TSC);
+   } else {
+   /* always poll if not using interrupts */
+   schd = schedule_delayed_work(>work,
+
msecs_to_jiffies(tsc->poll_period));
+   }
+}
+
+static irqreturn_t tps6507x_ts_irq(int irq, void * dev_id)
+{
+   struct tps6507x_ts * tsc = (struct tps6507x_ts *)dev_id;
+
+   schedule_delayed_work(>work, 0);
+
+   return IRQ_HANDLED;
+}
+
+static int tps6507x_ts_open(struct input_dev *input_dev)
+{
+   int ret;
+   struct tps6507x_ts *tsc = input_get_drvdata(input_dev);
+
+   tsc->open_count++;
+
+// printk("%s: %s\n", __func__, comm);
+   dump_stack();
+
+   if (tsc->irq) {
+
+   tps6507x_write_u8(tsc, TPS6

Re: Fwd: Ethernet controller not starting

[Jon Ringle]

On Tue, Mar 4, 2014 at 9:06 AM, Christian Riesch
 wrote:
> Hi Jon,
>
> [Now also cc'ed Prabhakar Lad]
>
>
> --On March 04, 2014 07:34 -0500 Jon Ringle  wrote:
>
>> On Tue, Mar 4, 2014 at 4:06 AM, Christian Riesch
>>  wrote:
>>>
>>> [cc'ed netdev and davinci-linux-open-source]
>>>
>>>
>>> --On March 03, 2014 19:39 -0500 Jon Ringle  wrote:
>>>
>>>> On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki 
>>>> wrote:
>>>>>
>>>>>
>>>>> On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote:
>>>>>>
>>>>>>
>>>>>> I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now
>>>>>> the latest LTS kernel).
>>>>>> I found that Ethernet controller on the board no longer comes up on
>>>>>> linux-3.12. I was able to bisect the issue I'm having to the following
>>>>>> commit:
>>>>>>
>>>>>> >   45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit
>>>>>> >   commit 45f0a85c8258741d11bda25c0a5669c06267204a
>>>>>> >   Author: Rafael J. Wysocki 
>>>>>> >   Date:   Mon Jun 3 21:49:52 2013 +0200
>>>>>> >
>
> [...]
>
>>>>>>
>>>>>> Can anyone offer any suggestions on what I should be looking for to
>>>>>> fix this on my board?
>>>>>
>>>>>
>>>>>
>>>>> Any pointers to the driver in question?
>>>>
>>>>
>>>>
>>>> drivers/net/ethernet/ti/davinci_emac.c
>>>>
>>>
>>> Hi Jon,
>>> I have successfully used the davinci_emac driver on a custom board with
>>> an AM1808 SoC with Kernel 3.13 a few weeks ago. So at least 3.13 should
>>> work. Did you try more recent kernel versions than 3.12?
>>
>>
>> I have not tried 3.13, but will do so today. Could I get a copy of
>> your .config for comparison purposes?
>>
>
> I would like to apologize, apparently my testing with 3.13 was quite bad.
> Ethernet comes up on my board and works fine after booting, but I can easily
> reproduce your problem by just doing ifconfig eth0 down /ifconfig eth0 up
> (which should call emac_dev_stop/emac_dev_open).
>
> # ifconfig eth0 up
> genirq: Flags mismatch irq 33. .
>
> So probably one of your start scripts (or dhcp or similar) does some
> ifconfig down/up, which then fails.
>
> I had a look at the code again, emac_dev_open requests the interrupts,
> whereas emac_dev_stop does not free them. If emac_dev_open is then called
> again by ifconfig eth0 up, it tries to request the interrupts again,
> resulting in the error above.
>
> I think the problem is a regression caused by
>
> Commit  6892b41d9701283085b655c6086fb57a5d63fa47
> net: davinci: emac: Convert to devm_* api
> Signed-off-by: Lad, Prabhakar 
>
> This patch replaces request_irq() by devm_request_irq() in emac_dev_open and
> removes free_irq() from emac_dev_stop. But since emac_dev_open is called
> every time we do an ifconfig eth0 up, it tries to request the interrupts
> again and again and again (and fails).
>
> So I guess the correct solution would be to move the calls of
> devm_request_irq() to davinci_emac_probe(). I will send a patch to netdev,
> it solves the problem on my board.

The posted patch also resolves the issue on my board. Thanks!

Jon
--
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/

Fwd: Ethernet controller not starting

[Jon Ringle]

On Tue, Mar 4, 2014 at 4:06 AM, Christian Riesch
 wrote:
> [cc'ed netdev and davinci-linux-open-source]
>
>
> --On March 03, 2014 19:39 -0500 Jon Ringle  wrote:
>
>> On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki 
>> wrote:
>>>
>>> On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote:
>>>>
>>>> I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now
>>>> the latest LTS kernel).
>>>> I found that Ethernet controller on the board no longer comes up on
>>>> linux-3.12. I was able to bisect the issue I'm having to the following
>>>> commit:
>>>>
>>>> >   45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit
>>>> >   commit 45f0a85c8258741d11bda25c0a5669c06267204a
>>>> >   Author: Rafael J. Wysocki 
>>>> >   Date:   Mon Jun 3 21:49:52 2013 +0200
>>>> >
>>>> >   PM / Runtime: Rework the "runtime idle" helper routine
>>>> >
>>>> >   The "runtime idle" helper routine, rpm_idle(), currently ignores
>>>> >   return values from .runtime_idle() callbacks executed by it.
>>>> >   However, it turns out that many subsystems use
>>>> >   pm_generic_runtime_idle() which checks the return value of the
>>>> >   driver's callback and executes pm_runtime_suspend() for the
>>>> >   device unless that value is not 0.  If that logic is moved to
>>>> >   rpm_idle() instead, pm_generic_runtime_idle() can be dropped
>>>> >   and its users will not need any .runtime_idle() callbacks any
>>>> >   more.
>>>> >
>>>> >   Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
>>>> >   routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
>>>> >   ata_port_runtime_idle(), respectively, as well as a few drivers'
>>>> >   ones may be simplified if rpm_idle() calls rpm_suspend() after
>>>> >   0 has been returned by the .runtime_idle() callback executed by
>>>> >   it.
>>>> >
>>>> >   To reduce overall code bloat, make the changes described above.
>>>> >
>>>> >   Tested-by: Mika Westerberg 
>>>> >   Tested-by: Kevin Hilman 
>>>> >   Signed-off-by: Rafael J. Wysocki 
>>>> >   Acked-by: Kevin Hilman 
>>>> >   Reviewed-by: Ulf Hansson 
>>>> >   Acked-by: Alan Stern 
>>>>
>>>> Can anyone offer any suggestions on what I should be looking for to
>>>> fix this on my board?
>>>
>>>
>>> Any pointers to the driver in question?
>>
>>
>> drivers/net/ethernet/ti/davinci_emac.c
>>
>
> Hi Jon,
> I have successfully used the davinci_emac driver on a custom board with an
> AM1808 SoC with Kernel 3.13 a few weeks ago. So at least 3.13 should work.
> Did you try more recent kernel versions than 3.12?

I have not tried 3.13, but will do so today. Could I get a copy of
your .config for comparison purposes?

>
>
>> I also get the following output:
>>
>>  Starting Network Manager Wait Online...
>> [   30.946509] davinci_mdio davinci_mdio.0: resetting idled controller
>> [   30.953220] net net0: attached PHY driver [Generic PHY]
>> (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1)
>> [   30.962938] IPv6: ADDRCONF(NETDEV_UP): net0: link is not ready
>> [   31.082087] genirq: Flags mismatch irq 33.  (net0) vs.
>>  (net0)
>
>
> Is it correct that this warning can only appear in case of shared
> interrupts? See kernel/irq/manage.c. Since we don't use shared interrupts
> here: Are you sure your board configuration is correct with regard to emac
> interrupts?

I added some additional printk's and see that emac_dev_open() seems to
get called again
and it is trying to call devm_request_irq() again for irq resources
(33-36) and fails when trying to get irq 33:

 Starting Network Manager Wait Online...
[   30.687505] emac_dev_open: trying to get irq 33
[   30.692314] emac_dev_open: got irq 33
[   30.696034] emac_dev_open: trying to get irq 34
[   30.700750] emac_dev_open: got irq 34
[   30.704469] emac_dev_open: trying to get irq 35
[   30.709088] emac_dev_open: got irq 35
[   30.712887] emac_dev_open: trying to get irq 36
[   30.717542] emac_dev_open: got irq 36
[   30.721507] davinci_mdio davinci_mdio.0: resetting idled controller
[   30.728909] net net0: attached PHY driver [Generic PHY]
(mii_bus:phy_addr=

Fwd: Ethernet controller not starting

[Jon Ringle]

On Tue, Mar 4, 2014 at 4:06 AM, Christian Riesch
christian.rie...@omicron.at wrote:
 [cc'ed netdev and davinci-linux-open-source]


 --On March 03, 2014 19:39 -0500 Jon Ringle j...@ringle.org wrote:

 On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki r...@rjwysocki.net
 wrote:

 On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote:

 I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now
 the latest LTS kernel).
 I found that Ethernet controller on the board no longer comes up on
 linux-3.12. I was able to bisect the issue I'm having to the following
 commit:

45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit
commit 45f0a85c8258741d11bda25c0a5669c06267204a
Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
Date:   Mon Jun 3 21:49:52 2013 +0200
 
PM / Runtime: Rework the runtime idle helper routine
 
The runtime idle helper routine, rpm_idle(), currently ignores
return values from .runtime_idle() callbacks executed by it.
However, it turns out that many subsystems use
pm_generic_runtime_idle() which checks the return value of the
driver's callback and executes pm_runtime_suspend() for the
device unless that value is not 0.  If that logic is moved to
rpm_idle() instead, pm_generic_runtime_idle() can be dropped
and its users will not need any .runtime_idle() callbacks any
more.
 
Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
ata_port_runtime_idle(), respectively, as well as a few drivers'
ones may be simplified if rpm_idle() calls rpm_suspend() after
0 has been returned by the .runtime_idle() callback executed by
it.
 
To reduce overall code bloat, make the changes described above.
 
Tested-by: Mika Westerberg mika.westerb...@linux.intel.com
Tested-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
Acked-by: Kevin Hilman khil...@linaro.org
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Alan Stern st...@rowland.harvard.edu

 Can anyone offer any suggestions on what I should be looking for to
 fix this on my board?


 Any pointers to the driver in question?


 drivers/net/ethernet/ti/davinci_emac.c


 Hi Jon,
 I have successfully used the davinci_emac driver on a custom board with an
 AM1808 SoC with Kernel 3.13 a few weeks ago. So at least 3.13 should work.
 Did you try more recent kernel versions than 3.12?

I have not tried 3.13, but will do so today. Could I get a copy of
your .config for comparison purposes?



 I also get the following output:

  Starting Network Manager Wait Online...
 [   30.946509] davinci_mdio davinci_mdio.0: resetting idled controller
 [   30.953220] net net0: attached PHY driver [Generic PHY]
 (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1)
 [   30.962938] IPv6: ADDRCONF(NETDEV_UP): net0: link is not ready
 [   31.082087] genirq: Flags mismatch irq 33.  (net0) vs.
  (net0)


 Is it correct that this warning can only appear in case of shared
 interrupts? See kernel/irq/manage.c. Since we don't use shared interrupts
 here: Are you sure your board configuration is correct with regard to emac
 interrupts?

I added some additional printk's and see that emac_dev_open() seems to
get called again
and it is trying to call devm_request_irq() again for irq resources
(33-36) and fails when trying to get irq 33:

 Starting Network Manager Wait Online...
[   30.687505] emac_dev_open: trying to get irq 33
[   30.692314] emac_dev_open: got irq 33
[   30.696034] emac_dev_open: trying to get irq 34
[   30.700750] emac_dev_open: got irq 34
[   30.704469] emac_dev_open: trying to get irq 35
[   30.709088] emac_dev_open: got irq 35
[   30.712887] emac_dev_open: trying to get irq 36
[   30.717542] emac_dev_open: got irq 36
[   30.721507] davinci_mdio davinci_mdio.0: resetting idled controller
[   30.728909] net net0: attached PHY driver [Generic PHY]
(mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1)
[   30.738614] IPv6: ADDRCONF(NETDEV_UP): net0: link is not ready
[   30.847040] emac_dev_open: trying to get irq 33
[   30.851809] genirq: Flags mismatch irq 33.  (net0) vs.
 (net0)
[   30.859125] CPU: 0 PID: 677 Comm: NetworkManager Not tainted
3.12.13-fs1-003-g5ae24fe-dirty+ #1234
[   30.868261] [c000d9c4] (unwind_backtrace+0x0/0x128) from
[c000be14] (show_stack+0x10/0x14)
[   30.877020] [c000be14] (show_stack+0x10/0x14) from [c0046970]
(__setup_irq+0x45c/0x4d4)
[   30.885499] [c0046970] (__setup_irq+0x45c/0x4d4) from
[c0046b18] (request_threaded_irq+0xa4/0x130)
[   30.894935] [c0046b18] (request_threaded_irq+0xa4/0x130) from
[c00484e0] (devm_request_threaded_irq+0x50/0x98)
[   30.905414] [c00484e0] (devm_request_threaded_irq+0x50/0x98) from
[c02db4b4] (emac_dev_open+0x3f4/0x4b8)
[   30.915364] [c02db4b4

Re: Fwd: Ethernet controller not starting

[Jon Ringle]

On Tue, Mar 4, 2014 at 9:06 AM, Christian Riesch
christian.rie...@omicron.at wrote:
 Hi Jon,

 [Now also cc'ed Prabhakar Lad]


 --On March 04, 2014 07:34 -0500 Jon Ringle j...@ringle.org wrote:

 On Tue, Mar 4, 2014 at 4:06 AM, Christian Riesch
 christian.rie...@omicron.at wrote:

 [cc'ed netdev and davinci-linux-open-source]


 --On March 03, 2014 19:39 -0500 Jon Ringle j...@ringle.org wrote:

 On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki r...@rjwysocki.net
 wrote:


 On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote:


 I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now
 the latest LTS kernel).
 I found that Ethernet controller on the board no longer comes up on
 linux-3.12. I was able to bisect the issue I'm having to the following
 commit:

45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit
commit 45f0a85c8258741d11bda25c0a5669c06267204a
Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
Date:   Mon Jun 3 21:49:52 2013 +0200
 

 [...]


 Can anyone offer any suggestions on what I should be looking for to
 fix this on my board?



 Any pointers to the driver in question?



 drivers/net/ethernet/ti/davinci_emac.c


 Hi Jon,
 I have successfully used the davinci_emac driver on a custom board with
 an AM1808 SoC with Kernel 3.13 a few weeks ago. So at least 3.13 should
 work. Did you try more recent kernel versions than 3.12?


 I have not tried 3.13, but will do so today. Could I get a copy of
 your .config for comparison purposes?


 I would like to apologize, apparently my testing with 3.13 was quite bad.
 Ethernet comes up on my board and works fine after booting, but I can easily
 reproduce your problem by just doing ifconfig eth0 down /ifconfig eth0 up
 (which should call emac_dev_stop/emac_dev_open).

 # ifconfig eth0 up
 genirq: Flags mismatch irq 33. .

 So probably one of your start scripts (or dhcp or similar) does some
 ifconfig down/up, which then fails.

 I had a look at the code again, emac_dev_open requests the interrupts,
 whereas emac_dev_stop does not free them. If emac_dev_open is then called
 again by ifconfig eth0 up, it tries to request the interrupts again,
 resulting in the error above.

 I think the problem is a regression caused by

 Commit  6892b41d9701283085b655c6086fb57a5d63fa47
 net: davinci: emac: Convert to devm_* api
 Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com

 This patch replaces request_irq() by devm_request_irq() in emac_dev_open and
 removes free_irq() from emac_dev_stop. But since emac_dev_open is called
 every time we do an ifconfig eth0 up, it tries to request the interrupts
 again and again and again (and fails).

 So I guess the correct solution would be to move the calls of
 devm_request_irq() to davinci_emac_probe(). I will send a patch to netdev,
 it solves the problem on my board.

The posted patch also resolves the issue on my board. Thanks!

Jon
--
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/

[PATCH] touchscreen: tps6507x-ts: only poll while touch event is occurring

[Jon Ringle]

We only need to poll for touch events after an interrupt occurs due to the
user touching the screen. We continue to poll until the user stops touching
the screen

Signed-off-by: Jon Ringle jrin...@gridpoint.com
---
 drivers/input/touchscreen/tps6507x-ts.c | 191 +---
 include/linux/mfd/tps6507x.h|   1 +
 2 files changed, 153 insertions(+), 39 deletions(-)

diff --git a/drivers/input/touchscreen/tps6507x-ts.c 
b/drivers/input/touchscreen/tps6507x-ts.c
index 94cde2c..fa1fb24 100644
--- a/drivers/input/touchscreen/tps6507x-ts.c
+++ b/drivers/input/touchscreen/tps6507x-ts.c
@@ -17,11 +17,14 @@
 #include linux/workqueue.h
 #include linux/slab.h
 #include linux/input.h
-#include linux/input-polldev.h
 #include linux/platform_device.h
 #include linux/mfd/tps6507x.h
 #include linux/input/tps6507x-ts.h
 #include linux/delay.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/irq.h
+#include linux/interrupt.h

 #define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
 #define TPS_DEFAULT_MIN_PRESSURE 0x30
@@ -39,13 +42,17 @@ struct ts_event {
 };

 struct tps6507x_ts {
+   struct input_dev*input_dev;
struct device   *dev;
-   struct input_polled_dev *poll_dev;
struct tps6507x_dev *mfd;
charphys[32];
+   struct delayed_work work;
struct ts_event tc;
+   int irq;
+   unsigned long   poll_period;/* ms */
u16 min_pressure;
boolpendown;
+   int open_count;
 };

 static int tps6507x_read_u8(struct tps6507x_ts *tsc, u8 reg, u8 *data)
@@ -155,13 +162,20 @@ static s32 tps6507x_adc_standby(struct tps6507x_ts *tsc)
return ret;
 }

-static void tps6507x_ts_poll(struct input_polled_dev *poll_dev)
+static void tps6507x_ts_handler(struct work_struct *work)
 {
-   struct tps6507x_ts *tsc = poll_dev-private;
-   struct input_dev *input_dev = poll_dev-input;
+   struct tps6507x_ts *tsc =  container_of(work, struct tps6507x_ts, 
work.work);
+   struct input_dev *input_dev = tsc-input_dev;
bool pendown;
+   int schd;
+   int poll = 0;
s32 ret;

+   if (tsc-irq) {
+   // Disable the touch interrupt
+   tps6507x_write_u8(tsc, TPS6507X_REG_INT, 0);
+   }
+
ret = tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_PRESSURE,
  tsc-tc.pressure);
if (ret)
@@ -178,9 +192,11 @@ static void tps6507x_ts_poll(struct input_polled_dev 
*poll_dev)
}

if (pendown) {
+   int report_pendown = 0;

if (!tsc-pendown) {
dev_dbg(tsc-dev, DOWN\n);
+   report_pendown = 1;
input_report_key(input_dev, BTN_TOUCH, 1);
} else
dev_dbg(tsc-dev, still down\n);
@@ -195,15 +211,89 @@ static void tps6507x_ts_poll(struct input_polled_dev 
*poll_dev)
if (ret)
goto done;

-   input_report_abs(input_dev, ABS_X, tsc-tc.x);
-   input_report_abs(input_dev, ABS_Y, tsc-tc.y);
-   input_report_abs(input_dev, ABS_PRESSURE, tsc-tc.pressure);
-   input_sync(input_dev);
-   tsc-pendown = true;
+   if (tsc-tc.x  tsc-tc.y) {
+   if (report_pendown)
+   input_report_key(input_dev, BTN_TOUCH, 1);
+
+   input_report_abs(input_dev, ABS_X, tsc-tc.x);
+   input_report_abs(input_dev, ABS_Y, tsc-tc.y);
+   input_report_abs(input_dev, ABS_PRESSURE, 
tsc-tc.pressure);
+   input_sync(input_dev);
+   tsc-pendown = true;
+   } else {
+   dev_dbg(tsc-dev, discarding bogus read x=%d, y=%d, 
pressure=%d\n, tsc-tc.x, tsc-tc.y, tsc-tc.pressure);
+   }
+   poll = 1;
}

 done:
tps6507x_adc_standby(tsc);
+   if (tsc-irq  !poll) {
+   // Re-enable the interrupt
+   tps6507x_write_u8(tsc, TPS6507X_REG_INT, TPS6507X_REG_MASK_TSC);
+   } else {
+   /* always poll if not using interrupts */
+   schd = schedule_delayed_work(tsc-work,
+
msecs_to_jiffies(tsc-poll_period));
+   }
+}
+
+static irqreturn_t tps6507x_ts_irq(int irq, void * dev_id)
+{
+   struct tps6507x_ts * tsc = (struct tps6507x_ts *)dev_id;
+
+   schedule_delayed_work(tsc-work, 0);
+
+   return IRQ_HANDLED;
+}
+
+static int tps6507x_ts_open(struct input_dev *input_dev)
+{
+   int ret;
+   struct tps6507x_ts *tsc = input_get_drvdata(input_dev);
+
+   tsc-open_count++;
+
+// printk(%s: %s\n, __func__, comm);
+   dump_stack();
+
+   if (tsc-irq

[PATCH v2] touchscreen: tps6507x-ts: only poll while touch event is occurring

[Jon Ringle]

We only need to poll for touch events after an interrupt occurs due to the
user touching the screen. We continue to poll until the user stops touching
the screen

Signed-off-by: Jon Ringle jrin...@gridpoint.com
---
 drivers/input/touchscreen/tps6507x-ts.c | 188 +---
 include/linux/input/tps6507x-ts.h   |   1 +
 include/linux/mfd/tps6507x.h|   1 +
 3 files changed, 151 insertions(+), 39 deletions(-)

diff --git a/drivers/input/touchscreen/tps6507x-ts.c 
b/drivers/input/touchscreen/tps6507x-ts.c
index 94cde2c..24043ff 100644
--- a/drivers/input/touchscreen/tps6507x-ts.c
+++ b/drivers/input/touchscreen/tps6507x-ts.c
@@ -17,11 +17,14 @@
 #include linux/workqueue.h
 #include linux/slab.h
 #include linux/input.h
-#include linux/input-polldev.h
 #include linux/platform_device.h
 #include linux/mfd/tps6507x.h
 #include linux/input/tps6507x-ts.h
 #include linux/delay.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/irq.h
+#include linux/interrupt.h

 #define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
 #define TPS_DEFAULT_MIN_PRESSURE 0x30
@@ -39,13 +42,17 @@ struct ts_event {
 };

 struct tps6507x_ts {
+   struct input_dev*input_dev;
struct device   *dev;
-   struct input_polled_dev *poll_dev;
struct tps6507x_dev *mfd;
charphys[32];
+   struct delayed_work work;
struct ts_event tc;
+   int irq;
+   unsigned long   poll_period;/* ms */
u16 min_pressure;
boolpendown;
+   int open_count;
 };

 static int tps6507x_read_u8(struct tps6507x_ts *tsc, u8 reg, u8 *data)
@@ -155,13 +162,20 @@ static s32 tps6507x_adc_standby(struct tps6507x_ts *tsc)
return ret;
 }

-static void tps6507x_ts_poll(struct input_polled_dev *poll_dev)
+static void tps6507x_ts_handler(struct work_struct *work)
 {
-   struct tps6507x_ts *tsc = poll_dev-private;
-   struct input_dev *input_dev = poll_dev-input;
+   struct tps6507x_ts *tsc =  container_of(work, struct tps6507x_ts, 
work.work);
+   struct input_dev *input_dev = tsc-input_dev;
bool pendown;
+   int schd;
+   int poll = 0;
s32 ret;

+   if (tsc-irq) {
+   // Disable the touch interrupt
+   tps6507x_write_u8(tsc, TPS6507X_REG_INT, 0);
+   }
+
ret = tps6507x_adc_conversion(tsc, TPS6507X_TSCMODE_PRESSURE,
  tsc-tc.pressure);
if (ret)
@@ -178,9 +192,11 @@ static void tps6507x_ts_poll(struct input_polled_dev 
*poll_dev)
}

if (pendown) {
+   int report_pendown = 0;

if (!tsc-pendown) {
dev_dbg(tsc-dev, DOWN\n);
+   report_pendown = 1;
input_report_key(input_dev, BTN_TOUCH, 1);
} else
dev_dbg(tsc-dev, still down\n);
@@ -195,15 +211,86 @@ static void tps6507x_ts_poll(struct input_polled_dev 
*poll_dev)
if (ret)
goto done;

-   input_report_abs(input_dev, ABS_X, tsc-tc.x);
-   input_report_abs(input_dev, ABS_Y, tsc-tc.y);
-   input_report_abs(input_dev, ABS_PRESSURE, tsc-tc.pressure);
-   input_sync(input_dev);
-   tsc-pendown = true;
+   if (tsc-tc.x  tsc-tc.y) {
+   if (report_pendown)
+   input_report_key(input_dev, BTN_TOUCH, 1);
+
+   input_report_abs(input_dev, ABS_X, tsc-tc.x);
+   input_report_abs(input_dev, ABS_Y, tsc-tc.y);
+   input_report_abs(input_dev, ABS_PRESSURE, 
tsc-tc.pressure);
+   input_sync(input_dev);
+   tsc-pendown = true;
+   } else {
+   dev_dbg(tsc-dev, discarding bogus read x=%d, y=%d, 
pressure=%d\n, tsc-tc.x, tsc-tc.y, tsc-tc.pressure);
+   }
+   poll = 1;
}

 done:
tps6507x_adc_standby(tsc);
+   if (tsc-irq  !poll) {
+   // Re-enable the interrupt
+   tps6507x_write_u8(tsc, TPS6507X_REG_INT, TPS6507X_REG_MASK_TSC);
+   } else {
+   /* always poll if not using interrupts */
+   schd = schedule_delayed_work(tsc-work,
+
msecs_to_jiffies(tsc-poll_period));
+   }
+}
+
+static irqreturn_t tps6507x_ts_irq(int irq, void * dev_id)
+{
+   struct tps6507x_ts * tsc = (struct tps6507x_ts *)dev_id;
+
+   schedule_delayed_work(tsc-work, 0);
+
+   return IRQ_HANDLED;
+}
+
+static int tps6507x_ts_open(struct input_dev *input_dev)
+{
+   int ret;
+   struct tps6507x_ts *tsc = input_get_drvdata(input_dev);
+
+   tsc-open_count++;
+
+   if (tsc-irq) {
+
+   tps6507x_write_u8

[PATCH] Add option to build with -O3

[Jon Ringle]

Signed-off-by: Jon Ringle jrin...@gridpoint.com
---
 Makefile |  2 ++
 init/Kconfig | 19 ---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 78209ee..e7f0b3c 100644
--- a/Makefile
+++ b/Makefile
@@ -581,6 +581,8 @@ all: vmlinux

 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
 KBUILD_CFLAGS  += -Os $(call cc-disable-warning,maybe-uninitialized,)
+else ifdef CONFIG_CC_OPTIMIZE_FOR_SPEED
+KBUILD_CFLAGS   += -O3
 else
 KBUILD_CFLAGS  += -O2
 endif
diff --git a/init/Kconfig b/init/Kconfig
index 009a797..17d4c62 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1233,13 +1233,26 @@ source usr/Kconfig

 endif

+choice
+prompt Optimize
+
+config CC_OPTIMIZE_NORMAL
+bool Optimize Normal (-O2)
+help
+  Enabling this option will pass -O2 to gcc
 config CC_OPTIMIZE_FOR_SIZE
-   bool Optimize for size
+   bool Optimize for size (-Os)
help
- Enabling this option will pass -Os instead of -O2 to gcc
+ Enabling this option will pass -Os to gcc
  resulting in a smaller kernel.

- If unsure, say N.
+config CC_OPTIMIZE_FOR_SPEED
+bool Optimze for speed (-O3)
+help
+  Enabling this option will pass -O3 to gcc
+  resulting in a larger kernel (but possibly faster)
+
+endchoice

 config SYSCTL
bool
--
1.8.5.4


The information contained in this transmission may contain confidential 
information.  If the reader of this message is not the intended recipient, you 
are hereby notified that any review, dissemination, distribution or duplication 
of this communication is strictly prohibited.  If you are not the intended 
recipient, please contact the sender by reply email and destroy all copies of 
the original message.
--
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/

Re: [PATCH] Add option to build with -O3

[Jon Ringle]

On Wed, 5 Mar 2014, Greg KH wrote:

 On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote:
  +config CC_OPTIMIZE_FOR_SPEED
  +bool Optimze for speed (-O3)
  +help
  +  Enabling this option will pass -O3 to gcc
  +  resulting in a larger kernel (but possibly faster)

 Are you sure about that?  Have you measured it?

I do know that there is an improvement performance-wise for my particular
use-case.

My target is an ARM board being built with gcc-4.8.2. My board has on it a
sc16is740 that is used as an RS-485 port. The sc16is740 is on the i2c bus,
so when an interrupt comes in to indicate that there is data available to
be read, I need to get the data over the i2c bus. I do this on a kthread
to do this work. The i2c transactions (using i2c-davinci driver) are also
interrupt driven. I was seeing a lot of lost packets when receiving data
at only 19200. Adding the -O3 compile option helped in this regard in that
I am now rarely seeing packet loss.

Jon

The information contained in this transmission may contain confidential 
information.  If the reader of this message is not the intended recipient, you 
are hereby notified that any review, dissemination, distribution or duplication 
of this communication is strictly prohibited.  If you are not the intended 
recipient, please contact the sender by reply email and destroy all copies of 
the original message.
--
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/

Re: [PATCH] Add option to build with -O3

[Jon Ringle]

On Wed, 5 Mar 2014, Greg KH wrote:

 On Wed, Mar 05, 2014 at 12:37:56AM -0500, Jon Ringle wrote:
  The information contained in this transmission may contain confidential 
  information.  If the reader of this message is not the intended recipient, 
  you are hereby notified that any review, dissemination, distribution or 
  duplication of this communication is strictly prohibited.  If you are not 
  the intended recipient, please contact the sender by reply email and 
  destroy all copies of the original message.

 Because of this footer, I must destroy this message, kernel development
 is not confidental.


Obviously, this is a footer that is not added by me, but rather the mail
server I am sending this message through. Besides, the footer indates it
may contain confidential information. The key word being *may*. Of
course kernel development is never confidential and the content of any
transmission done to the lkml is of public record. You and anyone who
cares to read/comment this message on lkml is indeed the inteded
recipient, therefore there is no need to destroy this message :)

I sure hope your response was just in jest :)

Jon

The information contained in this transmission may contain confidential 
information.  If the reader of this message is not the intended recipient, you 
are hereby notified that any review, dissemination, distribution or duplication 
of this communication is strictly prohibited.  If you are not the intended 
recipient, please contact the sender by reply email and destroy all copies of 
the original message.
--
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/

Re: [PATCH] Add option to build with -O3

[Jon Ringle]

On Wed, 5 Mar 2014, Greg KH wrote:

 On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote:
  +config CC_OPTIMIZE_FOR_SPEED
  +bool Optimze for speed (-O3)
  +help
  +  Enabling this option will pass -O3 to gcc
  +  resulting in a larger kernel (but possibly faster)
 
 Are you sure about that?  Have you measured it?

(Resending this message, since it was destroyed. Hopefully, this is now 
an an acceptable form :)

I do know that there is an improvement performance-wise for my particular 
use-case.

My target is an ARM board being built with gcc-4.8.2. My board has on it a 
sc16is740 that is used as an RS-485 port. The sc16is740 is on the i2c bus, 
so when an interrupt comes in to indicate that there is data available to 
be read, I need to get the data over the i2c bus. I do this on a kthread 
to do this work. The i2c transactions (using i2c-davinci driver) are also 
interrupt driven. I was seeing a lot of lost packets when receiving data 
at only 19200. Adding the -O3 compile option helped in this regard in that 
I am now rarely seeing packet loss.

Jon
 
--
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/

Re: Ethernet controller not starting

[Jon Ringle]

On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki  wrote:
> On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote:
>> I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now
>> the latest LTS kernel).
>> I found that Ethernet controller on the board no longer comes up on 
>> linux-3.12.
>> I was able to bisect the issue I'm having to the following commit:
>>
>> >   45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit
>> >   commit 45f0a85c8258741d11bda25c0a5669c06267204a
>> >   Author: Rafael J. Wysocki 
>> >   Date:   Mon Jun 3 21:49:52 2013 +0200
>> >
>> >   PM / Runtime: Rework the "runtime idle" helper routine
>> >
>> >   The "runtime idle" helper routine, rpm_idle(), currently ignores
>> >   return values from .runtime_idle() callbacks executed by it.
>> >   However, it turns out that many subsystems use
>> >   pm_generic_runtime_idle() which checks the return value of the
>> >   driver's callback and executes pm_runtime_suspend() for the device
>> >   unless that value is not 0.  If that logic is moved to rpm_idle()
>> >   instead, pm_generic_runtime_idle() can be dropped and its users
>> >   will not need any .runtime_idle() callbacks any more.
>> >
>> >   Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
>> >   routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
>> >   ata_port_runtime_idle(), respectively, as well as a few drivers'
>> >   ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
>> >   been returned by the .runtime_idle() callback executed by it.
>> >
>> >   To reduce overall code bloat, make the changes described above.
>> >
>> >   Tested-by: Mika Westerberg 
>> >   Tested-by: Kevin Hilman 
>> >   Signed-off-by: Rafael J. Wysocki 
>> >   Acked-by: Kevin Hilman 
>> >   Reviewed-by: Ulf Hansson 
>> >   Acked-by: Alan Stern 
>>
>> Can anyone offer any suggestions on what I should be looking for to
>> fix this on my board?
>
> Any pointers to the driver in question?

drivers/net/ethernet/ti/davinci_emac.c

I also get the following output:

 Starting Network Manager Wait Online...
[   30.946509] davinci_mdio davinci_mdio.0: resetting idled controller
[   30.953220] net net0: attached PHY driver [Generic PHY]
(mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1)
[   30.962938] IPv6: ADDRCONF(NETDEV_UP): net0: link is not ready
[   31.082087] genirq: Flags mismatch irq 33.  (net0) vs.
 (net0)
[   31.089425] CPU: 0 PID: 679 Comm: NetworkManager Not tainted
3.12.13-fs1-003-g5ae24fe-dirty+ #1218
[   31.098496] Function entered at [] from []
[   31.104398] Function entered at [] from []
[   31.110292] Function entered at [] from []
[   31.116180] Function entered at [] from []
[   31.122069] Function entered at [] from []
[   31.127958] Function entered at [] from []
[   31.133852] Function entered at [] from []
[   31.139741] Function entered at [] from []
[   31.145630] Function entered at [] from []
[   31.151523] Function entered at [] from []
[   31.157412] Function entered at [] from []
[   31.163303] Function entered at [] from []
[   31.169193] Function entered at [] from []
[   31.175080] Function entered at [] from []
[   31.180969] Function entered at [] from []
[   31.186857] Function entered at [] from []
[   31.192747] Function entered at [] from []
[   31.198637] Function entered at [] from []
[   31.204528] Function entered at [] from []
[   31.210600] net net0: DaVinci EMAC: devm_request_irq() failed
[FAILED] Failed to start Network Manager Wait Online.

Putting a breakpoint on the genirq message, the backtrace is:

#0  __setup_irq (irq=irq@entry=33, desc=desc@entry=0xc0d24b10
, new=new@entry=0xc0a6a320) at kernel/irq/manage.c:1177
#1  0xc0042fa4 in request_threaded_irq (irq=irq@entry=33,
handler=handler@entry=0xc02a6bbc ,
thread_fn=thread_fn@entry=0x0 <__vectors_start>, irqflags=0,
irqflags@entry=3234987536, devname=0xc2f87000 \"net0\",
devname@entry=0xc02a7954  \"\",
dev_id=dev_id@entry=0xc2f87000) at kernel/irq/manage.c:1438
#2  0xc0044794 in devm_request_threaded_irq (dev=0xc0d1e688
, irq=irq@entry=33,
handler=handler@entry=0xc02a6bbc ,
thread_fn=thread_fn@entry=0x0 <__vectors_start>,
irqflags=irqflags@entry=0, devname=devname@entry=0xc2f87000 \"net0\",
dev_id=dev_id@entry=0xc2f87000) at kernel/irq/devres.c:60
#3  0xc02a7954 in devm_request_irq (dev_id=0xc2f87000,
devname=0xc2f87000 \"net0\", irqflags=0, handler=0xc02a6bbc
, irq=33, dev=) at
include/linux/interrupt.h:158
#4  emac_dev_open (ndev=0xc2f87000) at
driv

Ethernet controller not starting

[Jon Ringle]

I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now
the latest LTS kernel).
I found that Ethernet controller on the board no longer comes up on linux-3.12.
I was able to bisect the issue I'm having to the following commit:

>   45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit
>   commit 45f0a85c8258741d11bda25c0a5669c06267204a
>   Author: Rafael J. Wysocki 
>   Date:   Mon Jun 3 21:49:52 2013 +0200
>
>   PM / Runtime: Rework the "runtime idle" helper routine
>
>   The "runtime idle" helper routine, rpm_idle(), currently ignores
>   return values from .runtime_idle() callbacks executed by it.
>   However, it turns out that many subsystems use
>   pm_generic_runtime_idle() which checks the return value of the
>   driver's callback and executes pm_runtime_suspend() for the device
>   unless that value is not 0.  If that logic is moved to rpm_idle()
>   instead, pm_generic_runtime_idle() can be dropped and its users
>   will not need any .runtime_idle() callbacks any more.
>
>   Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
>   routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
>   ata_port_runtime_idle(), respectively, as well as a few drivers'
>   ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
>   been returned by the .runtime_idle() callback executed by it.
>
>   To reduce overall code bloat, make the changes described above.
>
>   Tested-by: Mika Westerberg 
>   Tested-by: Kevin Hilman 
>   Signed-off-by: Rafael J. Wysocki 
>   Acked-by: Kevin Hilman 
>   Reviewed-by: Ulf Hansson 
>   Acked-by: Alan Stern 

Can anyone offer any suggestions on what I should be looking for to
fix this on my board?

Thanks,
Jon
--
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/

Ethernet controller not starting

[Jon Ringle]

I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now
the latest LTS kernel).
I found that Ethernet controller on the board no longer comes up on linux-3.12.
I was able to bisect the issue I'm having to the following commit:

   45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit
   commit 45f0a85c8258741d11bda25c0a5669c06267204a
   Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
   Date:   Mon Jun 3 21:49:52 2013 +0200

   PM / Runtime: Rework the runtime idle helper routine

   The runtime idle helper routine, rpm_idle(), currently ignores
   return values from .runtime_idle() callbacks executed by it.
   However, it turns out that many subsystems use
   pm_generic_runtime_idle() which checks the return value of the
   driver's callback and executes pm_runtime_suspend() for the device
   unless that value is not 0.  If that logic is moved to rpm_idle()
   instead, pm_generic_runtime_idle() can be dropped and its users
   will not need any .runtime_idle() callbacks any more.

   Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
   routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
   ata_port_runtime_idle(), respectively, as well as a few drivers'
   ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
   been returned by the .runtime_idle() callback executed by it.

   To reduce overall code bloat, make the changes described above.

   Tested-by: Mika Westerberg mika.westerb...@linux.intel.com
   Tested-by: Kevin Hilman khil...@linaro.org
   Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
   Acked-by: Kevin Hilman khil...@linaro.org
   Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
   Acked-by: Alan Stern st...@rowland.harvard.edu

Can anyone offer any suggestions on what I should be looking for to
fix this on my board?

Thanks,
Jon
--
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/

Re: Ethernet controller not starting

[Jon Ringle]

On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
 On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote:
 I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now
 the latest LTS kernel).
 I found that Ethernet controller on the board no longer comes up on 
 linux-3.12.
 I was able to bisect the issue I'm having to the following commit:

45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit
commit 45f0a85c8258741d11bda25c0a5669c06267204a
Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
Date:   Mon Jun 3 21:49:52 2013 +0200
 
PM / Runtime: Rework the runtime idle helper routine
 
The runtime idle helper routine, rpm_idle(), currently ignores
return values from .runtime_idle() callbacks executed by it.
However, it turns out that many subsystems use
pm_generic_runtime_idle() which checks the return value of the
driver's callback and executes pm_runtime_suspend() for the device
unless that value is not 0.  If that logic is moved to rpm_idle()
instead, pm_generic_runtime_idle() can be dropped and its users
will not need any .runtime_idle() callbacks any more.
 
Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
ata_port_runtime_idle(), respectively, as well as a few drivers'
ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
been returned by the .runtime_idle() callback executed by it.
 
To reduce overall code bloat, make the changes described above.
 
Tested-by: Mika Westerberg mika.westerb...@linux.intel.com
Tested-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
Acked-by: Kevin Hilman khil...@linaro.org
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Alan Stern st...@rowland.harvard.edu

 Can anyone offer any suggestions on what I should be looking for to
 fix this on my board?

 Any pointers to the driver in question?

drivers/net/ethernet/ti/davinci_emac.c

I also get the following output:

 Starting Network Manager Wait Online...
[   30.946509] davinci_mdio davinci_mdio.0: resetting idled controller
[   30.953220] net net0: attached PHY driver [Generic PHY]
(mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1)
[   30.962938] IPv6: ADDRCONF(NETDEV_UP): net0: link is not ready
[   31.082087] genirq: Flags mismatch irq 33.  (net0) vs.
 (net0)
[   31.089425] CPU: 0 PID: 679 Comm: NetworkManager Not tainted
3.12.13-fs1-003-g5ae24fe-dirty+ #1218
[   31.098496] Function entered at [c000d6dc] from [c000baa8]
[   31.104398] Function entered at [c000baa8] from [c0042d9c]
[   31.110292] Function entered at [c0042d9c] from [c0042fa4]
[   31.116180] Function entered at [c0042fa4] from [c0044794]
[   31.122069] Function entered at [c0044794] from [c02a7954]
[   31.127958] Function entered at [c02a7954] from [c03289b8]
[   31.133852] Function entered at [c03289b8] from [c0328bd8]
[   31.139741] Function entered at [c0328bd8] from [c0328ce4]
[   31.145630] Function entered at [c0328ce4] from [c03340fc]
[   31.151523] Function entered at [c03340fc] from [c0335104]
[   31.157412] Function entered at [c0335104] from [c033547c]
[   31.163303] Function entered at [c033547c] from [c033e858]
[   31.169193] Function entered at [c033e858] from [c0333db8]
[   31.175080] Function entered at [c0333db8] from [c033e238]
[   31.180969] Function entered at [c033e238] from [c033e6b4]
[   31.186857] Function entered at [c033e6b4] from [c0314460]
[   31.192747] Function entered at [c0314460] from [c0315598]
[   31.198637] Function entered at [c0315598] from [c0316580]
[   31.204528] Function entered at [c0316580] from [c00093c0]
[   31.210600] net net0: DaVinci EMAC: devm_request_irq() failed
[FAILED] Failed to start Network Manager Wait Online.

Putting a breakpoint on the genirq message, the backtrace is:

#0  __setup_irq (irq=irq@entry=33, desc=desc@entry=0xc0d24b10
irq_desc+3960, new=new@entry=0xc0a6a320) at kernel/irq/manage.c:1177
#1  0xc0042fa4 in request_threaded_irq (irq=irq@entry=33,
handler=handler@entry=0xc02a6bbc emac_irq,
thread_fn=thread_fn@entry=0x0 __vectors_start, irqflags=0,
irqflags@entry=3234987536, devname=0xc2f87000 \net0\,
devname@entry=0xc02a7954 emac_dev_open+284 \\,
dev_id=dev_id@entry=0xc2f87000) at kernel/irq/manage.c:1438
#2  0xc0044794 in devm_request_threaded_irq (dev=0xc0d1e688
da8xx_emac_device+16, irq=irq@entry=33,
handler=handler@entry=0xc02a6bbc emac_irq,
thread_fn=thread_fn@entry=0x0 __vectors_start,
irqflags=irqflags@entry=0, devname=devname@entry=0xc2f87000 \net0\,
dev_id=dev_id@entry=0xc2f87000) at kernel/irq/devres.c:60
#3  0xc02a7954 in devm_request_irq (dev_id=0xc2f87000,
devname=0xc2f87000 \net0\, irqflags=0, handler=0xc02a6bbc
emac_irq, irq=33, dev=optimized out) at
include/linux/interrupt.h:158
#4

Re: scheduling while atomic and DEBUG_SPINLOCK_SLEEP

[Jon Ringle]

Arjan van de Ven wrote:

On Tue, 2007-06-26 at 22:55 -0400, Jon Ringle wrote:
  

Hello,
Out of these two, the first one that is showing "in_atomic():1" seems
more likely to me to be a potential cause of the "scheduling while
atomic" dump.

Does this logic seem reasonable? Are there other debugging techniques I
can use to narrow down the cause for the "scheduling while atomic"?




you could start by giving us pointers to the sources of the two
drivers... without that... how can we look and help?

  

You can get Intel's source from here:
GPL_ixp400LinuxEthernetDriverPatch-1_5.zip:
http://downloadcenter.intel.com/detail_desc.aspx?agr=N=2100=9519

BSD_ixp400AccessLibrary-2_1.zip:
http://downloadfinder.intel.com/scripts-df/detail_desc.asp?agr=Y=2100=10146

Jon
-
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: scheduling while atomic and DEBUG_SPINLOCK_SLEEP

[Jon Ringle]

Arjan van de Ven wrote:

On Tue, 2007-06-26 at 22:55 -0400, Jon Ringle wrote:
  

Hello,
Out of these two, the first one that is showing in_atomic():1 seems
more likely to me to be a potential cause of the scheduling while
atomic dump.

Does this logic seem reasonable? Are there other debugging techniques I
can use to narrow down the cause for the scheduling while atomic?




you could start by giving us pointers to the sources of the two
drivers... without that... how can we look and help?

  

You can get Intel's source from here:
GPL_ixp400LinuxEthernetDriverPatch-1_5.zip:
http://downloadcenter.intel.com/detail_desc.aspx?agr=NProductID=2100DwnldID=9519

BSD_ixp400AccessLibrary-2_1.zip:
http://downloadfinder.intel.com/scripts-df/detail_desc.asp?agr=YProductID=2100DwnldID=10146

Jon
-
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/

scheduling while atomic and DEBUG_SPINLOCK_SLEEP

[Jon Ringle]

Hello,

I am sometimes getting the following "scheduling while atomic" dump:

[42949427.37] scheduling while atomic: sh/0x0002/144
[42949427.38] [] (dump_stack+0x0/0x14) from []
(schedule+0x628/0x6c8)
[42949427.39] [] (schedule+0x0/0x6c8) from []
(__down_read+0xc4/0x128)
[42949427.40] [] (__down_read+0x0/0x128) from []
(do_page_fault+0x84/0x214)
[42949427.40]  r5 = 0017  r4 = C02F6168
[42949427.41] [] (do_page_fault+0x0/0x214) from
[] (do_DataAbort+0x3c/0xa4)
[42949427.42] [] (do_DataAbort+0x0/0xa4) from []
(__dabt_svc+0x40/0x60)
[42949427.43]  r8 = 0093  r7 = C0186920  r6 = E5903048  r5 =
CF21FD14
[42949427.43]  r4 = 
[42949427.44] [] (do_alignment_ldrstr+0x0/0x130) from
[] (do_alignment+0x238/0x34c)
[42949427.45]  r4 = CF21E000
[42949427.45] [] (do_alignment+0x0/0x34c) from
[] (do_DataAbort+0x3c/0xa4)
[42949427.46] [] (do_DataAbort+0x0/0xa4) from []
(__dabt_svc+0x40/0x60)
[42949427.47]  r8 = CFD51F34  r7 = 8000  r6 = 0001  r5 =
CF21FE58
[42949427.47]  r4 = 
[42949427.48] [] (get_index+0x0/0x5c) from []
(prio_tree_insert+0xac/0x28c)
[42949427.49] [] (prio_tree_insert+0x0/0x28c) from
[] (vma_prio_tree_insert+0x28/0x40)
[42949427.50] [] (vma_prio_tree_insert+0x0/0x40) from
[] (vma_link+0xe0/0x1d4)
[42949427.50]  r5 = CFC4F90C  r4 = CF21E000
[42949427.51] [] (vma_link+0x0/0x1d4) from []
(do_mmap_pgoff+0x390/0x760)
[42949427.52]  r7 = CFC374E0  r6 = 1000  r5 = 4005E000  r4 =
CFC4F90C
[42949427.52] [] (do_mmap_pgoff+0x0/0x760) from
[] (old_mmap+0x108/0x130)
[42949427.53] [] (old_mmap+0x0/0x130) from []
(ret_fast_syscall+0x0/0x2c)

So, I think I need to try to figure out why the preempt_count is 2. I
enabled CONFIG_DEBUG_SPINLOCK_SLEEP thinking that it would give me more
information about this problem. I got two different hits with this
turned on.

The first dump is coming from Intel's ixp400eth driver:

[42949391.91] Debug: sleeping function called from invalid context
at include/asm/semaphore.h:69
[42949391.91] in_atomic():1, irqs_disabled():128
[42949391.91] [] (dump_stack+0x0/0x14) from []
(__might_sleep+0xe8/0x114)
[42949391.91] [] (__might_sleep+0x0/0x114) from
[] (ixOsalMutexLock+0x190/0x1d8 [ixp400eth])
[42949391.91]  r5 = BF0A3D84  r4 = CFC2D2C0
[42949391.91] [] (ixOsalMutexLock+0x0/0x1d8 [ixp400eth])
from [] (ixEthAccPortMulticastAddressLeaveAll+0x38/0x60
[ixp400eth])
[42949391.91]  r8 = FF9D  r7 = BF09ED88  r6 = C43F5260  r5 =
CFD36000
[42949391.91]  r4 = 
[42949391.91] []
(ixEthAccPortMulticastAddressLeaveAll+0x0/0x60 [ixp400eth]) from
[] (dev_set_multicast_list+0x68/0x214 [ixp400eth])
[42949391.91]  r4 = C43F5000
[42949391.91] [] (dev_set_multicast_list+0x0/0x214
[ixp400eth]) from [] (__dev_mc_upload+0x3c/0x40)
[42949391.91]  r7 =   r6 = 1002  r5 =   r4 =
CFD36000
[42949391.91] [] (__dev_mc_upload+0x0/0x40) from
[] (dev_mc_upload+0x30/0x44)
[42949391.91] [] (dev_mc_upload+0x0/0x44) from
[] (dev_open+0x70/0xcc)
[42949391.91]  r4 = C43F5000
[42949391.91] [] (dev_open+0x0/0xcc) from []
(dev_change_flags+0x68/0x138)
[42949391.91]  r5 = 1043  r4 = C43F5000
[42949391.91] [] (dev_change_flags+0x0/0x138) from
[] (devinet_ioctl+0x64c/0x72c)
[42949391.91]  r7 = CFA09760  r6 = CFD36000  r5 = BEFA8D2C  r4 =
CFB99D40
[42949391.91] [] (devinet_ioctl+0x0/0x72c) from
[] (inet_ioctl+0x1b0/0x1d4)
[42949391.91] [] (inet_ioctl+0x0/0x1d4) from []
(sock_ioctl+0x184/0x2f0)
[42949391.91] [] (sock_ioctl+0x0/0x2f0) from []
(do_ioctl+0x84/0xa0)
[42949391.91]  r8 = C002AE44  r7 = BEFA8D2C  r6 = 8914  r5 =
FFE7
[42949391.91]  r4 = C43F1800
[42949391.91] [] (do_ioctl+0x0/0xa0) from []
(vfs_ioctl+0x94/0x314)
[42949391.91]  r7 =   r6 = BEFA8D2C  r5 = 0003  r4 =
C43F1800
[42949391.91] [] (vfs_ioctl+0x0/0x314) from []
(sys_ioctl+0x40/0x64)
[42949391.91]  r8 = C002AE44  r7 = 0036  r6 = 8914  r5 =
FFF7
[42949391.91]  r4 = C43F1800
[42949391.91] [] (sys_ioctl+0x0/0x64) from []
(ret_fast_syscall+0x0/0x2c)
[42949391.91]  r6 =   r5 = BEFA8E1C  r4 = BEFA8D2C

And the other one is from one of our own kernel modules:

[42949490.89] Debug: sleeping function called from invalid context
at mm/slab.c:2729
[42949490.89] in_atomic():0, irqs_disabled():128
[42949490.89] [] (dump_stack+0x0/0x14) from []
(__might_sleep+0xe8/0x114)
[42949490.89] [] (__might_sleep+0x0/0x114) from
[] (kmem_cache_alloc+0x74/0x84)
[42949490.89]  r5 = 00D0  r4 = CFFFE0C0
[42949490.89] [] (kmem_cache_alloc+0x0/0x84) from
[] (request_irq+0x80/0xdc)
[42949490.89]  r6 =   r5 = 0007  r4 = 
[42949490.89] [] (request_irq+0x0/0xdc) from []
(VbusHookInterrupt+0x2c/0x68 [dstdrv])
[42949490.89] [] (VbusHookInterrupt+0x0/0x68 [dstdrv])
from [] (VbusRegisterISR+0xcc/0xfc [dstdrv])
[42949490.89]  

scheduling while atomic and DEBUG_SPINLOCK_SLEEP

[Jon Ringle]

Hello,

I am sometimes getting the following scheduling while atomic dump:

[42949427.37] scheduling while atomic: sh/0x0002/144
[42949427.38] [c0030370] (dump_stack+0x0/0x14) from [c029a868]
(schedule+0x628/0x6c8)
[42949427.39] [c029a240] (schedule+0x0/0x6c8) from [c029c92c]
(__down_read+0xc4/0x128)
[42949427.40] [c029c868] (__down_read+0x0/0x128) from [c00335a4]
(do_page_fault+0x84/0x214)
[42949427.40]  r5 = 0017  r4 = C02F6168
[42949427.41] [c0033520] (do_page_fault+0x0/0x214) from
[c0033870] (do_DataAbort+0x3c/0xa4)
[42949427.42] [c0033834] (do_DataAbort+0x0/0xa4) from [c002a800]
(__dabt_svc+0x40/0x60)
[42949427.43]  r8 = 0093  r7 = C0186920  r6 = E5903048  r5 =
CF21FD14
[42949427.43]  r4 = 
[42949427.44] [c0034990] (do_alignment_ldrstr+0x0/0x130) from
[c0034fac] (do_alignment+0x238/0x34c)
[42949427.45]  r4 = CF21E000
[42949427.45] [c0034d74] (do_alignment+0x0/0x34c) from
[c0033870] (do_DataAbort+0x3c/0xa4)
[42949427.46] [c0033834] (do_DataAbort+0x0/0xa4) from [c002a800]
(__dabt_svc+0x40/0x60)
[42949427.47]  r8 = CFD51F34  r7 = 8000  r6 = 0001  r5 =
CF21FE58
[42949427.47]  r4 = 
[42949427.48] [c0186900] (get_index+0x0/0x5c) from [c0186bd0]
(prio_tree_insert+0xac/0x28c)
[42949427.49] [c0186b24] (prio_tree_insert+0x0/0x28c) from
[c00762f8] (vma_prio_tree_insert+0x28/0x40)
[42949427.50] [c00762d0] (vma_prio_tree_insert+0x0/0x40) from
[c007b80c] (vma_link+0xe0/0x1d4)
[42949427.50]  r5 = CFC4F90C  r4 = CF21E000
[42949427.51] [c007b72c] (vma_link+0x0/0x1d4) from [c007cfe8]
(do_mmap_pgoff+0x390/0x760)
[42949427.52]  r7 = CFC374E0  r6 = 1000  r5 = 4005E000  r4 =
CFC4F90C
[42949427.52] [c007cc58] (do_mmap_pgoff+0x0/0x760) from
[c002f64c] (old_mmap+0x108/0x130)
[42949427.53] [c002f544] (old_mmap+0x0/0x130) from [c002aca0]
(ret_fast_syscall+0x0/0x2c)

So, I think I need to try to figure out why the preempt_count is 2. I
enabled CONFIG_DEBUG_SPINLOCK_SLEEP thinking that it would give me more
information about this problem. I got two different hits with this
turned on.

The first dump is coming from Intel's ixp400eth driver:

[42949391.91] Debug: sleeping function called from invalid context
at include/asm/semaphore.h:69
[42949391.91] in_atomic():1, irqs_disabled():128
[42949391.91] [c00303bc] (dump_stack+0x0/0x14) from [c003f6f0]
(__might_sleep+0xe8/0x114)
[42949391.91] [c003f608] (__might_sleep+0x0/0x114) from
[bf003a20] (ixOsalMutexLock+0x190/0x1d8 [ixp400eth])
[42949391.91]  r5 = BF0A3D84  r4 = CFC2D2C0
[42949391.91] [bf003890] (ixOsalMutexLock+0x0/0x1d8 [ixp400eth])
from [bf00bc40] (ixEthAccPortMulticastAddressLeaveAll+0x38/0x60
[ixp400eth])
[42949391.91]  r8 = FF9D  r7 = BF09ED88  r6 = C43F5260  r5 =
CFD36000
[42949391.91]  r4 = 
[42949391.91] [bf00bc08]
(ixEthAccPortMulticastAddressLeaveAll+0x0/0x60 [ixp400eth]) from
[bf001734] (dev_set_multicast_list+0x68/0x214 [ixp400eth])
[42949391.91]  r4 = C43F5000
[42949391.91] [bf0016cc] (dev_set_multicast_list+0x0/0x214
[ixp400eth]) from [c01ea834] (__dev_mc_upload+0x3c/0x40)
[42949391.91]  r7 =   r6 = 1002  r5 =   r4 =
CFD36000
[42949391.91] [c01ea7f8] (__dev_mc_upload+0x0/0x40) from
[c01ea868] (dev_mc_upload+0x30/0x44)
[42949391.91] [c01ea838] (dev_mc_upload+0x0/0x44) from
[c01e551c] (dev_open+0x70/0xcc)
[42949391.91]  r4 = C43F5000
[42949391.91] [c01e54ac] (dev_open+0x0/0xcc) from [c01e6f68]
(dev_change_flags+0x68/0x138)
[42949391.91]  r5 = 1043  r4 = C43F5000
[42949391.91] [c01e6f00] (dev_change_flags+0x0/0x138) from
[c0231454] (devinet_ioctl+0x64c/0x72c)
[42949391.91]  r7 = CFA09760  r6 = CFD36000  r5 = BEFA8D2C  r4 =
CFB99D40
[42949391.91] [c0230e08] (devinet_ioctl+0x0/0x72c) from
[c0232760] (inet_ioctl+0x1b0/0x1d4)
[42949391.91] [c02325b0] (inet_ioctl+0x0/0x1d4) from [c01dac0c]
(sock_ioctl+0x184/0x2f0)
[42949391.91] [c01daa88] (sock_ioctl+0x0/0x2f0) from [c00a2e4c]
(do_ioctl+0x84/0xa0)
[42949391.91]  r8 = C002AE44  r7 = BEFA8D2C  r6 = 8914  r5 =
FFE7
[42949391.91]  r4 = C43F1800
[42949391.91] [c00a2dc8] (do_ioctl+0x0/0xa0) from [c00a2efc]
(vfs_ioctl+0x94/0x314)
[42949391.91]  r7 =   r6 = BEFA8D2C  r5 = 0003  r4 =
C43F1800
[42949391.91] [c00a2e68] (vfs_ioctl+0x0/0x314) from [c00a31bc]
(sys_ioctl+0x40/0x64)
[42949391.91]  r8 = C002AE44  r7 = 0036  r6 = 8914  r5 =
FFF7
[42949391.91]  r4 = C43F1800
[42949391.91] [c00a317c] (sys_ioctl+0x0/0x64) from [c002aca0]
(ret_fast_syscall+0x0/0x2c)
[42949391.91]  r6 =   r5 = BEFA8E1C  r4 = BEFA8D2C

And the other one is from one of our own kernel modules:

[42949490.89] Debug: sleeping function called from invalid context
at mm/slab.c:2729
[42949490.89] in_atomic():0, irqs_disabled():128
[42949490.89] [c00303bc] (dump_stack+0x0/0x14) from [c003f6f0]
(__might_sleep+0xe8/0x114)

scheduling while atomic on arm board.

[Jon Ringle]

Hello,

I'm running Linux 2.6.16.29 on an ixp455 based board (arm). On rare
occasions, I am seeing the following stack dump, which gets resolved
only when a power cycle is done. Does anyone have any suggestions on
what to look for?

Thanks,
Jon

[42949427.37] scheduling while atomic: sh/0x0002/144
[42949427.38] [] (dump_stack+0x0/0x14) from []
(schedule+0x628/0x6c8)
[42949427.39] [] (schedule+0x0/0x6c8) from []
(__down_read+0xc4/0x128)
[42949427.40] [] (__down_read+0x0/0x128) from []
(do_page_fault+0x84/0x214)
[42949427.40]  r5 = 0017  r4 = C02F6168
[42949427.41] [] (do_page_fault+0x0/0x214) from
[] (do_DataAbort+0x3c/0xa4)
[42949427.42] [] (do_DataAbort+0x0/0xa4) from []
(__dabt_svc+0x40/0x60)
[42949427.43]  r8 = 0093  r7 = C0186920  r6 = E5903048  r5 =
CF21FD14
[42949427.43]  r4 = 
[42949427.44] [] (do_alignment_ldrstr+0x0/0x130) from
[] (do_alignment+0x238/0x34c)
[42949427.45]  r4 = CF21E000
[42949427.45] [] (do_alignment+0x0/0x34c) from
[] (do_DataAbort+0x3c/0xa4)
[42949427.46] [] (do_DataAbort+0x0/0xa4) from []
(__dabt_svc+0x40/0x60)
[42949427.47]  r8 = CFD51F34  r7 = 8000  r6 = 0001  r5 =
CF21FE58
[42949427.47]  r4 = 
[42949427.48] [] (get_index+0x0/0x5c) from []
(prio_tree_insert+0xac/0x28c)
[42949427.49] [] (prio_tree_insert+0x0/0x28c) from
[] (vma_prio_tree_insert+0x28/0x40)
[42949427.50] [] (vma_prio_tree_insert+0x0/0x40) from
[] (vma_link+0xe0/0x1d4)
[42949427.50]  r5 = CFC4F90C  r4 = CF21E000
[42949427.51] [] (vma_link+0x0/0x1d4) from []
(do_mmap_pgoff+0x390/0x760)
[42949427.52]  r7 = CFC374E0  r6 = 1000  r5 = 4005E000  r4 =
CFC4F90C
[42949427.52] [] (do_mmap_pgoff+0x0/0x760) from
[] (old_mmap+0x108/0x130)
[42949427.53] [] (old_mmap+0x0/0x130) from []
(ret_fast_syscall+0x0/0x2c)
-
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/

scheduling while atomic on arm board.

[Jon Ringle]

Hello,

I'm running Linux 2.6.16.29 on an ixp455 based board (arm). On rare
occasions, I am seeing the following stack dump, which gets resolved
only when a power cycle is done. Does anyone have any suggestions on
what to look for?

Thanks,
Jon

[42949427.37] scheduling while atomic: sh/0x0002/144
[42949427.38] [c0030370] (dump_stack+0x0/0x14) from [c029a868]
(schedule+0x628/0x6c8)
[42949427.39] [c029a240] (schedule+0x0/0x6c8) from [c029c92c]
(__down_read+0xc4/0x128)
[42949427.40] [c029c868] (__down_read+0x0/0x128) from [c00335a4]
(do_page_fault+0x84/0x214)
[42949427.40]  r5 = 0017  r4 = C02F6168
[42949427.41] [c0033520] (do_page_fault+0x0/0x214) from
[c0033870] (do_DataAbort+0x3c/0xa4)
[42949427.42] [c0033834] (do_DataAbort+0x0/0xa4) from [c002a800]
(__dabt_svc+0x40/0x60)
[42949427.43]  r8 = 0093  r7 = C0186920  r6 = E5903048  r5 =
CF21FD14
[42949427.43]  r4 = 
[42949427.44] [c0034990] (do_alignment_ldrstr+0x0/0x130) from
[c0034fac] (do_alignment+0x238/0x34c)
[42949427.45]  r4 = CF21E000
[42949427.45] [c0034d74] (do_alignment+0x0/0x34c) from
[c0033870] (do_DataAbort+0x3c/0xa4)
[42949427.46] [c0033834] (do_DataAbort+0x0/0xa4) from [c002a800]
(__dabt_svc+0x40/0x60)
[42949427.47]  r8 = CFD51F34  r7 = 8000  r6 = 0001  r5 =
CF21FE58
[42949427.47]  r4 = 
[42949427.48] [c0186900] (get_index+0x0/0x5c) from [c0186bd0]
(prio_tree_insert+0xac/0x28c)
[42949427.49] [c0186b24] (prio_tree_insert+0x0/0x28c) from
[c00762f8] (vma_prio_tree_insert+0x28/0x40)
[42949427.50] [c00762d0] (vma_prio_tree_insert+0x0/0x40) from
[c007b80c] (vma_link+0xe0/0x1d4)
[42949427.50]  r5 = CFC4F90C  r4 = CF21E000
[42949427.51] [c007b72c] (vma_link+0x0/0x1d4) from [c007cfe8]
(do_mmap_pgoff+0x390/0x760)
[42949427.52]  r7 = CFC374E0  r6 = 1000  r5 = 4005E000  r4 =
CFC4F90C
[42949427.52] [c007cc58] (do_mmap_pgoff+0x0/0x760) from
[c002f64c] (old_mmap+0x108/0x130)
[42949427.53] [c002f544] (old_mmap+0x0/0x130) from [c002aca0]
(ret_fast_syscall+0x0/0x2c)
-
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/

tiny tty driver sample

[Jon Ringle]

Hello,

I'm trying to write a tty driver and I'm using
http://lwn.net/images/pdf/LDD3/ch18.pdf as a guide. The sample tiny tty
driver includes the following code:

for (i = 0; i < data_size; ++i) {
if (tty->flip.count >= TTY_FLIPBUF_SIZE)
tty_flip_buffer_push(tty);
tty_insert_flip_char(tty, data[i], TTY_NORMAL);
}
tty_flip_buffer_push(tty);

This doesn't compile against Linux 2.6.16 kernel I'm using, because
tty->flip.count doesn't exist anymore.
How should this sample be re-coded?

Thanks,

Jon
-
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/

tiny tty driver sample

[Jon Ringle]

Hello,

I'm trying to write a tty driver and I'm using
http://lwn.net/images/pdf/LDD3/ch18.pdf as a guide. The sample tiny tty
driver includes the following code:

for (i = 0; i  data_size; ++i) {
if (tty-flip.count = TTY_FLIPBUF_SIZE)
tty_flip_buffer_push(tty);
tty_insert_flip_char(tty, data[i], TTY_NORMAL);
}
tty_flip_buffer_push(tty);

This doesn't compile against Linux 2.6.16 kernel I'm using, because
tty-flip.count doesn't exist anymore.
How should this sample be re-coded?

Thanks,

Jon
-
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: Reserving a fixed physical address page of RAM.

[Jon Ringle]

Fawad Lateef wrote:
> reserving_bootmem in devicemaps_init will work but I think it 
> will be better if you do this in mem_init function (here:
> http://sosdg.org/~coywolf/lxr/source/arch/arm/mm/init.c?v=2.6.
> 16;a=arm#L620),
> so that all the paging and other map related stuff completes. (CMIIW)

Ok. That seems to work ok too. Thanks.

Jon
-
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: Reserving a fixed physical address page of RAM.

[Jon Ringle]

Jon Ringle wrote:
> Fawad Lateef wrote:
> > On 11/30/06, Jon Ringle <[EMAIL PROTECTED]> wrote:
> > > Do you think that the following would work to properly 
> reserve the 
> > > memory. If it does, then I think I can just do a 
> ioremap(0x0000,
> > > 0x1000) to obtain a virtual address. (Ofcourse I would 
> actually use 
> > > symbolic names rather than the hardcoded addesses shown here).
> > >
> > > Index: linux/arch/arm/mm/init.c
> > > 
> ===
> > > --- linux.orig/arch/arm/mm/init.c   2006-11-30 
> > 11:03:00.0
> > > -0500
> > > +++ linux/arch/arm/mm/init.c2006-11-30 
> 11:09:09.0 -0500
> > > @@ -429,6 +429,10 @@
> > > unsigned long addr;
> > > void *vectors;
> > >
> > > +#ifdef CONFIG_MACH_VERTICAL_RSC4
> > > +   reserve_bootmem (0x0000, 0x1000); #endif
> > > +
> > > /*
> > >  * Allocate the vector page early.
> > >  */
> > >
> > >
> > 
> > I think you can do like this but can't say accurately 
> because I havn't 
> > worked on arm architecture and also you havn't mentioned your 
> > kernel-version or function (in file
> > arch/arm/mm/init.c) which you are going to do call reserve_bootmem !
> 
> Kernel version is 2.6.16.29 and the reserve_bootmem() call 
> above is at the top of the function devicemaps_init().

Is there some way I can verify that the above works? I've tried the
following to try to get info on the reservation:
# cat /proc/iomem
# cat /proc/meminfo
# cat /proc/slabinfo
# echo m > /proc/sysrq-trigger

The only one that hints that this might have worked is the `echo m >
/proc/sysrq-trigger` in that I see the reserved pages count one larger
than using a kernel without this patch. Does this mean that the page I
reserved won't get used by Linux for any purpose?

Jon
-
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: Reserving a fixed physical address page of RAM.

[Jon Ringle]

Fawad Lateef wrote:
> On 11/30/06, Jon Ringle <[EMAIL PROTECTED]> wrote:
> > Fawad Lateef wrote:
> > > Yes, this can be used if required physical-memory exists 
> in the last 
> > > part of RAM as if you use mem= then kernel will only use 
> > > memory less than or equal-to  and above can be used 
> by drivers 
> > > (or any kernel module) might be through ioremap which takes 
> > > physical-address.
> >
> > Seems that using mem= has to be in 1MB increments, where I 
> only need 4K.
> >
> 
> No AFAIK you can specify it in KBs (see
> http://sosdg.org/~coywolf/lxr/source/Documentation/kernel-para
> meters.txt#L869)

Yes, you can specify the mem= using K notation, but there is a test in
arch/arm/mm/mm-armv.c:create_mapping() that prevents the mapping from
being created if the boundaries are not MB aligned:

if (mem_types[md->type].prot_l1 == 0 &&
(virt & 0xf || (virt + off) & 0xf || (virt + length)
& 0xf)) {
printk(KERN_WARNING "BUG: map for 0x%08lx at 0x%08lx can
not "
   "be mapped using pages, ignoring.\n",
   __pfn_to_phys(md->pfn), md->virtual);
return;
}

This is in linux-2.6.16.29.

> 
> > >
> > > But if lets say we need only 1MB portion of specific 
> physical-memory 
> > > region then AFAIK it must be done by hacking in kernel 
> code during 
> > > memory-initialization (mem_init
> > > function) where it is marking/checking pages as/are reserved; you 
> > > can simply mark you required pages as reserved too and set their 
> > > count to some-value if you want to know later which pages are 
> > > reserved by you. (can do this reservation work
> > > here: 
> http://lxr.free-electrons.com/source/arch/i386/mm/init.c#605).
> >
> > Do you think that the following would work to properly reserve the 
> > memory. If it does, then I think I can just do a ioremap(0x0000,
> > 0x1000) to obtain a virtual address. (Ofcourse I would actually use 
> > symbolic names rather than the hardcoded addesses shown here).
> >
> > Index: linux/arch/arm/mm/init.c
> > ===
> > --- linux.orig/arch/arm/mm/init.c   2006-11-30 
> 11:03:00.0
> > -0500
> > +++ linux/arch/arm/mm/init.c2006-11-30 11:09:09.0 -0500
> > @@ -429,6 +429,10 @@
> > unsigned long addr;
> > void *vectors;
> >
> > +#ifdef CONFIG_MACH_VERTICAL_RSC4
> > +   reserve_bootmem (0x0000, 0x1000); #endif
> > +
> > /*
> >  * Allocate the vector page early.
> >  */
> >
> >
> 
> I think you can do like this but can't say accurately because 
> I havn't worked on arm architecture and also you havn't 
> mentioned your kernel-version or function (in file 
> arch/arm/mm/init.c) which you are going to do call reserve_bootmem !

Kernel version is 2.6.16.29 and the reserve_bootmem() call above is at
the top of the function devicemaps_init().

Jon
-
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: Reserving a fixed physical address page of RAM.

[Jon Ringle]

Fawad Lateef wrote:
 On 11/30/06, Jon Ringle [EMAIL PROTECTED] wrote:
  Fawad Lateef wrote:
   Yes, this can be used if required physical-memory exists 
 in the last 
   part of RAM as if you use mem=xxxM then kernel will only use 
   memory less than or equal-to xxxM and above can be used 
 by drivers 
   (or any kernel module) might be through ioremap which takes 
   physical-address.
 
  Seems that using mem= has to be in 1MB increments, where I 
 only need 4K.
 
 
 No AFAIK you can specify it in KBs (see
 http://sosdg.org/~coywolf/lxr/source/Documentation/kernel-para
 meters.txt#L869)

Yes, you can specify the mem= using K notation, but there is a test in
arch/arm/mm/mm-armv.c:create_mapping() that prevents the mapping from
being created if the boundaries are not MB aligned:

if (mem_types[md-type].prot_l1 == 0 
(virt  0xf || (virt + off)  0xf || (virt + length)
 0xf)) {
printk(KERN_WARNING BUG: map for 0x%08lx at 0x%08lx can
not 
   be mapped using pages, ignoring.\n,
   __pfn_to_phys(md-pfn), md-virtual);
return;
}

This is in linux-2.6.16.29.

 
  
   But if lets say we need only 1MB portion of specific 
 physical-memory 
   region then AFAIK it must be done by hacking in kernel 
 code during 
   memory-initialization (mem_init
   function) where it is marking/checking pages as/are reserved; you 
   can simply mark you required pages as reserved too and set their 
   count to some-value if you want to know later which pages are 
   reserved by you. (can do this reservation work
   here: 
 http://lxr.free-electrons.com/source/arch/i386/mm/init.c#605).
 
  Do you think that the following would work to properly reserve the 
  memory. If it does, then I think I can just do a ioremap(0x0000,
  0x1000) to obtain a virtual address. (Ofcourse I would actually use 
  symbolic names rather than the hardcoded addesses shown here).
 
  Index: linux/arch/arm/mm/init.c
  ===
  --- linux.orig/arch/arm/mm/init.c   2006-11-30 
 11:03:00.0
  -0500
  +++ linux/arch/arm/mm/init.c2006-11-30 11:09:09.0 -0500
  @@ -429,6 +429,10 @@
  unsigned long addr;
  void *vectors;
 
  +#ifdef CONFIG_MACH_VERTICAL_RSC4
  +   reserve_bootmem (0x0000, 0x1000); #endif
  +
  /*
   * Allocate the vector page early.
   */
 
 
 
 I think you can do like this but can't say accurately because 
 I havn't worked on arm architecture and also you havn't 
 mentioned your kernel-version or function (in file 
 arch/arm/mm/init.c) which you are going to do call reserve_bootmem !

Kernel version is 2.6.16.29 and the reserve_bootmem() call above is at
the top of the function devicemaps_init().

Jon
-
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: Reserving a fixed physical address page of RAM.

[Jon Ringle]

Jon Ringle wrote:
 Fawad Lateef wrote:
  On 11/30/06, Jon Ringle [EMAIL PROTECTED] wrote:
   Do you think that the following would work to properly 
 reserve the 
   memory. If it does, then I think I can just do a 
 ioremap(0x0000,
   0x1000) to obtain a virtual address. (Ofcourse I would 
 actually use 
   symbolic names rather than the hardcoded addesses shown here).
  
   Index: linux/arch/arm/mm/init.c
   
 ===
   --- linux.orig/arch/arm/mm/init.c   2006-11-30 
  11:03:00.0
   -0500
   +++ linux/arch/arm/mm/init.c2006-11-30 
 11:09:09.0 -0500
   @@ -429,6 +429,10 @@
   unsigned long addr;
   void *vectors;
  
   +#ifdef CONFIG_MACH_VERTICAL_RSC4
   +   reserve_bootmem (0x0000, 0x1000); #endif
   +
   /*
* Allocate the vector page early.
*/
  
  
  
  I think you can do like this but can't say accurately 
 because I havn't 
  worked on arm architecture and also you havn't mentioned your 
  kernel-version or function (in file
  arch/arm/mm/init.c) which you are going to do call reserve_bootmem !
 
 Kernel version is 2.6.16.29 and the reserve_bootmem() call 
 above is at the top of the function devicemaps_init().

Is there some way I can verify that the above works? I've tried the
following to try to get info on the reservation:
# cat /proc/iomem
# cat /proc/meminfo
# cat /proc/slabinfo
# echo m  /proc/sysrq-trigger

The only one that hints that this might have worked is the `echo m 
/proc/sysrq-trigger` in that I see the reserved pages count one larger
than using a kernel without this patch. Does this mean that the page I
reserved won't get used by Linux for any purpose?

Jon
-
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: Reserving a fixed physical address page of RAM.

[Jon Ringle]

Fawad Lateef wrote:
 reserving_bootmem in devicemaps_init will work but I think it 
 will be better if you do this in mem_init function (here:
 http://sosdg.org/~coywolf/lxr/source/arch/arm/mm/init.c?v=2.6.
 16;a=arm#L620),
 so that all the paging and other map related stuff completes. (CMIIW)

Ok. That seems to work ok too. Thanks.

Jon
-
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: Reserving a fixed physical address page of RAM.

[Jon Ringle]

linux-os (Dick Johnson) wrote:
> On Mon, 27 Nov 2006, Jon Ringle wrote:
> 
> > Robert Hancock wrote:
> >> Jon Ringle wrote:
> >>> Hi,
> >>>
> >>> I need to reserve a page of memory at a specific area of RAM that 
> >>> will be used as a "shared memory" with another processor 
> over PCI. 
> >>> How can I ensure that the this area of RAM gets reseved 
> so that the 
> >>> Linux's memory management (kmalloc() and friends) don't use it?
> >>>
> >>> Some things that I've considered are iotable_init() and ioremap().
> >>> However, I've seen these used for memory mapped IO 
> devices which are 
> >>> outside of the RAM memory. Can I use them for reseving RAM too?
> >>>
> >>> I appreciate any advice in this regard.
> >>
> >> Sounds to me like dma_alloc_coherent is what you want..
> >>
> > It looks promising, however, I need to reserve a physical 
> address area 
> > that is well known (so that the code running on the other processor 
> > knows where in PCI memory to write to). It appears that 
> > dma_alloc_coherent returns the address that it allocated. Instead I 
> > need something where I can tell it what physical address 
> and range I want to use.
> >
> > Jon
> 
> First, "PCI memory" is some memory inside a board that is 
> addressed through the PCI bus. This address is allocated upon 
> machine start and is available though the PCI interface 
> (check any of the PCI card drivers). If you want to access 
> this memory, you need to follow the same procedures that 
> other boards use.

In my hardware setup, Linux is running in PCI option mode on a IXP455
processor and it exposes a segment of the IXP455's memory so that it is
available on the PCI bus. The other processor (a pentium M running
Windows OS) sees this exposed IXP455 memory as PCI memory from it's
perspective.

> 
> However, perhaps you don't mean "PCI memory". Perhaps you 
> mean real memory in the address-space, and you need to 
> reserve it and give its physical address to something inside 
> a PCI-bus card, perhaps for DMA. In that case, you can either 
> memory-map some physical memory (get_dma_pages()) or you can 
> tell the kernel you have less memory than you really have, 
> and use the memory the kernel doesn't know about for your own 
> private purposes. To access this private memory you use 
> ioremap() and friends. This can be memory-mapped to 
> user-space as well so you can perform DMA directly to 
> user-space buffers. You can find the highest address that the 
> kernel uses by reading kernel variable num_physpages. This 
> tells the number of pages the kernel uses. The kernel does 
> write to the next one so you need to start using pages that 
> are two higher than num_physpages.

I'll take a look telling the kernel it has less memory that there
physically exists and use ioremap() to map it in.

Thanks,
Jon 
-
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: Reserving a fixed physical address page of RAM.

[Jon Ringle]

Jesper Juhl wrote:
> On 28/11/06, Fawad Lateef <[EMAIL PROTECTED]> wrote:
> > On 11/28/06, Dave Airlie <[EMAIL PROTECTED]> wrote:
> > > On 11/28/06, Jon Ringle <[EMAIL PROTECTED]> wrote:
> > 
> > > > It looks promising, however, I need to reserve a 
> physical address 
> > > > area that is well known (so that the code running on the other 
> > > > processor knows where in PCI memory to write to). It 
> appears that 
> > > > dma_alloc_coherent returns the address that it 
> allocated. Instead 
> > > > I need something where I can tell it what physical 
> address and range I want to use.
> > > >
> > >
> > > I've seen other projects just boot a 128M board with mem=120M and 
> > > just use the 8MB at 120 to talk to the other processor..
> > >
> >
> > Yes, this can be used if required physical-memory exists in 
> the last 
> > part of RAM as if you use mem= then kernel will only 
> use memory 
> > less than or equal-to  and above can be used by 
> drivers (or any 
> > kernel module) might be through ioremap which takes 
> physical-address.
> >
> > But if lets say we need only 1MB portion of specific 
> physical-memory 
> > region then AFAIK it must be done by hacking in kernel code during 
> > memory-initialization (mem_init function) where it is 
> marking/checking 
> > pages as/are reserved; you can simply mark you required pages as 
> > reserved too and set their count to some-value if you want to know 
> > later which pages are reserved by you. (can do this reservation work
> > here: http://lxr.free-electrons.com/source/arch/i386/mm/init.c#605).
> > CMIIW
> >
> 
> Can you not use the 'memmap=' kernel option to reserve the 
> specific area you need?
> (See Documentation/kernel-parameters.txt for details)

This looks like what I want, but after searching for this, I found that
memmap= is implemented for i386 and ia64 only. My arch is arm (processor
is an IXP455).

I'll explore the mem= option to see if it will work out.

Jon
-
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: Reserving a fixed physical address page of RAM.

[Jon Ringle]

Robert Hancock wrote:
> Jon Ringle wrote:
> > Robert Hancock wrote:
> >> Jon Ringle wrote:
> >>> Hi,
> >>>
> >>> I need to reserve a page of memory at a specific area of RAM that 
> >>> will be used as a "shared memory" with another processor 
> over PCI. 
> >>> How can I ensure that the this area of RAM gets reseved 
> so that the 
> >>> Linux's memory management (kmalloc() and friends) don't use it?
> >>>
> >>> Some things that I've considered are iotable_init() and ioremap().
> >>> However, I've seen these used for memory mapped IO 
> devices which are 
> >>> outside of the RAM memory. Can I use them for reseving RAM too?
> >>>
> >>> I appreciate any advice in this regard.
> >>
> >> Sounds to me like dma_alloc_coherent is what you want..
> >>
> > It looks promising, however, I need to reserve a physical 
> address area 
> > that is well known (so that the code running on the other processor 
> > knows where in PCI memory to write to). It appears that 
> > dma_alloc_coherent returns the address that it allocated. Instead I 
> > need something where I can tell it what physical address 
> and range I 
> > want to use.
> 
> I don't think this is possible in the general case, as 
> there's no mechanism for moving things out of the way if they 
> might be in use. Your best solution is likely to use 
> dma_alloc_coherent and pass the bus address returned into the 
> other processor to tell it where to write..

I can't do that because my mechanism to talk to the other processor is
exactly what I'm trying to setup. Catch-22 :)
-
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: Reserving a fixed physical address page of RAM.

[Jon Ringle]

Robert Hancock wrote:
 Jon Ringle wrote:
  Robert Hancock wrote:
  Jon Ringle wrote:
  Hi,
 
  I need to reserve a page of memory at a specific area of RAM that 
  will be used as a shared memory with another processor 
 over PCI. 
  How can I ensure that the this area of RAM gets reseved 
 so that the 
  Linux's memory management (kmalloc() and friends) don't use it?
 
  Some things that I've considered are iotable_init() and ioremap().
  However, I've seen these used for memory mapped IO 
 devices which are 
  outside of the RAM memory. Can I use them for reseving RAM too?
 
  I appreciate any advice in this regard.
 
  Sounds to me like dma_alloc_coherent is what you want..
 
  It looks promising, however, I need to reserve a physical 
 address area 
  that is well known (so that the code running on the other processor 
  knows where in PCI memory to write to). It appears that 
  dma_alloc_coherent returns the address that it allocated. Instead I 
  need something where I can tell it what physical address 
 and range I 
  want to use.
 
 I don't think this is possible in the general case, as 
 there's no mechanism for moving things out of the way if they 
 might be in use. Your best solution is likely to use 
 dma_alloc_coherent and pass the bus address returned into the 
 other processor to tell it where to write..

I can't do that because my mechanism to talk to the other processor is
exactly what I'm trying to setup. Catch-22 :)
-
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: Reserving a fixed physical address page of RAM.

[Jon Ringle]

Jesper Juhl wrote:
 On 28/11/06, Fawad Lateef [EMAIL PROTECTED] wrote:
  On 11/28/06, Dave Airlie [EMAIL PROTECTED] wrote:
   On 11/28/06, Jon Ringle [EMAIL PROTECTED] wrote:
  snip
It looks promising, however, I need to reserve a 
 physical address 
area that is well known (so that the code running on the other 
processor knows where in PCI memory to write to). It 
 appears that 
dma_alloc_coherent returns the address that it 
 allocated. Instead 
I need something where I can tell it what physical 
 address and range I want to use.
   
  
   I've seen other projects just boot a 128M board with mem=120M and 
   just use the 8MB at 120 to talk to the other processor..
  
 
  Yes, this can be used if required physical-memory exists in 
 the last 
  part of RAM as if you use mem=xxxM then kernel will only 
 use memory 
  less than or equal-to xxxM and above can be used by 
 drivers (or any 
  kernel module) might be through ioremap which takes 
 physical-address.
 
  But if lets say we need only 1MB portion of specific 
 physical-memory 
  region then AFAIK it must be done by hacking in kernel code during 
  memory-initialization (mem_init function) where it is 
 marking/checking 
  pages as/are reserved; you can simply mark you required pages as 
  reserved too and set their count to some-value if you want to know 
  later which pages are reserved by you. (can do this reservation work
  here: http://lxr.free-electrons.com/source/arch/i386/mm/init.c#605).
  CMIIW
 
 
 Can you not use the 'memmap=' kernel option to reserve the 
 specific area you need?
 (See Documentation/kernel-parameters.txt for details)

This looks like what I want, but after searching for this, I found that
memmap= is implemented for i386 and ia64 only. My arch is arm (processor
is an IXP455).

I'll explore the mem= option to see if it will work out.

Jon
-
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: Reserving a fixed physical address page of RAM.

[Jon Ringle]

linux-os (Dick Johnson) wrote:
 On Mon, 27 Nov 2006, Jon Ringle wrote:
 
  Robert Hancock wrote:
  Jon Ringle wrote:
  Hi,
 
  I need to reserve a page of memory at a specific area of RAM that 
  will be used as a shared memory with another processor 
 over PCI. 
  How can I ensure that the this area of RAM gets reseved 
 so that the 
  Linux's memory management (kmalloc() and friends) don't use it?
 
  Some things that I've considered are iotable_init() and ioremap().
  However, I've seen these used for memory mapped IO 
 devices which are 
  outside of the RAM memory. Can I use them for reseving RAM too?
 
  I appreciate any advice in this regard.
 
  Sounds to me like dma_alloc_coherent is what you want..
 
  It looks promising, however, I need to reserve a physical 
 address area 
  that is well known (so that the code running on the other processor 
  knows where in PCI memory to write to). It appears that 
  dma_alloc_coherent returns the address that it allocated. Instead I 
  need something where I can tell it what physical address 
 and range I want to use.
 
  Jon
 
 First, PCI memory is some memory inside a board that is 
 addressed through the PCI bus. This address is allocated upon 
 machine start and is available though the PCI interface 
 (check any of the PCI card drivers). If you want to access 
 this memory, you need to follow the same procedures that 
 other boards use.

In my hardware setup, Linux is running in PCI option mode on a IXP455
processor and it exposes a segment of the IXP455's memory so that it is
available on the PCI bus. The other processor (a pentium M running
Windows OS) sees this exposed IXP455 memory as PCI memory from it's
perspective.

 
 However, perhaps you don't mean PCI memory. Perhaps you 
 mean real memory in the address-space, and you need to 
 reserve it and give its physical address to something inside 
 a PCI-bus card, perhaps for DMA. In that case, you can either 
 memory-map some physical memory (get_dma_pages()) or you can 
 tell the kernel you have less memory than you really have, 
 and use the memory the kernel doesn't know about for your own 
 private purposes. To access this private memory you use 
 ioremap() and friends. This can be memory-mapped to 
 user-space as well so you can perform DMA directly to 
 user-space buffers. You can find the highest address that the 
 kernel uses by reading kernel variable num_physpages. This 
 tells the number of pages the kernel uses. The kernel does 
 write to the next one so you need to start using pages that 
 are two higher than num_physpages.

I'll take a look telling the kernel it has less memory that there
physically exists and use ioremap() to map it in.

Thanks,
Jon 
-
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: Reserving a fixed physical address page of RAM.

[Jon Ringle]

Robert Hancock wrote:

Jon Ringle wrote:

Hi,

I need to reserve a page of memory at a specific area of RAM that will
be used as a "shared memory" with another processor over PCI. How can I
ensure that the this area of RAM gets reseved so that the Linux's memory
management (kmalloc() and friends) don't use it?

Some things that I've considered are iotable_init() and ioremap().
However, I've seen these used for memory mapped IO devices which are
outside of the RAM memory. Can I use them for reseving RAM too?

I appreciate any advice in this regard.


Sounds to me like dma_alloc_coherent is what you want..

It looks promising, however, I need to reserve a physical address area 
that is well known (so that the code running on the other processor 
knows where in PCI memory to write to). It appears that 
dma_alloc_coherent returns the address that it allocated. Instead I need 
something where I can tell it what physical address and range I want to use.


Jon
-
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/

Reserving a fixed physical address page of RAM.

[Jon Ringle]

Hi,

I need to reserve a page of memory at a specific area of RAM that will
be used as a "shared memory" with another processor over PCI. How can I
ensure that the this area of RAM gets reseved so that the Linux's memory
management (kmalloc() and friends) don't use it?

Some things that I've considered are iotable_init() and ioremap().
However, I've seen these used for memory mapped IO devices which are
outside of the RAM memory. Can I use them for reseving RAM too?

I appreciate any advice in this regard.

Thanks,

Jon
-
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/

Reserving a fixed physical address page of RAM.

[Jon Ringle]

Hi,

I need to reserve a page of memory at a specific area of RAM that will
be used as a shared memory with another processor over PCI. How can I
ensure that the this area of RAM gets reseved so that the Linux's memory
management (kmalloc() and friends) don't use it?

Some things that I've considered are iotable_init() and ioremap().
However, I've seen these used for memory mapped IO devices which are
outside of the RAM memory. Can I use them for reseving RAM too?

I appreciate any advice in this regard.

Thanks,

Jon
-
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: Reserving a fixed physical address page of RAM.

[Jon Ringle]

Robert Hancock wrote:

Jon Ringle wrote:

Hi,

I need to reserve a page of memory at a specific area of RAM that will
be used as a shared memory with another processor over PCI. How can I
ensure that the this area of RAM gets reseved so that the Linux's memory
management (kmalloc() and friends) don't use it?

Some things that I've considered are iotable_init() and ioremap().
However, I've seen these used for memory mapped IO devices which are
outside of the RAM memory. Can I use them for reseving RAM too?

I appreciate any advice in this regard.


Sounds to me like dma_alloc_coherent is what you want..

It looks promising, however, I need to reserve a physical address area 
that is well known (so that the code running on the other processor 
knows where in PCI memory to write to). It appears that 
dma_alloc_coherent returns the address that it allocated. Instead I need 
something where I can tell it what physical address and range I want to use.


Jon
-
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/