time resume of i2c client
> which is UCSI Cypress CCGx driver. CCG driver will call the ISR
> for any connector change event only if NVIDIA GPU has old
> CCG firmware with the known issue.
>
> Signed-off-by: Ajay Gupta
Can't say if this is a valid workaround but here is my ack
On Fri, Jun 07, 2019 at 11:25:10AM +0300, Heikki Krogerus wrote:
> On Mon, Jun 03, 2019 at 10:05:43AM -0700, Ajay Gupta wrote:
> > From: Ajay Gupta
> >
> > The change enables runtime pm support to UCSI CCG driver.
> > Added ucsi_resume() function to enable notification after
> > system reusme. Ex
> + pm_runtime_mark_last_busy(i2cd->dev);
> + pm_runtime_put_autosuspend(i2cd->dev);
Much better to have this only once!
> +/*
> + * We need gpu_i2c_suspend() even if it is stub, for runtime pm to work
> + * correctly. Without it, lspci shows runtime pm status as "D0" for the card.
> + *
> Changes from v3->v4:
> - Further refactor master_xfer based on Wolfram's comment.
Yay, looks even better. One thing to improve, though.
> status = gpu_i2c_stop(i2cd);
send_stop = false;
> - if (status < 0)
> - return status;
> + if (status < 0) {
> +
On Fri, Jun 07, 2019 at 09:34:18AM -0700, Ajay Gupta wrote:
> Hi Heikki and Wolfram
> The latest set (v5) fix comments from Wolfram on further refactoring
> master_xfer() function in i2c-nvidia-gpuc.c file and removing extra comments
> in patch 2/5.
>
> Patches can go through either usb or i2c tre
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/usb/mtu3/mtu3_plat.c | 6 ++
1 file changed, 2 insertions(+), 4
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/usb/phy/phy-am335x.c | 6 ++
1 file changed, 2 insertions(+), 4
ptr =
- platform_get_drvdata(pdev)
+ dev_get_drvdata(d)
<... when != pdev
- &pdev->dev
+ d
...>
Kind regards,
Wolfram
Wolfram Sang (61):
ARM: plat-samsung: simplify getting .drvdata
ata: simplify getting .drvdata
auxdisplay: simplify getting .drvda
On Tue, Apr 24, 2018 at 10:32:34PM +0200, Krzysztof Kozlowski wrote:
> The Exynos5440 is not actively developed, there are no development
> boards available and probably there are no real products with it.
> Remove wide-tree support for Exynos5440.
>
> Signed-off-by: Krzysztof Kozlowski
Applied
Due to a typo, the mask was destroyed by a comparison instead of a bit
shift.
Reported-by: Geert Uytterhoeven
Signed-off-by: Wolfram Sang
---
Only build tested.
drivers/usb/gadget/udc/goku_udc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc
On Tue, Feb 06, 2018 at 09:50:40AM +0100, Wolfram Sang wrote:
> Due to a typo, the mask was destroyed by a comparison instead of a bit
> shift.
>
> Reported-by: Geert Uytterhoeven
> Signed-off-by: Wolfram Sang
> ---
> Only build tested.
Add. note: according to 'git g
On Mon, Apr 03, 2017 at 09:51:32AM +0200, Zoltan Boszormenyi wrote:
> Use the common mutex from driver/usb/host/pci-quirks.c in the
> i2c-piix4 driver to synchronize access to the I/O port pair
> 0xcd6 / 0xcd7.
>
> At the same time, remove the request_region() call to reserve
> these I/O ports, so
h can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/platform_data
Thanks and kind regards,
Wolfram
Wolfram Sang (3):
mfd: dm355evm_msp: move header file out of I2C realm
mfd: tps65010: move header file out of I2C realm
mfd: twl: move header file out o
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang
---
arch/arm/mach-omap2/common.h| 2 +-
arch/arm/mach-omap2/omap_twl.c | 2 +-
drivers/gpio/gpio-twl4030.c | 2 +-
drivers/iio/adc
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang
---
arch/arm/mach-omap1/board-h2-mmc.c | 2 +-
arch/arm/mach-omap1/board-h2.c | 2 +-
arch/arm/mach-omap1/board-h3-mmc.c | 2 +-
arch/arm/mach-omap1
On Mon, May 22, 2017 at 10:52:43AM +0100, Mark Brown wrote:
> On Mon, May 22, 2017 at 12:02:10AM +0200, Wolfram Sang wrote:
> > include/linux/i2c is not for client devices. Move the header file to a
> > more appropriate location.
>
> Acked-by: Mark Brown
Thanks!
> I&#
> For my own reference:
> Acked-for-MFD-by: Lee Jones
>
> I guess this will be going through the MFD tree?
I'd prefer that, yes. Thanks!
signature.asc
Description: PGP signature
y not sure if dma-mapping.h is a good place for such
a function. I just couldn't think of a better one for now.
Second note: I am not even sure the checks are complete (kmapped mem?).
I am not an MM expert. But that just strengthens the argument of having
on centralized place IMO.
Signed-of
> > +/* only works in process context because of stack detection */
> > +static inline bool is_dma_capable_addr(void *addr)
> > +{
> > + return !(is_vmalloc_or_module_addr(addr) ||
> > +object_is_on_stack(addr));
>
> This does not catch kmap'ed buffers which are not directly DMA'abl
> > Possibly more useful would be a variant of (IIRC) dma_map_for_device()
> > that will allocate a suitable bounce buffer for non-dma memory.
> > I think it can already do so for memory that is outside the address
> > range that the device can address (eg for a 32bit PCIe master in 64bit
> > syst
> So, if I2C is a bit different, then it might simply make sense to keep
> the function local for I2C now? This seems like a sensible start to me
> meanwhile.
Then again, the DMA API would be for drivers. If the USB core wants to
check for capable buffers, such a helper might be nice nonetheless.
On Tue, May 23, 2017 at 08:18:19AM +0100, Lee Jones wrote:
> On Mon, 22 May 2017, Wolfram Sang wrote:
>
> > include/linux/i2c is not for client devices. Move the header file to a
> > more appropriate location.
> >
> > Signed-off-by: Wolfram Sang
> > ---
>
On Thu, Jul 06, 2017 at 08:03:52AM +0100, Lee Jones wrote:
> On Thu, 06 Jul 2017, Thierry Reding wrote:
>
> > On Mon, May 22, 2017 at 12:02:10AM +0200, Wolfram Sang wrote:
> > > include/linux/i2c is not for client devices. Move the header file to a
> >
> > Given the triviality of the change for non-MFD subsystems, can we apply
> > this for 4.14?
>
> I can't apply anything without Acks for *all* of the subsystems above.
Well, there are cases when you can. Those should be exceptions and well
justified, of course.
> My suggestion would be to col
> > Even if it doesn't, it still requires Acks.
>
> As long as this has been compile tested with omap1_defconfig:
>
> Acked-by: Tony Lindgren
Hah, just in time. I was about to send out the new version, thanks! :D
buildbot did test it and I did compile tests, too.
signature.asc
Description:
> Acked-by: Daniel Thompson
Added, thanks!
signature.asc
Description: PGP signature
> grouped together. Wolfgang, can we have your ack for Greg merging both
> through the USB tree?
My name is "Wolfram".
signature.asc
Description: PGP signature
c17 ("typec: tcpm: Represent source supply through...")
> Cc: Adam Thomson
> Signed-off-by: Hans de Goede
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
On Wed, Aug 29, 2018 at 05:33:17PM -0700, ajayk...@gmail.com wrote:
> From: Ajay Gupta
Can you add your full name to the gmail address, too? That would make
patch processing a tad easier.
Thanks,
Wolfram
signature.asc
Description: PGP signature
On Wed, Sep 05, 2018 at 10:17:26PM +, Ajay Gupta wrote:
> Hi Greg,
>
> > > +static int ccg_read(struct ucsi_ccg *uc, u16 rab, u8 *data, u32 len)
> > > +{
> > > + struct device *dev = uc->dev;
> > > + struct i2c_client *client = uc->client;
> > > + unsigned char buf[2];
> > > + struct i2c_msg m
On Mon, Oct 01, 2018 at 07:33:02PM +, Ajay Gupta wrote:
> Hi Heikki and Peter,
>
> > > > > Can we get the working set in while the issues is being debugged?
> > > >
> > > > I'm not the one making the decision, and I don't even know if this
> > > > is going through the i2c or the usb tree? If i
Hi,
> > > We got confirmation from HW team about 4 byte read limitation. There
> > > has to be a STOP after every single read cycle. One read cycle
> > > supports maximum of
> > > 4 byte burst. I will update the patches with a comment on this.
> >
> > Could it be that this is more an SMBus contro
> I don't think SMBus is an option in this case since the intended client
> (Cypress
> something in patch 2/2) does xfers that would need 16-bit commands and I think
> they are always 8-bit in SMBus, no?
Yes. Command is 8 bit, data can be 16. Thanks for the heads up!
signature.asc
Description
On Fri, Oct 26, 2018 at 09:36:58AM -0700, Ajay Gupta wrote:
> Latest NVIDIA GPU card has USB Type-C interface. There is a
> Type-C controller which can be accessed over I2C.
>
> This driver adds I2C bus driver to communicate with Type-C controller.
> I2C client driver will be part of USB Type-C UC
On Mon, Oct 29, 2018 at 02:42:37PM +0200, Andy Shevchenko wrote:
> On Fri, Oct 26, 2018 at 09:36:57AM -0700, Ajay Gupta wrote:
> > Hi Heikki and Wolfram,
> >
> > These two changes add support for USB Type-C interface on latest NVIDIA GPU
> > card.
> > The Type-C controller used is Cypress CCGx an
> @@ -140,5 +140,6 @@ obj-$(CONFIG_I2C_SIBYTE) += i2c-sibyte.o
> obj-$(CONFIG_I2C_XGENE_SLIMPRO) += i2c-xgene-slimpro.o
> obj-$(CONFIG_SCx200_ACB) += scx200_acb.o
> obj-$(CONFIG_I2C_FSI)+= i2c-fsi.o
> +obj-$(CONFIG_I2C_NVIDIA_GPU) += i2c-nvidia-gpu.o
Oh, I fixed this up an
> Hmm... It would be a bit difficult (requires to download patches again as
> mbox).
> I would rather give you a hint how I resolve such problem when apply a tag to
> a
> pile of patches.
I don't mean now, for future patch series, that is... With this one, all
is fine...
> git filter-branch --
On Fri, Oct 26, 2018 at 09:36:59AM -0700, Ajay Gupta wrote:
> Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller
> over I2C interface.
>
> This UCSI I2C driver uses I2C bus driver interface for communicating
> with Type-C controller.
>
> Signed-off-by: Ajay Gupta
Applied to for-curre
> It will be good if both of them can go together either through I2C or
> USB subsystem. Since USB part is reviewed and has Acked-by Heikki so please
> take that also.
Hmmm, technicallly, there is no need to let them go together. There is
no strict dependency. Yet, since Heikki gave his ack, I a
> > I can't send an incremental patch for this, I need to ask: did you try
> > SMBUS_QUICK with it?
> Tried it today using i2cdetect and it looks good to me.
Yup, looks good. Thanks for checking!
signature.asc
Description: PGP signature
On Wed, Oct 24, 2018 at 04:51:31PM +0300, Jarkko Nikula wrote:
> I noticed these independent Renesas drivers have needless dummy runtime
> PM callbacks. I don't have the HW so only build tested.
>
> Patches can be applied independently to their own subsystems. I wanted to
> send them together if s
> At least the I2C driver part of this was on my todo list as well (just a
> bit lower :/). I wanted to find out why they have been there in the
> first place. Do you know if such callbacks were needed "back in the
> days"?
I see now that you referenced the relevant commits in the patch
descripti
enient generic runtime pm callbacks")
> 543f2503a956 ("PM / platform_bus: Allow runtime PM by default")
> 8b313a38ecff ("PM / Platform: Use generic runtime PM callbacks directly")
>
> Signed-off-by: Jarkko Nikula
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
enient generic runtime pm callbacks")
> 543f2503a956 ("PM / platform_bus: Allow runtime PM by default")
> 8b313a38ecff ("PM / Platform: Use generic runtime PM callbacks directly")
>
> Signed-off-by: Jarkko Nikula
Acked-by: Wolfram Sang
>
On Wed, Oct 24, 2018 at 04:51:32PM +0300, Jarkko Nikula wrote:
> Platform drivers don't need dummy runtime PM callbacks that just return
> success and non-NULL pm pointer in their struct device_driver in order
> to have runtime PM happening. This has changed since following commits:
>
> 05aa55dddb
201 - 245 of 245 matches
Mail list logo
