Re: [PATCH v3 09/11] power: supply: bq24190_charger: Get input_current_limit from our supplier

[Tony Lindgren]

* Hans de Goede <hdego...@redhat.com> [170830 02:49]:
> On some devices the USB Type-C port power (USB PD 2.0) negotiation is
> done by a separate port-controller IC, while the current limit is
> controlled through another (charger) IC.
> 
> It has been decided to model this by modelling the external Type-C
> power brick (adapter/charger) as a power-supply class device which
> supplies the charger-IC, with its voltage-now and current-max representing
> the negotiated voltage and max current draw.
> 
> This commit adds support for this to the bq24190_charger driver by adding
> an external_power_changed callback and calling
> power_supply_set_input_current_limit_from_supplier from this callback.
> This callback will only get called if the bq24190 has a parent-supply.
> 
> Note this replaces the functionality to get the current-limit from an
> extcon device, which will be removed in a follow-up commit.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Tony Lindgren <t...@atomide.com>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 08/11] power: supply: bq24190_charger: Export 5V boost converter as regulator

[Tony Lindgren]

* Hans de Goede <hdego...@redhat.com> [170830 02:49]:
> Register the 5V boost converter as a regulator named "usb_otg_vbus".
> 
> This commit also adds support for bq24190_platform_data, through which
> non device-tree platforms can pass the regulator_init_data (containing
> mappings for the consumer amongst other things).
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

This will make it easy for USB PHY drivers to implement USB host mode:

Acked-by: Tony Lindgren <t...@atomide.com>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 08/14] power: supply: Add power_supply_set_input_current_limit_from_supplier helper

[Tony Lindgren]

* Hans de Goede <hdego...@redhat.com> [170816 10:38]:
> Hi,
> 
> On 16-08-17 17:54, Tony Lindgren wrote:
> > * Hans de Goede <hdego...@redhat.com> [170815 13:06]:
> > > On some devices the USB Type-C port power (USB PD 2.0) negotiation is
> > > done by a separate port-controller IC, while the current limit is
> > > controlled through another (charger) IC.
> > > 
> > > It has been decided to model this by modelling the external Type-C
> > > power brick (adapter/charger) as a power-supply class device which
> > > supplies the charger-IC, with its voltage-now and current-max representing
> > > the negotiated voltage and max current draw.
> > > 
> > > This commit adds a power_supply_set_input_current_limit_from_supplier
> > > helper function which charger power-supply drivers can call to get
> > > the max-current from their supplier and have this applied
> > > through their set_property call-back to their input-current-limit.
> > 
> > Hmm so can this also be used for the USB gadget subsystem
> > to tell charge controller when it's OK to enable 500mA
> > charging after enumeration?
> 
> I'm not sure that that would be best modeled this way. Perhaps
> the phy-driver can directly control the gpio you have for that,
> that seems better then trying to solve this with cross subsystem
> calls which are always tricky.

I don't think the phy driver knows either when the system
has enumerated as a gadget..

> > FYI, that's controlled by the bq24190 pin named OTG that should
> > be only set high after enumeration. Any ideas how that is wired
> > on your device? Does it connect to the USB PHY or to a GPIO
> > line?
> 
> I believe it is just hardwired to be logical high all the time
> on my board.

OK thanks for checking.

Tony
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 08/14] power: supply: Add power_supply_set_input_current_limit_from_supplier helper

[Tony Lindgren]

* Hans de Goede  [170815 13:06]:
> On some devices the USB Type-C port power (USB PD 2.0) negotiation is
> done by a separate port-controller IC, while the current limit is
> controlled through another (charger) IC.
> 
> It has been decided to model this by modelling the external Type-C
> power brick (adapter/charger) as a power-supply class device which
> supplies the charger-IC, with its voltage-now and current-max representing
> the negotiated voltage and max current draw.
> 
> This commit adds a power_supply_set_input_current_limit_from_supplier
> helper function which charger power-supply drivers can call to get
> the max-current from their supplier and have this applied
> through their set_property call-back to their input-current-limit.

Hmm so can this also be used for the USB gadget subsystem
to tell charge controller when it's OK to enable 500mA
charging after enumeration?

FYI, that's controlled by the bq24190 pin named OTG that should
be only set high after enumeration. Any ideas how that is wired
on your device? Does it connect to the USB PHY or to a GPIO
line?

Regards,

Tony
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] mtd: nand: Rename nand.h into rawnand.h

[Tony Lindgren]

* Boris Brezillon <boris.brezil...@free-electrons.com> [170804 08:30]:
> We are planning to share more code between different NAND based
> devices (SPI NAND, OneNAND and raw NANDs), but before doing that
> we need to move the existing include/linux/mtd/nand.h file into
> include/linux/mtd/rawnand.h so we can later create a nand.h header
> containing all common structure and function prototypes.

For omap:

Acked-by: Tony Lindgren <t...@atomide.com>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 13/18] power: supply: bq24190_charger: Export 5V boost converter as regulator

[Tony Lindgren]

* Hans de Goede  [170806 05:37]:
> Register the 5V boost converter as a regulator named
> "regulator-bq24190-usb-vbus". Note the name includes "bq24190" because
> the bq24190 family is also used on ACPI devices where there are no
> device-tree phandles, so regulator_get will fallback to the name and thus
> it must be unique on the system.

Nice, this makes VBUS easy to use for USB PHY drivers :)

Tony
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC] [PATCH 0/3] media: an attempt to refresh omap1_camera driver

[Tony Lindgren]

* Hans Verkuil  [160617 00:07]:
> Hi Janusz,
> 
> On 06/16/2016 07:21 PM, Janusz Krzysztofik wrote:
> > As requested by media subsystem maintainers, here is an attempt to 
> > convert the omap1_camera driver to the vb2 framework. Also, conversion 
> > to the dmaengine framework, long awaited by ARM/OMAP maintainers, is 
> > done.

Janusz, thanks for updating to the dmaengine :)

> > Next, I'm going to approach removal of soc-camera dependency. Please 
> > let me know how much time I have for that, i.e., when the soc-camera
> > framework is going to be depreciated.
> 
> Well, it is already deprecated (i.e. new drivers cannot use it), but it won't
> be removed any time soon. There are still drivers depending on it, and some
> aren't easy to rewrite.
> 
> I have to say that it is totally unexpected to see that this omap1 driver is 
> still
> used. In fact, we've already merged a patch that removed it for the upcoming
> 4.8 kernel. Based on this new development I'll revert that for the omap1
> driver.
> 
> Out of curiosity: is supporting the Amstrad Delta something you do as a hobby
> or are there other reasons?

Hmm if that IP old phone works fine with mainline kernel, why not keep
using it? :)

> A final note: once you've managed to drop the soc-camera dependency you should
> run the v4l2-compliance test over the video node 
> (https://git.linuxtv.org/v4l-utils.git/).
> 
> If that passes without failures, then this driver is in good shape and can be
> moved out of staging again.

Sounds good to me also, thanks guys.

Tony
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] ARM: OMAP2+: remove DSP platform device

[Tony Lindgren]

* Kristina Martšenko kristina.martse...@gmail.com [140715 16:33]:
 It was added to support DSP Bridge. Since DSP Bridge was removed, and
 nothing else is using the platform device, remove it too.
 
 Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
 Cc: Omar Ramirez Luna omar.rami...@copitl.com
 Cc: Suman Anna s-a...@ti.com
 Cc: Felipe Contreras felipe.contre...@gmail.com

This should not affect idling the DSP hardware block either,
so Greg feel free to queue with the DSP removal patch:

Acked-by: Tony Lindgren t...@atomide.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] staging: tidspbridge: remove driver

[Tony Lindgren]

* Kristina Martšenko kristina.martse...@gmail.com [140716 02:33]:
 The driver has been broken and disabled for several kernel versions now.
 It doesn't have a maintainer anymore, and most of the people who've
 worked on it have moved on. There's also still a long list of issues in
 the TODO file before it can be moved out of staging. Until someone can
 put in the work to make the driver work again and move it out of
 staging, remove it from the kernel.
 
 Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
 Cc: Omar Ramirez Luna omar.rami...@copitl.com
 Cc: Suman Anna s-a...@ti.com
 Cc: Felipe Contreras felipe.contre...@gmail.com
 Cc: Ohad Ben-Cohen o...@wizery.com

Acked-by: Tony Lindgren t...@atomide.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Anybody working on tidspbridge?

[Tony Lindgren]

* Suman Anna s-a...@ti.com [140708 11:40]:
 Hi Peter,
 
 On 07/08/2014 09:36 AM, Greg KH wrote:
  On Tue, Jul 08, 2014 at 03:03:58PM +0200, Peter Meerwald wrote:
  Hello,
 
  Given the total lack of response here, I suggest just deleting the
  driver.  No one has ever done the real work that is going to be
  required to get this code out of staging.  It has had build errors
  causing it to not even be usable for some kernel versions with no one
  noticing, so I doubt anyone cares about it anymore here.
 
  Cc'ing some more people who might be interested. If no one offers to
  work on the driver in the next couple of days, I'll send a patch to
  remove it.
 
  I'm using the driver (with kernel 3.7) and it works reasonably well for 
  me; removing it seems a bit harsh.
  
  Using it is different from being able to maintain the code and move it
  out of the staging tree.  Also, 3.7 is really old and obsolete, not much
  we can do with that kernel version :)
  
  Are you able to work on the code and do the effort needed to get it out
  of the staging tree?  If so, great, if not, we are going to have to
  delete it, sorry.
 
 I agree with Greg here. In fact, the current TODO does not do enough
 justice to the amount of work required to make it even work on the
 latest kernel. Most of the TIers who worked on this driver have moved on
 as Kristina would have figured with her bounced emails. So I do suggest
 that this driver be deleted from the kernel tree. If there are enough
 number of folks using it (not sure how many are out there), it can be
 worked on out-of-tree and brought back in a cleaner fashion rather than
 keeping a broken stale driver in the kernel.

I agree, not much has improved with this driver since it got added into
staging except just compile fixes.

Regards,

Tony
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel