All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Behún" <kabel@kernel.org>
To: Andy Shevchenko <andy@kernel.org>
Cc: Gregory CLEMENT <gregory.clement@bootlin.com>,
	Arnd Bergmann <arnd@arndb.de>,
	soc@kernel.org, arm@kernel.org,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	linux-gpio@vger.kernel.org
Subject: Re: [PATCH v2 3/7] platform: cznic: turris-omnia-mcu: Add support for MCU connected GPIOs
Date: Mon, 25 Sep 2023 12:03:56 +0200	[thread overview]
Message-ID: <20230925120356.52bcd639@dellmb> (raw)
In-Reply-To: <ZQ2iULDcH6kdk7cJ@smile.fi.intel.com>

On Fri, 22 Sep 2023 17:18:56 +0300
Andy Shevchenko <andy@kernel.org> wrote:

> On Thu, Sep 21, 2023 at 10:25:01PM +0200, Marek Behún wrote:
> > On Thu, 21 Sep 2023 12:55:08 +0300
> > Andy Shevchenko <andy@kernel.org> wrote:  
> 
> ...
> 
> > > > > > +	rising = reply[0] | (reply[2] << 8) | (reply[4] << 16) |
> > > > > > +		 (reply[6] << 24);
> > > > > > +	falling = reply[1] | (reply[3] << 8) | (reply[5] << 16) |
> > > > > > +		  (reply[7] << 24);      
> > > > > 
> > > > > With a help of two masks, you can access to the both edges as to
> > > > >   64-bit value and simplify the code.    
> > > > 
> > > > Huh? As in
> > > >   rising = reply & 0x00ff00ff00ff00ff;
> > > >   falling = reply & 0xff00ff00ff00ff00;
> > > > ?
> > > > But then I can't or the rising bit with the corresponding falling bit
> > > > to get pending...
> > > > Or I guess i can with:
> > > >   pending = rising & (pending >> 8);
> > > > 
> > > > Am I understanding you correctly?
> > > > 
> > > > But then I would need to store the mask in driver data as a 64-bit
> > > > value with half the data not used. Also the CPU is 32-bit.    
> > > 
> > > If you use proper bitmaps, perhaps this will be easier. You can use one for
> > > each and merge them whenever you want (with bitmap_or() call) or split (with
> > > bitmap_and() respectively):
> > > 
> > > 	bitmap_or(full, raising, failing); // merge
> > > 	bitmap_and(raising, full, rasing_mask); // split  
> > 
> > Hmm. But then what? I or the result and use it as pending interrupt
> > bitmap, to be iterated over. The indexes of the bits correspond to the
> > constants in the MCU API.
> > 
> > So after your suggestion I have rising and falling containgin
> >   rising = 00rr00rr00rr00rr; /* r means rising bits */
> >   falling = 00ff00ff00ff00ff; /* f means falling bits */
> >   pending = rising | falling;
> > which means:
> >   pending = pp00pp00pp00pp; /* p means pending bits */
> > But these bit positions do not correspond to the interrupt number
> > anymore.
> > 
> > I still think the de-interleaving of the buffer from
> >   rr ff rr ff rr ff rr ff
> > into two words:
> >   rising = rrrrrrrr;
> >   falling = ffffffff;
> > is simpler...  
> 
> There are two sides of this: OS and hardware. See Xilinx GPIO driver how it's
> made there. But before going that way, check on
> https://lore.kernel.org/all/ZOMmuZuhdjA6mdIG@smile.fi.intel.com/
> That APIs you would need I am pretty sure.

Andy, thank you for patience in reviewing this.

Hmm. I like the names, scatter and gather. In the firmware, I used
interleave and deinterleave, see
  https://gitlab.nic.cz/turris/hw/omnia_hw_ctrl/-/blob/master/src/drivers/i2c_iface.c#L360

But those functions work bit-wise. I realize that the I2C transfers in
the driver are so slow that such bit-wise cycling over a bitmap won't
matter much, but I still find my original proposal more simple and
straight-forward. But I will cave if you insist. Please let me know
(and can I then send your local patch in the series?)

> > > > > > +	if (!(mcu->features & FEAT_NEW_INT_API))
> > > > > > +
> > > > > >   cancel_delayed_work_sync(&mcu->button_release_emul_work); +
> > > > > > +	mutex_destroy(&mcu->lock);      
> > > > > 
> > > > > Wrong order?    
> > > > 
> > > > No, the mutex may be used in the work. Can't destroy it first. Or am I
> > > > misunderstanding something?    
> > > 
> > > I mean you are using a lot of devm(), can mutex be used in IRQ or whatever
> > > that can be triggered after this call?  
> > 
> > OK, I think I need to free the irq before canceling the work. Thank you!  
> 
> Can you rather switch everything to be devm managed?

There are no devm_ calls for mutex and work initialization. Are you
suggesting that I should write a release function for the gpio
sub-driver? Something like

static void omnia_gpiochip_release(dev, res)
{
  cancel_work();
  mutex_destroy();
}

int omnia_mcu_register_gpiochip(mcu)
{
  ...
  x = devres_alloc(omnia_gpiochip_release);
  devres_add(dev, x);
  ...
}

Marek

  reply	other threads:[~2023-09-25 10:04 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-19 10:38 [PATCH v2 0/7] Turris Omnia MCU driver Marek Behún
2023-09-19 10:38 ` [PATCH v2 1/7] dt-bindings: arm: add cznic,turris-omnia-mcu binding Marek Behún
2023-09-20 12:37   ` Krzysztof Kozlowski
2023-09-19 10:38 ` [PATCH v2 2/7] platform: cznic: Add preliminary support for Turris Omnia MCU Marek Behún
2023-09-19 12:29   ` Andy Shevchenko
2023-09-19 15:16     ` Marek Behún
2023-09-19 18:27       ` Andy Shevchenko
2023-09-20 14:19         ` Marek Behún
2023-09-20 14:47           ` Andy Shevchenko
2023-09-19 10:38 ` [PATCH v2 3/7] platform: cznic: turris-omnia-mcu: Add support for MCU connected GPIOs Marek Behún
2023-09-19 13:00   ` Andy Shevchenko
2023-09-20 17:08     ` Marek Behún
2023-09-21  9:55       ` Andy Shevchenko
2023-09-21 20:25         ` Marek Behún
2023-09-22 14:18           ` Andy Shevchenko
2023-09-25 10:03             ` Marek Behún [this message]
2023-09-25 10:29               ` Andy Shevchenko
2023-09-21 18:42     ` Marek Behún
2023-09-22 14:14       ` Andy Shevchenko
2023-09-20 11:58   ` Linus Walleij
2023-09-20 13:36     ` Andy Shevchenko
2023-09-21 19:45     ` Marek Behún
2023-09-21 20:14       ` Marek Behún
2023-09-22 14:21         ` Andy Shevchenko
2023-09-19 10:38 ` [PATCH v2 4/7] platform: cznic: turris-omnia-mcu: Add support for poweroff and wakeup Marek Behún
2023-09-22 16:28   ` Marek Behún
2023-09-19 10:38 ` [PATCH v2 5/7] platform: cznic: turris-omnia-mcu: Add support for MCU watchdog Marek Behún
2023-09-19 13:50   ` Guenter Roeck
2023-09-22 11:46     ` Marek Behún
2023-09-19 10:38 ` [PATCH v2 6/7] ARM: dts: turris-omnia: Add MCU system-controller node Marek Behún
2023-09-19 10:38 ` [PATCH v2 7/7] ARM: dts: turris-omnia: Add GPIO key node for front button Marek Behún

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230925120356.52bcd639@dellmb \
    --to=kabel@kernel.org \
    --cc=andy@kernel.org \
    --cc=arm@kernel.org \
    --cc=arnd@arndb.de \
    --cc=brgl@bgdev.pl \
    --cc=gregory.clement@bootlin.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=soc@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.