[PATCH 86/86] usb/dwc3: move ids to pci_ids.h

2015-03-29 Thread Michael S. Tsirkin
Comment says IDs should move to pci_ids.h, let's do it.

Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
 include/uapi/linux/pci_ids.h |  8 
 drivers/usb/dwc3/dwc3-pci.c  | 10 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/uapi/linux/pci_ids.h b/include/uapi/linux/pci_ids.h
index e63c02a..c10833f3 100644
--- a/include/uapi/linux/pci_ids.h
+++ b/include/uapi/linux/pci_ids.h
@@ -2312,6 +2312,9 @@
 #define PCI_VENDOR_ID_NETCELL  0x169c
 #define PCI_DEVICE_ID_REVOLUTION   0x0044
 
+#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
+
 #define PCI_VENDOR_ID_CENATEK  0x16CA
 #define PCI_DEVICE_ID_CENATEK_IDE  0x0001
 
@@ -2567,11 +2570,13 @@
 #define PCI_DEVICE_ID_INTEL_I960   0x0960
 #define PCI_DEVICE_ID_INTEL_I960RM 0x0962
 #define PCI_DEVICE_ID_INTEL_CENTERTON_ILB  0x0c60
+#define PCI_DEVICE_ID_INTEL_BYT0x0f37
 #define PCI_DEVICE_ID_INTEL_8257X_SOL  0x1062
 #define PCI_DEVICE_ID_INTEL_82573E_SOL 0x1085
 #define PCI_DEVICE_ID_INTEL_82573L_SOL 0x108F
 #define PCI_DEVICE_ID_INTEL_82815_MC   0x1130
 #define PCI_DEVICE_ID_INTEL_82815_CGC  0x1132
+#define PCI_DEVICE_ID_INTEL_MRFLD  0x119e
 #define PCI_DEVICE_ID_INTEL_82092AA_0  0x1221
 #define PCI_DEVICE_ID_INTEL_7505_0 0x2550
 #define PCI_DEVICE_ID_INTEL_7205_0 0x255d
@@ -2593,6 +2598,7 @@
 #define PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI  0x1e31
 #define PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MIN   0x1e40
 #define PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MAX   0x1e5f
+#define PCI_DEVICE_ID_INTEL_BSW0x22B7
 #define PCI_DEVICE_ID_INTEL_DH89XXCC_LPC_MIN   0x2310
 #define PCI_DEVICE_ID_INTEL_DH89XXCC_LPC_MAX   0x231f
 #define PCI_DEVICE_ID_INTEL_82801AA_0  0x2410
@@ -2891,6 +2897,8 @@
 #define PCI_DEVICE_ID_INTEL_84460GX0x84ea
 #define PCI_DEVICE_ID_INTEL_IXP4XX 0x8500
 #define PCI_DEVICE_ID_INTEL_IXP28000x9004
+#define PCI_DEVICE_ID_INTEL_SPTLP  0x9d30
+#define PCI_DEVICE_ID_INTEL_SPTH   0xa130
 #define PCI_DEVICE_ID_INTEL_S21152BB   0xb152
 
 #define PCI_VENDOR_ID_SCALEMP  0x8686
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 4285d8f..19ca7f6 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -20,19 +20,11 @@
 #include linux/module.h
 #include linux/slab.h
 #include linux/pci.h
+#include linux/pci_ids.h
 #include linux/platform_device.h
 
 #include platform_data.h
 
-/* FIXME define these in uapi/linux/pci_ids.h */
-#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
-#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
-#define PCI_DEVICE_ID_INTEL_BYT0x0f37
-#define PCI_DEVICE_ID_INTEL_MRFLD  0x119e
-#define PCI_DEVICE_ID_INTEL_BSW0x22B7
-#define PCI_DEVICE_ID_INTEL_SPTLP  0x9d30
-#define PCI_DEVICE_ID_INTEL_SPTH   0xa130
-
 static int dwc3_pci_quirks(struct pci_dev *pdev)
 {
if (pdev-vendor == PCI_VENDOR_ID_AMD 
-- 
MST

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 65/86] usb/dwc3: comment update

2015-03-29 Thread Michael S. Tsirkin
Header moved from linux/pci_ids.h to uapi/linux/pci_ids.h,
update comment to list the correct header.

Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
 drivers/usb/dwc3/dwc3-pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 8d95056..4285d8f 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -24,7 +24,7 @@
 
 #include platform_data.h
 
-/* FIXME define these in linux/pci_ids.h */
+/* FIXME define these in uapi/linux/pci_ids.h */
 #define PCI_VENDOR_ID_SYNOPSYS 0x16c3
 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
 #define PCI_DEVICE_ID_INTEL_BYT0x0f37
-- 
MST

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] omap fixes for v4.0-rc cycle

2015-03-29 Thread Olof Johansson
On Thu, Mar 19, 2015 at 01:49:23PM -0700, Tony Lindgren wrote:
 The following changes since commit 5b7610f235627878617648a99dd1442997f1c889:
 
   ARM: OMAP2+: Fix wl12xx on dm3730-evm with mainline u-boot (2015-03-06 
 10:37:34 -0800)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/fixes-v4.0-rc4
 
 for you to fetch changes up to 599c376c49323127c9bdbb0fa61a3d4743819bc2:
 
   ARM: dts: Fix gpio interrupts for dm816x (2015-03-18 13:41:34 -0700)
 
 
 Fixes for omaps for the -rc cycle:
 
 - Fix a device tree based booting vs legacy booting regression for
   omap3 crypto hardware by adding the missing DMA channels.
 
 - Fix /sys/bus/soc/devices/soc0/family for am33xx devices.
 
 - Fix two timer issues that can cause hangs if the timer related
   hwmod data is missing like it often initially is for new SoCs.
 
 - Remove pcie hwmods entry from dts as that causes runtime PM to
   fail for the PHYs.
 
 - A paper bag type dts configuration fix for dm816x GPIO
   interrupts that I just noticed. This is most of the changes
   diffstat wise, but as it's a basic feature for connecting
   devices and things work otherwise, it should be fixed.

Merged, thanks.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 86/86] usb/dwc3: move ids to pci_ids.h

2015-03-29 Thread Greg Kroah-Hartman
On Sun, Mar 29, 2015 at 03:43:40PM +0200, Michael S. Tsirkin wrote:
 Comment says IDs should move to pci_ids.h, let's do it.

No, please remove the comment, it's not needed in pci_ids.h at all.

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv3 1/2] HSI: cmt_speech: Add cmt-speech driver

2015-03-29 Thread Aaro Koskinen
Hi,

On Sat, Mar 21, 2015 at 08:09:16PM +0100, Sebastian Reichel wrote:
 From: Kai Vehmanen kai.vehma...@nokia.com
 
 Introduces the cmt-speech driver, which implements
 a character device interface for transferring speech
 data frames over HSI/SSI.
 
 The driver is used to exchange voice/speech data between
 the Nokia N900/N950/N9's modem and its cpu.
 
 Signed-off-by: Kai Vehmanen kai.vehma...@nokia.com
 Signed-off-by: Carlos Chinea carlos.chi...@nokia.com
 Signed-off-by: Joni Lapilainen joni.lapilai...@gmail.com

Acked-by: Aaro Koskinen aaro.koski...@iki.fi

A.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv3 2/2] HSI: nokia-modem: Add cmt-speech support

2015-03-29 Thread Aaro Koskinen
Hi,

On Sat, Mar 21, 2015 at 08:09:17PM +0100, Sebastian Reichel wrote:
 Register cmt-speech driver in nokia-modem driver and forward
 hsi channel information.
 
 Signed-off-by: Sebastian Reichel s...@kernel.org

Acked-by: Aaro Koskinen aaro.koski...@iki.fi

A.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 13/14] twl4030_charger: Increase current carefully while watching voltage.

2015-03-29 Thread NeilBrown
On Mon, 23 Mar 2015 22:25:41 +0100 Pavel Machek pa...@ucw.cz wrote:

 Hi!
 
  The USB Battery Charging spec (BC1.2) suggests a dedicated
  charging port can deliver from 0.5 to 5.0A at between 4.75 and 5.25
  volts.
  
  To choose the correct current voltage setting requires a trial
  and error approach: try to draw current and see if the voltage drops
  too low.
  
  Even with a configured Standard Downstream Port, it may not be possible
  to reliably pull 500mA - depending on cable quality and source
  quality I have reports of charging failure due to the voltage dropping
  too low.
  
  To address both these concerns, this patch introduce incremental
  current setting.
  The current pull from VBUS is increased in steps of 20mA every 100ms
  until the target is reached or until the measure voltage drops below
  4.75V.  If the voltage does go too low, the target current is reduced
  by 20mA and kept there.
 
 Still nervous. If it is possible to overheat the charger, without
 tripping internal fuse, then you'll do it.

If it is possible to overheat the charger without tripping an internal fuse,
then sure the charger is mis-designed - is it not?

Can you suggest an algorithm for determining how much current can safely be
pulled from a charger that would *not* make you nervous?



 
  This applies to currents selected automatically, or to values
  set via sysfs.  So setting a large value will cause the maximum
  available to be used - up to the limit of 1.7A imposed by the
  hardware.
 
 
  +   printk(v=%d cur=%d target=%d\n, v, bci-usb_cur,
  +  bci-usb_cur_target);
 
 dev_info() and a bit better message, or drop it for production?

Changed to dev_dbg() - thanks.


 
  +   if (v  USB_MIN_VOLT) {
  +   /* Back up and stop adjusting. */
  +   bci-usb_cur -= USB_CUR_STEP;
  +   bci-usb_cur_target = bci-usb_cur;
 
 More importantly how does it work with device drawing power for
 operation, too?
 
 Imagine device need 500mA with wifi hotspot, nearly nothing while idle.
 
 Idle device. Code will find that it can charge using 1A, backs up to
 0.9A. User starts hotspot. Now device will draw 1.4A, overloading the
 charger and not charging at all...?

The current being measured and controlled is the current flowing in from the
USB VBUS, not flowing out to the battery.
So I the code choose 0.9A, that is all that will be drawn.

This is a possible issue similar to this though.
If the device is idle and the battery is fully charged, then it won't draw
much current from USB even if we allow it too.
So the algorithm might decide it is OK to draw 1.7A because at that time the
device cannot use more than 200mA, and that doesn't cause the voltage to drop.

Then later when user enabled wifi-hotspot, the current needed might go up
above what the charger can provide.

Maybe I should only increase the limit while the actual current is also
increasing.  Maybe also revisit the setting when the battery starts charging.

NeilBrown


 
 Best regards,
   Pavel



pgpc908HCllRF.pgp
Description: OpenPGP digital signature