Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

25 participants
7086 discussions

Re: [Linaro-mm-sig] [PATCH 1/2] dt-bindings: i2c: tegra: Add SMBus feature properties

by Rob Herring

On Thu, Dec 09, 2021 at 08:35:20PM +0530, Akhil R wrote: > Tegra I2C can use a gpio as an smbus-alert. Document the usage of > the same. > > Signed-off-by: Akhil R <akhilrajeev(a)nvidia.com> > --- > Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt > index 3f2f990..71ee79b 100644 > --- a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt > +++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt > @@ -70,6 +70,10 @@ Required properties: > - rx > - tx > > +optional properties: > +- smbalert-gpio: Must contain an entry for the gpio to be used as smbus alert. > + It will be used only if optional smbus-alert property is present. There's already a standard way to do this with interrupts. And GPIOs can be interrupts usually. > + > Example: > > i2c@7000c000 { > -- > 2.7.4 > >

4 years, 6 months

Re: [Linaro-mm-sig] [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support

by Christian König

Am 13.12.21 um 12:18 schrieb Shunsuke Mie: > 2021年12月10日(金) 22:29 Christian König <christian.koenig(a)amd.com>: >> Am 10.12.21 um 14:26 schrieb Jason Gunthorpe: >>> On Fri, Dec 10, 2021 at 01:47:37PM +0100, Christian König wrote: >>>> Am 10.12.21 um 13:42 schrieb Jason Gunthorpe: >>>>> On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote: >>>>>> Hi Jason, >>>>>> Thank you for replying. >>>>>> >>>>>> 2021年12月8日(水) 2:14 Jason Gunthorpe <jgg(a)ziepe.ca>: >>>>>>> On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote: >>>>>>>> Hi maintainers, >>>>>>>> >>>>>>>> Could you please review this patch series? >>>>>>> Why is it RFC? >>>>>>> >>>>>>> I'm confused why this is useful? >>>>>>> >>>>>>> This can't do copy from MMIO memory, so it shouldn't be compatible >>>>>>> with things like Gaudi - does something prevent this? >>>>>> I think if an export of the dma-buf supports vmap, CPU is able to access the >>>>>> mmio memory. >>>>>> >>>>>> Is it wrong? If this is wrong, there is no advantages this changes.. >>>>> I don't know what the dmabuf folks did, but yes, it is wrong. >>>>> >>>>> IOMEM must be touched using only special accessors, some platforms >>>>> crash if you don't do this. Even x86 will crash if you touch it with >>>>> something like an XMM optimized memcpy. >>>>> >>>>> Christian? If the vmap succeeds what rules must the caller use to >>>>> access the memory? >>>> See dma-buf-map.h and especially struct dma_buf_map. >>>> >>>> MMIO memory is perfectly supported here and actually the most common case. >>> Okay that looks sane, but this rxe RFC seems to ignore this >>> completely. It stuffs the vaddr directly into a umem which goes to all >>> manner of places in the driver. >>> >>> ?? >> Well, yes that can go boom pretty quickly. > Sorry, I was wrong. The dma_buf_map treats both iomem and vaddr region, but > this RFC only supports vaddr. Advantage of the partial support is we can use the > vaddr dma-buf in RXE without changing a rxe data copy implementation. Well that is most likely not a good idea. For example buffers for GPU drivers can be placed in both MMIO memory and system memory. If you don't want to provoke random failures you *MUST* be able to handle both if you want to use this. Regards, Christian. > > An example of a dma-buf pointing to a vaddr is some gpu drivers use RAM for > VRAM and we can get dma-buf for the region that indicates vaddr regions. > Specifically, the gpu driver using gpu/drm/drm_gem_cma_helper.c is one such > example. > >> Not sure what they want to use this for. > I'd like to use RDMA with RXE for that memory region. > > Best, > Shunsuke >> Christian. >> >>> Jason

4 years, 6 months

Re: [Linaro-mm-sig] [PATCH 2/2] i2c: tegra: Add SMBus block read and SMBus alert functions

by Dmitry Osipenko

09.12.2021 18:05, Akhil R пишет: > +static int tegra_i2c_setup_smbalert(struct tegra_i2c_dev *i2c_dev) > +{ > + struct tegra_i2c_smbalert *smbalert = &i2c_dev->smbalert; > + struct gpio_desc *alert_gpiod; > + struct i2c_client *ara; > + > + alert_gpiod = devm_gpiod_get(i2c_dev->dev, "smbalert", GPIOD_IN); > + if (IS_ERR(alert_gpiod)) > + return PTR_ERR(alert_gpiod); > + > + smbalert->alert_data.irq = gpiod_to_irq(alert_gpiod); > + if (smbalert->alert_data.irq <= 0) > + return smbalert->alert_data.irq; Why GPIO is needed at all if what's actually needed is the interrupt?

4 years, 7 months

Re: [Linaro-mm-sig] [PATCH 2/2] i2c: tegra: Add SMBus block read and SMBus alert functions

by Dmitry Osipenko

09.12.2021 18:33, Andy Shevchenko пишет: > On Thu, Dec 9, 2021 at 5:30 PM Dmitry Osipenko <digetx(a)gmail.com> wrote: >> 09.12.2021 18:05, Akhil R пишет: >>> +static int tegra_i2c_setup_smbalert(struct tegra_i2c_dev *i2c_dev) >>> +{ >>> + struct tegra_i2c_smbalert *smbalert = &i2c_dev->smbalert; >>> + struct gpio_desc *alert_gpiod; >>> + struct i2c_client *ara; >>> + >>> + alert_gpiod = devm_gpiod_get(i2c_dev->dev, "smbalert", GPIOD_IN); >>> + if (IS_ERR(alert_gpiod)) >>> + return PTR_ERR(alert_gpiod); >>> + >>> + smbalert->alert_data.irq = gpiod_to_irq(alert_gpiod); >>> + if (smbalert->alert_data.irq <= 0) >>> + return smbalert->alert_data.irq; >> >> 0 is the error condition. > > I'm not sure what you implied here. gpiod_to_irq() returns 0 if and > only if it goes to the architectures where it might be possible to > have valid vIRQ 0, but this is not the case (at least I never heard of > a such) for GPIO controllers on such platforms. So, looking at the > above code I may tell that the '=' part is redundant. > Yes, removal of the '=' should be enough here.

4 years, 7 months

Re: [Linaro-mm-sig] [PATCH 2/2] i2c: tegra: Add SMBus block read and SMBus alert functions

by Dmitry Osipenko

4 years, 7 months

Re: [Linaro-mm-sig] [PATCH 2/2] i2c: tegra: Add SMBus block read and SMBus alert functions

by Dmitry Osipenko

09.12.2021 18:05, Akhil R пишет: > Emulate the SMBus block read using ContinueXfer and SMBus using GPIO > interrupt. > > For SMBus block read, the driver reads the first byte with ContinueXfer > set which will help to parse the data count and read the remaining bytes > without stop condition in between. > SMBus alert is implemented using external gpio interrupt. > > Signed-off-by: Akhil R <akhilrajeev(a)nvidia.com> > --- > drivers/i2c/busses/i2c-tegra.c | 54 +++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 53 insertions(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c > index a5be8f0..3b70013 100644 > --- a/drivers/i2c/busses/i2c-tegra.c > +++ b/drivers/i2c/busses/i2c-tegra.c > @@ -14,6 +14,7 @@ > #include <linux/dma-mapping.h> > #include <linux/err.h> > #include <linux/i2c.h> > +#include <linux/i2c-smbus.h> > #include <linux/init.h> > #include <linux/interrupt.h> > #include <linux/io.h> > @@ -226,6 +227,11 @@ struct tegra_i2c_hw_feature { > bool has_interface_timing_reg; > }; > > +struct tegra_i2c_smbalert { smbalert isn't a word, should be smbus_alert. Same for the GPIO name and other places. > + struct i2c_smbus_alert_setup alert_data; > + struct i2c_client *ara; What "ara" stands for? Please use meaningful names, like alert_dev for example. I don't see where this member is used at all, please remove it. > +}; > + > /** > * struct tegra_i2c_dev - per device I2C context > * @dev: device reference for power management > @@ -280,6 +286,8 @@ struct tegra_i2c_dev { > int msg_err; > u8 *msg_buf; > > + struct tegra_i2c_smbalert smbalert; All properties must have doc comment. > struct completion dma_complete; > struct dma_chan *tx_dma_chan; > struct dma_chan *rx_dma_chan; > @@ -1232,6 +1240,11 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev, > return err; > > i2c_dev->msg_buf = msg->buf; > + > + /* The condition true implies smbus block read and len is already read*/ Proper SMBus capitalization in comments. Mussing whitespace in the end of the comment. > + if (msg->flags & I2C_M_RECV_LEN && end_state != MSG_END_CONTINUE) > + i2c_dev->msg_buf = msg->buf + 1; > + > i2c_dev->msg_buf_remaining = msg->len; > i2c_dev->msg_err = I2C_ERR_NONE; > i2c_dev->msg_read = !!(msg->flags & I2C_M_RD); > @@ -1388,6 +1401,15 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], > else > end_type = MSG_END_REPEAT_START; > } > + /* If M_RECV_LEN use ContinueXfer to read the first byte */ > + if (msgs[i].flags & I2C_M_RECV_LEN) { > + ret = tegra_i2c_xfer_msg(i2c_dev, &msgs[i], MSG_END_CONTINUE); > + if (ret) > + break; > + /* Set the read byte as msg len */ > + msgs[i].len = msgs[i].buf[0]; > + dev_dbg(i2c_dev->dev, "reading %d bytes\n", msgs[i].len); > + } > ret = tegra_i2c_xfer_msg(i2c_dev, &msgs[i], end_type); > if (ret) > break; > @@ -1415,7 +1437,8 @@ static u32 tegra_i2c_func(struct i2c_adapter *adap) > { > struct tegra_i2c_dev *i2c_dev = i2c_get_adapdata(adap); > u32 ret = I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK) | > - I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING; > + I2C_FUNC_SMBUS_READ_BLOCK_DATA | I2C_FUNC_10BIT_ADDR | > + I2C_FUNC_PROTOCOL_MANGLING; > > if (i2c_dev->hw->has_continue_xfer_support) > ret |= I2C_FUNC_NOSTART; > @@ -1727,6 +1750,29 @@ static int tegra_i2c_init_hardware(struct tegra_i2c_dev *i2c_dev) > return ret; > } > > +static int tegra_i2c_setup_smbalert(struct tegra_i2c_dev *i2c_dev) > +{ > + struct tegra_i2c_smbalert *smbalert = &i2c_dev->smbalert; > + struct gpio_desc *alert_gpiod; > + struct i2c_client *ara; > + > + alert_gpiod = devm_gpiod_get(i2c_dev->dev, "smbalert", GPIOD_IN); > + if (IS_ERR(alert_gpiod)) > + return PTR_ERR(alert_gpiod); > + > + smbalert->alert_data.irq = gpiod_to_irq(alert_gpiod); > + if (smbalert->alert_data.irq <= 0) > + return smbalert->alert_data.irq; > + > + ara = i2c_new_smbus_alert_device(&i2c_dev->adapter, &smbalert->alert_data); > + if (IS_ERR(ara)) > + return PTR_ERR(ara); > + > + smbalert->ara = ara; > + > + return 0; > +} > + > static int tegra_i2c_probe(struct platform_device *pdev) > { > struct tegra_i2c_dev *i2c_dev; > @@ -1821,6 +1867,12 @@ static int tegra_i2c_probe(struct platform_device *pdev) > if (err) > goto release_rpm; > > + if (device_property_read_bool(i2c_dev->dev, "smbus-alert")) { I'd move this device_property_read_bool() inside of tegra_i2c_setup_smbus_alert(), for consistency with the rest of the code in this driver. Although, you shouldn't need it at all, use devm_gpiod_get_optional(). > + err = tegra_i2c_setup_smbalert(i2c_dev); > + if (err) > + dev_warn(&pdev->dev, "smbus-alert setup failed: %d\n", err); GPIO may probe-defer, must be dev_err_probe() here.

4 years, 7 months

[PATCH] drm: Remove duplicate include

by Jiapeng Chong

Clean up the following includecheck warning: ./drivers/gpu/drm/drm_gem_shmem_helper.c: linux/module.h is included more than once. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/drm_gem_shmem_helper.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 62192411..7915047 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -10,7 +10,6 @@ #include <linux/shmem_fs.h> #include <linux/slab.h> #include <linux/vmalloc.h> -#include <linux/module.h> #ifdef CONFIG_X86 #include <asm/set_memory.h> -- 1.8.3.1

4 years, 7 months

Re: [Linaro-mm-sig] [Intel-gfx] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

by Daniel Vetter

Once more an entire week behind on mails, but this looked interesting enough. On Fri, Dec 03, 2021 at 03:18:01PM +0100, Thomas Hellström wrote: > On Fri, 2021-12-03 at 14:08 +0100, Christian König wrote: > > Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel): > > > > > > On 12/1/21 12:25, Christian König wrote: > > > > And why do you use dma_fence_chain to generate a timeline for > > > > TTM? > > > > That should come naturally because all the moves must be ordered. > > > > > > Oh, in this case because we're looking at adding stuff at the end > > > of > > > migration (like coalescing object shared fences and / or async > > > unbind > > > fences), which may not complete in order. > > > > Well that's ok as well. My question is why does this single dma_fence > > then shows up in the dma_fence_chain representing the whole > > migration? > > What we'd like to happen during eviction is that we > > 1) await any exclusive- or moving fences, then schedule the migration > blit. The blit manages its own GPU ptes. Results in a single fence. > 2) Schedule unbind of any gpu vmas, resulting possibly in multiple > fences. This sounds like over-optimizing for nothing. We only really care about pipeling moves on dgpu, and on dgpu we only care about modern userspace (because even gl moves in that direction). And modern means that usually even write access is only setting a read fence, because in vk/compute we only set write fences for object which need implicit sync, and _only_ when actually needed. So ignoring read fences for movings "because it's only reads" is actually busted. I think for buffer moves we should document and enforce (in review) the rule that you have to wait for all fences, otherwise boom. Same really like before freeing backing storage. Otherwise there's just too many gaps and surprises. And yes with Christian's rework of dma_resv this will change, and we'll allow multiple write fences (because that's what amdgpu encoded into their uapi). Still means that you cannot move a buffer without waiting for read fences (or kernel fences or anything really). The other thing is this entire spinlock recursion topic for dma_fence, and I'm deeply unhappy about the truckload of tricks i915 plays and hence in favour of avoiding recursion in this area as much as possible. If we really can't avoid it then irq_work to get a new clean context gets the job done. Making this messy and work is imo a feature, lock nesting of same level locks is just not a good&robust engineering idea. /me back to being completely burried I do hope I can find some more time to review a few more of Christian's patches this week though :-/ Cheers, Daniel > 3) Most but not all of the remaining resv shared fences will have been > finished in 2) We can't easily tell which so we have a couple of shared > fences left. > 4) Add all fences resulting from 1) 2) and 3) into the per-memory-type > dma-fence-chain. > 5) hand the resulting dma-fence-chain representing the end of migration > over to ttm's resource manager. > > Now this means we have a dma-fence-chain disguised as a dma-fence out > in the wild, and it could in theory reappear as a 3) fence for another > migration unless a very careful audit is done, or as an input to the > dma-fence-array used for that single dependency. > > > > > That somehow doesn't seem to make sense because each individual step > > of > > the migration needs to wait for those dependencies as well even when > > it > > runs in parallel. > > > > > But that's not really the point, the point was that an (at least to > > > me) seemingly harmless usage pattern, be it real or fictious, ends > > > up > > > giving you severe internal- or cross-driver headaches. > > > > Yeah, we probably should document that better. But in general I don't > > see much reason to allow mixing containers. The dma_fence_array and > > dma_fence_chain objects have some distinct use cases and and using > > them > > to build up larger dependency structures sounds really questionable. > > Yes, I tend to agree to some extent here. Perhaps add warnings when > adding a chain or array as an input to array and when accidently > joining chains, and provide helpers for flattening if needed. > > /Thomas > > > > > > Christian. > > > > > > > > /Thomas > > > > > > > > > > > > > > Regards, > > > > Christian. > > > > > > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

4 years, 7 months

Re: [Linaro-mm-sig] [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support

by Jason Gunthorpe

On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote: > Hi maintainers, > > Could you please review this patch series? Why is it RFC? I'm confused why this is useful? This can't do copy from MMIO memory, so it shouldn't be compatible with things like Gaudi - does something prevent this? Jason

4 years, 7 months

Re: [Linaro-mm-sig] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

by Christian König

Am 03.12.21 um 15:50 schrieb Thomas Hellström: > > On 12/3/21 15:26, Christian König wrote: >> [Adding Daniel here as well] >> >> Am 03.12.21 um 15:18 schrieb Thomas Hellström: >>> [SNIP] >>>> Well that's ok as well. My question is why does this single dma_fence >>>> then shows up in the dma_fence_chain representing the whole >>>> migration? >>> What we'd like to happen during eviction is that we >>> >>> 1) await any exclusive- or moving fences, then schedule the migration >>> blit. The blit manages its own GPU ptes. Results in a single fence. >>> 2) Schedule unbind of any gpu vmas, resulting possibly in multiple >>> fences. >>> 3) Most but not all of the remaining resv shared fences will have been >>> finished in 2) We can't easily tell which so we have a couple of shared >>> fences left. >> >> Stop, wait a second here. We are going a bit in circles. >> >> Before you migrate a buffer, you *MUST* wait for all shared fences to >> complete. This is documented mandatory DMA-buf behavior. >> >> Daniel and I have discussed that quite extensively in the last few >> month. >> >> So how does it come that you do the blit before all shared fences are >> completed? > > Well we don't currently but wanted to... (I haven't consulted Daniel > in the matter, tbh). > > I was under the impression that all writes would add an exclusive > fence to the dma_resv. Yes that's correct. I'm working on to have more than one write fence, but that is currently under review. > If that's not the case or this is otherwise against the mandatory > DMA-buf bevhavior, we can certainly keep that part as is and that > would eliminate 3). Ah, now that somewhat starts to make sense. So your blit only waits for the writes to finish before starting the blit. Yes that's legal as long as you don't change the original content with the blit. But don't you then need to wait for both reads and writes before you unmap the VMAs? Anyway the good news is your problem totally goes away with the DMA-resv rework I've already send out. Basically it is now possible to have more than one fence in the DMA-resv object for migrations and all existing fences are kept around until they are finished. Regards, Christian. > > /Thomas >

4 years, 7 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig