* Re: [PATCH v9 2/6] usb:gadget Separated decoding functions from dwc3 driver.
From: Roger Quadros @ 2019-08-07 10:17 UTC (permalink / raw)
To: Pawel Laszczak, Felipe Balbi, devicetree@vger.kernel.org
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
hdegoede@redhat.com, heikki.krogerus@linux.intel.com,
robh+dt@kernel.org, linux-kernel@vger.kernel.org,
jbergsagel@ti.com, nsekhar@ti.com, nm@ti.com, Suresh Punnoose,
peter.chen@nxp.com, Jayshri Dajiram Pawar, Rahul Kumar
In-Reply-To: <BYAPR07MB4709964C1D0AA2A851BF2F55DDF50@BYAPR07MB4709.namprd07.prod.outlook.com>
On 05/07/2019 14:44, Pawel Laszczak wrote:
>
>> EXTERNAL MAIL
>>
>>
>>
>> Hi,
>>
>> Pawel Laszczak <pawell@cadence.com> writes:
>>> diff --git a/include/linux/usb/ch9.h b/include/linux/usb/ch9.h
>>> index da82606be605..d388a3a5ab7e 100644
>>> --- a/include/linux/usb/ch9.h
>>> +++ b/include/linux/usb/ch9.h
>>> @@ -70,4 +70,29 @@ extern enum usb_device_speed usb_get_maximum_speed(struct device *dev);
>>> */
>>> extern const char *usb_state_string(enum usb_device_state state);
>>>
>>> +/**
>>> + * usb_decode_ctrl - Returns human readable representation of control request.
>>> + * @str: buffer to return a human-readable representation of control request.
>>> + * This buffer should have about 200 bytes.
>>> + * @size: size of str buffer.
>>> + * @bRequestType: matches the USB bmRequestType field
>>> + * @bRequest: matches the USB bRequest field
>>> + * @wValue: matches the USB wValue field (CPU byte order)
>>> + * @wIndex: matches the USB wIndex field (CPU byte order)
>>> + * @wLength: matches the USB wLength field (CPU byte order)
>>> + *
>>> + * Function returns decoded, formatted and human-readable description of
>>> + * control request packet.
>>> + *
>>> + * The usage scenario for this is for tracepoints, so function as a return
>>> + * use the same value as in parameters. This approach allows to use this
>>> + * function in TP_printk
>>> + *
>>> + * Important: wValue, wIndex, wLength parameters before invoking this function
>>> + * should be processed by le16_to_cpu macro.
>>> + */
>>> +extern const char *usb_decode_ctrl(char *str, size_t size, __u8 bRequestType,
>>> + __u8 bRequest, __u16 wValue, __u16 wIndex,
>>> + __u16 wLength);
>>> +
>>
>> where's the stub when !TRACING?
>
> Right, I will add
> #ifdef CONFIG_TRACING
> .....
> #endif
Can usb_decode_ctrl() be used even when CONFIG_TRACING is not set?
If yes then above #ifdefe is not sufficient.
You might need to do something like
#if defined(CONFIG_TRACING)
extern const char *usb_decode_ctrl(..)
#else
static inline const char *usb_decode_ctrl(..) {
return NULL;
}
#endif
--
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* Re: [PATCH v2 3/5] dt-bindings: arm: Extend SCMI to support new reset protocol
From: Sudeep Holla @ 2019-08-07 10:18 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-arm-kernel, Peng Fan, linux-kernel, Bo Zhang, Jim Quinlan,
Volodymyr Babchuk, Gaku Inami, aidapala, pajay, Etienne Carriere,
Souvik Chakravarty, wesleys, Felix Burton, Saeed Nowshadi,
Rob Herring, Mark Rutland, devicetree
In-Reply-To: <1565166410.5048.5.camel@pengutronix.de>
On Wed, Aug 07, 2019 at 10:26:50AM +0200, Philipp Zabel wrote:
> On Tue, 2019-08-06 at 18:02 +0100, Sudeep Holla wrote:
> > SCMIv2.0 adds a new Reset Management Protocol to manage various reset
> > states a given device or domain can enter. Extend the existing SCMI
> > bindings to add reset protocol support by re-using the reset bindings
> > for bothe reset providers and consumers.
> ^
> typo
>
Thanks, fixed now.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v9 2/6] usb:gadget Separated decoding functions from dwc3 driver.
From: Felipe Balbi @ 2019-08-07 10:22 UTC (permalink / raw)
To: Roger Quadros, Pawel Laszczak, devicetree@vger.kernel.org
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
hdegoede@redhat.com, heikki.krogerus@linux.intel.com,
robh+dt@kernel.org, linux-kernel@vger.kernel.org,
jbergsagel@ti.com, nsekhar@ti.com, nm@ti.com, Suresh Punnoose,
peter.chen@nxp.com, Jayshri Dajiram Pawar, Rahul Kumar
In-Reply-To: <b66216dd-6fcf-2900-e67b-42fdb81af78a@ti.com>
Hi,
Roger Quadros <rogerq@ti.com> writes:
>>>> +extern const char *usb_decode_ctrl(char *str, size_t size, __u8 bRequestType,
>>>> + __u8 bRequest, __u16 wValue, __u16 wIndex,
>>>> + __u16 wLength);
>>>> +
>>>
>>> where's the stub when !TRACING?
>>
>> Right, I will add
>> #ifdef CONFIG_TRACING
>> .....
>> #endif
>
> Can usb_decode_ctrl() be used even when CONFIG_TRACING is not set?
> If yes then above #ifdefe is not sufficient.
>
> You might need to do something like
>
> #if defined(CONFIG_TRACING)
>
> extern const char *usb_decode_ctrl(..)
>
> #else
>
> static inline const char *usb_decode_ctrl(..) {
> return NULL;
> }
>
> #endif
This is what I mean. They shouldn't be used outside of TRACING, but it's
far safer to have the stubs.
--
balbi
^ permalink raw reply
* RE: [PATCH v9 5/6] usb:cdns3 Add Cadence USB3 DRD Driver
From: Felipe Balbi @ 2019-08-07 10:34 UTC (permalink / raw)
To: Pawel Laszczak, devicetree@vger.kernel.org
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
hdegoede@redhat.com, heikki.krogerus@linux.intel.com,
robh+dt@kernel.org, rogerq@ti.com, linux-kernel@vger.kernel.org,
jbergsagel@ti.com, nsekhar@ti.com, nm@ti.com, Suresh Punnoose,
peter.chen@nxp.com, Jayshri Dajiram Pawar, Rahul Kumar
In-Reply-To: <BYAPR07MB4709152CB29B6B027ABEB688DDCF0@BYAPR07MB4709.namprd07.prod.outlook.com>
Hi,
Pawel Laszczak <pawell@cadence.com> writes:
>>> +static int cdns3_gadget_start(struct cdns3 *cdns)
>>> +{
>>> + struct cdns3_device *priv_dev;
>>> + u32 max_speed;
>>> + int ret;
>>> +
>>> + priv_dev = kzalloc(sizeof(*priv_dev), GFP_KERNEL);
>>> + if (!priv_dev)
>>> + return -ENOMEM;
>>> +
>>> + cdns->gadget_dev = priv_dev;
>>> + priv_dev->sysdev = cdns->dev;
>>> + priv_dev->dev = cdns->dev;
>>> + priv_dev->regs = cdns->dev_regs;
>>> +
>>> + device_property_read_u16(priv_dev->dev, "cdns,on-chip-buff-size",
>>> + &priv_dev->onchip_buffers);
>>> +
>>> + if (priv_dev->onchip_buffers <= 0) {
>>> + u32 reg = readl(&priv_dev->regs->usb_cap2);
>>> +
>>> + priv_dev->onchip_buffers = USB_CAP2_ACTUAL_MEM_SIZE(reg);
>>> + }
>>> +
>>> + if (!priv_dev->onchip_buffers)
>>> + priv_dev->onchip_buffers = 256;
>>> +
>>> + max_speed = usb_get_maximum_speed(cdns->dev);
>>> +
>>> + /* Check the maximum_speed parameter */
>>> + switch (max_speed) {
>>> + case USB_SPEED_FULL:
>>> + case USB_SPEED_HIGH:
>>> + case USB_SPEED_SUPER:
>>> + break;
>>> + default:
>>> + dev_err(cdns->dev, "invalid maximum_speed parameter %d\n",
>>> + max_speed);
>>> + /* fall through */
>>> + case USB_SPEED_UNKNOWN:
>>> + /* default to superspeed */
>>> + max_speed = USB_SPEED_SUPER;
>>> + break;
>>> + }
>>> +
>>> + /* fill gadget fields */
>>> + priv_dev->gadget.max_speed = max_speed;
>>> + priv_dev->gadget.speed = USB_SPEED_UNKNOWN;
>>> + priv_dev->gadget.ops = &cdns3_gadget_ops;
>>> + priv_dev->gadget.name = "usb-ss-gadget";
>>> + priv_dev->gadget.sg_supported = 1;
>>> +
>>> + spin_lock_init(&priv_dev->lock);
>>> + INIT_WORK(&priv_dev->pending_status_wq,
>>> + cdns3_pending_setup_status_handler);
>>> +
>>> + /* initialize endpoint container */
>>> + INIT_LIST_HEAD(&priv_dev->gadget.ep_list);
>>> + INIT_LIST_HEAD(&priv_dev->aligned_buf_list);
>>> +
>>> + ret = cdns3_init_eps(priv_dev);
>>> + if (ret) {
>>> + dev_err(priv_dev->dev, "Failed to create endpoints\n");
>>> + goto err1;
>>> + }
>>> +
>>> + /* allocate memory for setup packet buffer */
>>> + priv_dev->setup_buf = dma_alloc_coherent(priv_dev->sysdev, 8,
>>> + &priv_dev->setup_dma, GFP_DMA);
>>> + if (!priv_dev->setup_buf) {
>>> + ret = -ENOMEM;
>>> + goto err2;
>>> + }
>>> +
>>> + priv_dev->dev_ver = readl(&priv_dev->regs->usb_cap6);
>>> +
>>> + dev_dbg(priv_dev->dev, "Device Controller version: %08x\n",
>>> + readl(&priv_dev->regs->usb_cap6));
>>> + dev_dbg(priv_dev->dev, "USB Capabilities:: %08x\n",
>>> + readl(&priv_dev->regs->usb_cap1));
>>> + dev_dbg(priv_dev->dev, "On-Chip memory cnfiguration: %08x\n",
>>> + readl(&priv_dev->regs->usb_cap2));
>>> +
>>> + priv_dev->dev_ver = GET_DEV_BASE_VERSION(priv_dev->dev_ver);
>>> +
>>> + priv_dev->zlp_buf = kzalloc(CDNS3_EP_ZLP_BUF_SIZE, GFP_KERNEL);
>>> + if (!priv_dev->zlp_buf) {
>>> + ret = -ENOMEM;
>>> + goto err3;
>>> + }
>>> +
>>> + /* add USB gadget device */
>>> + ret = usb_add_gadget_udc(priv_dev->dev, &priv_dev->gadget);
>>> + if (ret < 0) {
>>> + dev_err(priv_dev->dev,
>>> + "Failed to register USB device controller\n");
>>> + goto err4;
>>> + }
>>> +
>>> + return 0;
>>> +err4:
>>> + kfree(priv_dev->zlp_buf);
>>> +err3:
>>> + dma_free_coherent(priv_dev->sysdev, 8, priv_dev->setup_buf,
>>> + priv_dev->setup_dma);
>>> +err2:
>>> + cdns3_free_all_eps(priv_dev);
>>> +err1:
>>> + cdns->gadget_dev = NULL;
>>> + return ret;
>>> +}
>>> +
>>> +static int __cdns3_gadget_init(struct cdns3 *cdns)
>>> +{
>>> + struct cdns3_device *priv_dev;
>>> + int ret = 0;
>>> +
>>> + cdns3_drd_switch_gadget(cdns, 1);
>>> + pm_runtime_get_sync(cdns->dev);
>>> +
>>> + ret = cdns3_gadget_start(cdns);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + priv_dev = cdns->gadget_dev;
>>> + ret = devm_request_threaded_irq(cdns->dev, cdns->dev_irq,
>>> + cdns3_device_irq_handler,
>>> + cdns3_device_thread_irq_handler,
>>> + IRQF_SHARED, dev_name(cdns->dev), cdns);
>>
>>copied handlers here for commenting. Note that you don't have
>>IRQF_ONESHOT:
>
> I know, I can't use IRQF_ ONESHOT flag in this case. I have implemented
> some code for masking/unmasking interrupts in cdns3_device_irq_handler.
>
> Some priority interrupts should be handled ASAP so I can't blocked interrupt
> Line.
You're completely missing my comment. Your top half should be as short
as possile. It should only check if current device generated
interrupts. If it did, then you should wake the thread handler.
This is to improve realtime behavior but not keeping preemption disabled
for longer than necessary.
>>> +static irqreturn_t cdns3_device_irq_handler(int irq, void *data)
>>> +{
>>> + struct cdns3_device *priv_dev;
>>> + struct cdns3 *cdns = data;
>>> + irqreturn_t ret = IRQ_NONE;
>>> + unsigned long flags;
>>> + u32 reg;
>>> +
>>> + priv_dev = cdns->gadget_dev;
>>> + spin_lock_irqsave(&priv_dev->lock, flags);
>>
>>the top half handler runs in hardirq context. You don't need any locks
>>here. Also IRQs are *already* disabled, you don't need to disable them again.
>
> I will remove spin_lock_irqsave but I need to disable only some of the interrupts.
> I disable interrupts associated with USB endpoints. Handling of them can be
> deferred to thread handled.
you should defer all of them to thread. Endpoints or otherwise.
>>> +
>>> + /* check USB device interrupt */
>>> + reg = readl(&priv_dev->regs->usb_ists);
>>> +
>>> + if (reg) {
>>> + writel(reg, &priv_dev->regs->usb_ists);
>>> + cdns3_check_usb_interrupt_proceed(priv_dev, reg);
>>> + ret = IRQ_HANDLED;
>>
>>now, because you _don't_ mask this interrupt, you're gonna have
>>issues. Say we actually get both device and endpoint interrupts while
>>the thread is already running with previous endpoint interrupts. Now
>>we're gonna reenter the top half, because device interrupts are *not*
>>masked, which will read usb_ists and handle it here.
>
> Endpoint interrupts are masked in cdns3_device_irq_handler and stay masked
> until they are not handled in threaded handler.
Quick question, then: these ISTS registers, are they masked interrupt
status or raw interrupt status?
> Of course, not all endpoint interrupts are masked, but only reported in ep_ists.
> USB interrupt will be handled immediately.
>
> Also, I can get next endpoint interrupt from not masked endpoint and driver also again wake
> the thread. I saw such situation, but threaded interrupt handler has been working correct
> in such situations.
>
> In thread handler driver checks again which endpoint should be handled in ep_ists.
>
> I think that such situation should also occurs during our LPM enter/exit test.
> So, driver has been tested for such case. During this test driver during
> transferring data generate a huge number of LPM interrupts which
> are usb interrupts.
>
> I can't block usb interrupts interrupts because:
> /*
> * WORKAROUND: CDNS3 controller has issue with hardware resuming
> * from L1. To fix it, if any DMA transfer is pending driver
> * must starts driving resume signal immediately.
> */
I can't see why this would prevent you from defering handling to thread
handler.
>>> + if (priv_dev->run_garbage_colector) {
>>
>>wait, what?
>
> DMA require data buffer aligned to 8 bytes. So, if buffer data is not aligned
> driver allocate aligned buffer for data and copy it from unaligned to
> Aligned.
>
>>
>>ps: correct spelling is "collector" ;-)
>
> Ok, thanks.
>>
>>> + struct cdns3_aligned_buf *buf, *tmp;
>>> +
>>> + list_for_each_entry_safe(buf, tmp, &priv_dev->aligned_buf_list,
>>> + list) {
>>> + if (!buf->in_use) {
>>> + list_del(&buf->list);
>>> +
>>> + spin_unlock_irqrestore(&priv_dev->lock, flags);
>>
>>creates the possibility of a race condition
> Why? In this place the buf can't be used.
but you're reenabling interrupts, right?
>>> + dma_free_coherent(priv_dev->sysdev, buf->size,
>>> + buf->buf,
>>> + buf->dma);
>>> + spin_lock_irqsave(&priv_dev->lock, flags);
>>> +
>>> + kfree(buf);
>>
>>why do you even need this "garbage collector"?
>
> I need to free not used memory. The once allocated buffer will be associated with
> request, but if request.length will be increased in usb_request then driver will
> must allocate the bigger buffer. As I remember I couldn't call dma_free_coherent
> in interrupt context so I had to move it to thread handled. This flag was used to avoid
> going through whole aligned_buf_list every time.
> In most cases this part will never called int this place
Did you try, btw, setting the quirk flag which tells gadget drivers to
always allocate buffers aligned to MaxPacketSize? Wouldn't that be enough?
>>> + TP_printk("%s: req: %p, req buff %p, length: %u/%u %s%s%s, status: %d,"
>>> + cd " trb: [start:%d, end:%d: virt addr %pa], flags:%x ",
>>> + __get_str(name), __entry->req, __entry->buf, __entry->actual,
>>> + __entry->length,
>>> + __entry->zero ? "zero | " : "",
>>> + __entry->short_not_ok ? "short | " : "",
>>> + __entry->no_interrupt ? "no int" : "",
>>
>>I guess you didn't really think the formatting through. Think about what
>>happens if you get a request with only zero flag or only short flag. How
>>will this log look like?
>
> Like this:
> cdns3_gadget_giveback: ep0: req: 0000000071a6a5f5, req buff 000000008d40c4db, length: 60/60 zero | , status: 0, trb: [start:0, end:0: virt addr (null)], flags:0
>
> Is it something wrong with this?. Maybe one extra sign |.
yes, the extra | :-)
This is one reason why I switched to character flags where a lower case
character means flag is cleared while uppercase means it's set.
--
balbi
^ permalink raw reply
* Re: [PATCH v8 05/14] media: rkisp1: add Rockchip ISP1 subdev driver
From: Hans Verkuil @ 2019-08-07 10:39 UTC (permalink / raw)
To: Helen Koike, hans.verkuil
Cc: linux-rockchip, devicetree, eddie.cai.linux, mchehab, heiko,
jacob2.chen, jeffy.chen, zyc, linux-kernel, tfiga,
laurent.pinchart, sakari.ailus, kernel, ezequiel, linux-media,
linux-arm-kernel, zhengsq, Jacob Chen, Allon Huang
In-Reply-To: <86e17716-193f-ca49-1104-9c599a667eeb@collabora.com>
On 8/6/19 8:51 PM, Helen Koike wrote:
> Hi Hans,
>
> On 7/30/19 3:42 PM, Helen Koike wrote:
>> From: Jacob Chen <jacob2.chen@rock-chips.com>
>>
>> Add the subdev driver for rockchip isp1.
>>
>> Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
>> Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
>> Signed-off-by: Yichong Zhong <zyc@rock-chips.com>
>> Signed-off-by: Jacob Chen <cc@rock-chips.com>
>> Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
>> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
>> Signed-off-by: Allon Huang <allon.huang@rock-chips.com>
>> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
>> [fixed unknown entity type / switched to PIXEL_RATE]
>> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
>> [update for upstream]
>> Signed-off-by: Helen Koike <helen.koike@collabora.com>
>>
>> ---
>>
>> Changes in v8: None
>> Changes in v7:
>> - fixed warning because of unknown entity type
>> - fixed v4l2-compliance errors regarding rkisp1 formats, try formats
>> and default values
>> - fix typo riksp1/rkisp1
>> - redesign: remove mipi/csi subdevice, sensors connect directly to the
>> isp subdevice in the media topology now. As a consequence, remove the
>> hack in mipidphy_g_mbus_config() where information from the sensor was
>> being propagated through the topology.
>> - From the old dphy:
>> * cache get_remote_sensor() in s_stream
>> * use V4L2_CID_PIXEL_RATE instead of V4L2_CID_LINK_FREQ
>> - Replace stream state with a boolean
>> - code styling and checkpatch fixes
>> - fix stop_stream (return after calling stop, do not reenable the stream)
>> - fix rkisp1_isp_sd_get_selection when V4L2_SUBDEV_FORMAT_TRY is set
>> - fix get format in output (isp_sd->out_fmt.mbus_code was being ignored)
>> - s/intput/input
>> - remove #define sd_to_isp_sd(_sd), add a static inline as it will be
>> reused by the capture
>>
>> drivers/media/platform/rockchip/isp1/rkisp1.c | 1286 +++++++++++++++++
>> drivers/media/platform/rockchip/isp1/rkisp1.h | 111 ++
>> 2 files changed, 1397 insertions(+)
>> create mode 100644 drivers/media/platform/rockchip/isp1/rkisp1.c
>> create mode 100644 drivers/media/platform/rockchip/isp1/rkisp1.h
>>
>> diff --git a/drivers/media/platform/rockchip/isp1/rkisp1.c b/drivers/media/platform/rockchip/isp1/rkisp1.c
>> new file mode 100644
>> index 000000000000..6d0c0ffb5e03
>> --- /dev/null
>> +++ b/drivers/media/platform/rockchip/isp1/rkisp1.c
>> @@ -0,0 +1,1286 @@
<snip>
>> +static int rkisp1_isp_sd_get_fmt(struct v4l2_subdev *sd,
>> + struct v4l2_subdev_pad_config *cfg,
>> + struct v4l2_subdev_format *fmt)
>> +{
>> + struct rkisp1_isp_subdev *isp_sd = sd_to_isp_sd(sd);
>> + struct v4l2_mbus_framefmt *mf = &fmt->format;
>> +
>> + if ((fmt->pad != RKISP1_ISP_PAD_SINK) &&
>> + (fmt->pad != RKISP1_ISP_PAD_SOURCE_PATH)) {
>> + fmt->format.code = MEDIA_BUS_FMT_FIXED;
>> + /*
>> + * NOTE: setting a format here doesn't make much sense
>> + * but v4l2-compliance complains
>> + */
>> + fmt->format.width = RKISP1_DEFAULT_WIDTH;
>> + fmt->format.height = RKISP1_DEFAULT_HEIGHT;
>
> As I had mentioned to you, this is called for the isp pads connected to the
> DMA engines for statistics and parameters (meta data).
>
> If I remove those, I get the following errors:
>
> Sub-Device ioctls (Sink Pad 1):
> test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
> fail: v4l2-test-subdevs.cpp(311): fmt.width == 0 || fmt.width > 65536
> fail: v4l2-test-subdevs.cpp(356): checkMBusFrameFmt(node, fmt.format)
> test Try VIDIOC_SUBDEV_G/S_FMT: FAIL
> test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK
> test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
> fail: v4l2-test-subdevs.cpp(311): fmt.width == 0 || fmt.width > 65536
> fail: v4l2-test-subdevs.cpp(356): checkMBusFrameFmt(node, fmt.format)
> test Active VIDIOC_SUBDEV_G/S_FMT: FAIL
> test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK
> test VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
>
> Here is the full log: http://ix.io/1QNt
>
> Is this a bug in v4l2-compliance?
Yes and no :-)
Currently v4l2-compliance assumes that only video is transferred over a media bus.
But that's not the case here, and testing the code field doesn't help v4l2-compliance
since MEDIA_BUS_FMT_FIXED is also still used by some older subdev drivers for video.
I think we need a new bus format: MEDIA_BUS_FMT_FIXED_METADATA. Then v4l2-compliance
can tell it apart from the regular fixed video bus format.
If I do a 'git grep MEDIA_BUS_FMT_FIXED' then I see that it is also in use by vsp1
for histogram information, so that should also be converted to use the new FIXED_METADATA
format, although that might be too late (there might be userspace complications).
Regards,
Hans
>
> Thanks
> Helen
>
>> + fmt->format.field = V4L2_FIELD_NONE;
>> + return 0;
>> + }
>> +
>> + if (fmt->which == V4L2_SUBDEV_FORMAT_TRY) {
>> + mf = v4l2_subdev_get_try_format(sd, cfg, fmt->pad);
>> + fmt->format = *mf;
>> + return 0;
>> + }
>> +
>> + if (fmt->pad == RKISP1_ISP_PAD_SINK) {
>> + *mf = isp_sd->in_frm;
>> + } else if (fmt->pad == RKISP1_ISP_PAD_SOURCE_PATH) {
>> + /* format of source pad */
>> + *mf = isp_sd->in_frm;
>> + mf->code = isp_sd->out_fmt.mbus_code;
>> + /* window size of source pad */
>> + mf->width = isp_sd->out_crop.width;
>> + mf->height = isp_sd->out_crop.height;
>> + mf->quantization = isp_sd->quantization;
>> + }
>> + mf->field = V4L2_FIELD_NONE;
>> +
>> + return 0;
>> +}
^ permalink raw reply
* [PATCH v15 0/5] Add support for mt8183 SCP.
From: Pi-Hsun Shih @ 2019-08-07 10:43 UTC (permalink / raw)
Cc: Pi-Hsun Shih,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support, open list,
moderated list:ARM/Mediatek SoC support,
open list:REMOTE PROCESSOR REMOTEPROC SUBSYSTEM
Add support for controlling and communicating with mt8183's system
control processor (SCP), using the remoteproc & rpmsg framework.
And also add a cros_ec driver for CrOS EC host command over rpmsg.
The overall structure of the series is:
* remoteproc/mtk_scp.c: Control the start / stop of SCP (Patch 2, 3).
* remoteproc/mtk_scp_ipi.c: Communicates to SCP using inter-processor
interrupt (IPI) and shared memory (Patch 2, 3).
* rpmsg/mtk_rpmsg.c: Wrapper to wrap the IPI communication into a rpmsg
device. Supports name service for SCP firmware to
announce channels (Patch 4).
* add scp dts node to mt8183 platform (Patch 5).
Changes from v14:
- Fix a typo on variable in DEBUG section.
Changes from v13:
- Move include/linux/platform_data/mtk_scp.h to
include/linux/remoteproc/mtk_scp.h.
- Rename scp_get_reserve_* to scp_get_reserved_*.
- Add lock for access of scp->ipi_desc.
- Lock the whole ipi_send function.
- Move more setting of cache size from SCP firmware to kernel driver,
to prevent problem while loading firmware onto DRAM.
- Minor fixes addressing comment.
Changes from v12:
- Initialize cache before firmware load, to avoid problem while loading
large firmware.
- Disable watchdog before stopping SCP, to avoid extra warning message.
- Fix new warnings by checkpatch.
Changes from v11:
- Fixed a bug that mtk_rpmsg_endpoint is not properly cleaned up if
rproc_boot fails.
- Add missing documentation in comment.
Changes from v10:
- Drop applied cros_ec_rpmsg patches.
- Add clock reset before loading SCP firmware.
- Fix some type mismatch warnings when printing debug messages.
Changes from v9:
- Remove reserve-memory-vpu_share node.
- Remove change to cros_ec_commands.h (That is already in
https://lore.kernel.org/lkml/20190518063949.GY4319@dell/T/)
Changes from v8:
- Rebased onto https://patchwork.kernel.org/cover/10962385/.
- Drop merged cros_ec_rpmsg patch, and add scp dts node patch.
- Add more reserved memory region.
Changes from v7:
- Rebase onto https://lore.kernel.org/patchwork/patch/1059196/.
- Fix clock enable/disable timing for SCP driver.
- Add more SCP IPI ID.
Changes from v6:
- Decouple mtk_rpmsg from mtk_scp.
- Change data of EC response to be aligned to 4 bytes.
Changes from v5:
- Add device tree binding document for cros_ec_rpmsg.
- Better document in comments for cros_ec_rpmsg.
- Remove dependency on CONFIG_ in binding tree document.
Changes from v4:
- Merge patch 6 (Load ELF firmware) into patch 2, so the driver loads
ELF firmware by default, and no longer accept plain binary.
- rpmsg_device listed in device tree (as a child of the SCP node) would
have it's device tree node mapped to the rpmsg_device, so the rpmsg
driver can use the properties on device tree.
Changes from v3:
- Make writing to SCP SRAM aligned.
- Add a new patch (Patch 6) to load ELF instead of bin firmware.
- Add host event support for EC driver.
- Fix some bugs found in testing (missing spin_lock_init,
rproc_subdev_unprepare to rproc_subdev_stop).
- Fix some coding style issue found by checkpatch.pl.
Changes from v2:
- Fold patch 3 into patch 2 in v2.
- Move IPI id around to support cross-testing for old and new firmware.
- Finish more TODO items.
Changes from v1:
- Extract functions and rename variables in mtk_scp.c.
- Do cleanup properly in mtk_rpmsg.c, which also removes the problem of
short-lived work items.
- Code format fix based on feedback for cros_ec_rpmsg.c.
- Extract feature detection for SCP into separate patch (Patch 6).
Eddie Huang (1):
arm64: dts: mt8183: add scp node
Erin Lo (3):
dt-bindings: Add a binding for Mediatek SCP
remoteproc/mediatek: add SCP support for mt8183
remoteproc: mt8183: add reserved memory manager API
Pi-Hsun Shih (1):
rpmsg: add rpmsg support for mt8183 SCP.
.../bindings/remoteproc/mtk,scp.txt | 36 +
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 11 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 12 +
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/mtk_common.h | 92 +++
drivers/remoteproc/mtk_scp.c | 710 ++++++++++++++++++
drivers/remoteproc/mtk_scp_ipi.c | 159 ++++
drivers/rpmsg/Kconfig | 9 +
drivers/rpmsg/Makefile | 1 +
drivers/rpmsg/mtk_rpmsg.c | 414 ++++++++++
include/linux/remoteproc/mtk_scp.h | 168 +++++
include/linux/rpmsg/mtk_rpmsg.h | 38 +
13 files changed, 1661 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
create mode 100644 drivers/remoteproc/mtk_common.h
create mode 100644 drivers/remoteproc/mtk_scp.c
create mode 100644 drivers/remoteproc/mtk_scp_ipi.c
create mode 100644 drivers/rpmsg/mtk_rpmsg.c
create mode 100644 include/linux/remoteproc/mtk_scp.h
create mode 100644 include/linux/rpmsg/mtk_rpmsg.h
--
2.22.0.770.g0f2c4a37fd-goog
^ permalink raw reply
* [PATCH v15 1/5] dt-bindings: Add a binding for Mediatek SCP
From: Pi-Hsun Shih @ 2019-08-07 10:43 UTC (permalink / raw)
Cc: Pi-Hsun Shih, Erin Lo, Rob Herring, Ohad Ben-Cohen,
Bjorn Andersson, Rob Herring, Mark Rutland, Matthias Brugger,
open list:REMOTE PROCESSOR REMOTEPROC SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, open list
In-Reply-To: <20190807104352.259767-1-pihsun@chromium.org>
From: Erin Lo <erin.lo@mediatek.com>
Add a DT binding documentation of SCP for the
MT8183 SoC from Mediatek.
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes from v14, v13, v12, v11, v10, v9, v8, v7, v6:
- No change.
Changes from v5:
- Remove dependency on CONFIG_RPMSG_MTK_SCP.
Changes from v4:
- Add detail of more properties.
- Document the usage of mtk,rpmsg-name in subnode from the new design.
Changes from v3:
- No change.
Changes from v2:
- No change. I realized that for this patch series, there's no need to
add anything under the mt8183-scp node (neither the mt8183-rpmsg or
the cros-ec-rpmsg) for them to work, since mt8183-rpmsg is added
directly as a rproc_subdev by code, and cros-ec-rpmsg is dynamically
created by SCP name service.
Changes from v1:
- No change.
---
.../bindings/remoteproc/mtk,scp.txt | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
new file mode 100644
index 000000000000..3ba668bab14b
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
@@ -0,0 +1,36 @@
+Mediatek SCP Bindings
+----------------------------------------
+
+This binding provides support for ARM Cortex M4 Co-processor found on some
+Mediatek SoCs.
+
+Required properties:
+- compatible Should be "mediatek,mt8183-scp"
+- reg Should contain the address ranges for the two memory
+ regions, SRAM and CFG.
+- reg-names Contains the corresponding names for the two memory
+ regions. These should be named "sram" & "cfg".
+- clocks Clock for co-processor (See: ../clock/clock-bindings.txt)
+- clock-names Contains the corresponding name for the clock. This
+ should be named "main".
+
+Subnodes
+--------
+
+Subnodes of the SCP represent rpmsg devices. The names of the devices are not
+important. The properties of these nodes are defined by the individual bindings
+for the rpmsg devices - but must contain the following property:
+
+- mtk,rpmsg-name Contains the name for the rpmsg device. Used to match
+ the subnode to rpmsg device announced by SCP.
+
+Example:
+
+ scp: scp@10500000 {
+ compatible = "mediatek,mt8183-scp";
+ reg = <0 0x10500000 0 0x80000>,
+ <0 0x105c0000 0 0x5000>;
+ reg-names = "sram", "cfg";
+ clocks = <&infracfg CLK_INFRA_SCPSYS>;
+ clock-names = "main";
+ };
--
2.22.0.770.g0f2c4a37fd-goog
^ permalink raw reply related
* [PATCH v15 5/5] arm64: dts: mt8183: add scp node
From: Pi-Hsun Shih @ 2019-08-07 10:43 UTC (permalink / raw)
Cc: Pi-Hsun Shih, Eddie Huang, Erin Lo, Rob Herring, Mark Rutland,
Matthias Brugger,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, open list
In-Reply-To: <20190807104352.259767-1-pihsun@chromium.org>
From: Eddie Huang <eddie.huang@mediatek.com>
Add scp node to mt8183 and mt8183-evb
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Signed-off-by: Eddie Huang <eddie.huang@mediatek.com>
---
Changes from v14:
- No change.
Changes from v13:
- Change the size of the cfg register region.
Changes from v12, v11, v10:
- No change.
Changes from v9:
- Remove extra reserve-memory-vpu_share node.
Changes from v8:
- New patch.
---
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 11 +++++++++++
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 12 ++++++++++++
2 files changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index d8e555cbb5d3..e46e34ce3159 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -24,6 +24,17 @@
chosen {
stdout-path = "serial0:921600n8";
};
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ scp_mem_reserved: scp_mem_region {
+ compatible = "shared-dma-pool";
+ reg = <0 0x50000000 0 0x2900000>;
+ no-map;
+ };
+ };
};
&auxadc {
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index c2749c4631bc..871754c2f477 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -254,6 +254,18 @@
clock-names = "spi", "wrap";
};
+ scp: scp@10500000 {
+ compatible = "mediatek,mt8183-scp";
+ reg = <0 0x10500000 0 0x80000>,
+ <0 0x105c0000 0 0x19080>;
+ reg-names = "sram", "cfg";
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&infracfg CLK_INFRA_SCPSYS>;
+ clock-names = "main";
+ memory-region = <&scp_mem_reserved>;
+ status = "disabled";
+ };
+
auxadc: auxadc@11001000 {
compatible = "mediatek,mt8183-auxadc",
"mediatek,mt8173-auxadc";
--
2.22.0.770.g0f2c4a37fd-goog
^ permalink raw reply related
* Re: [PATCH v3 09/21] ARM: dts: imx6qdl-colibri: add phy to fec
From: Uwe Kleine-König @ 2019-08-07 10:51 UTC (permalink / raw)
To: Philippe Schenker
Cc: Marcel Ziswiler, Max Krummenacher, stefan@agner.ch,
devicetree@vger.kernel.org, Rob Herring, Shawn Guo, Mark Rutland,
Michal Vokáč, Fabio Estevam, Sascha Hauer,
linux-kernel@vger.kernel.org, NXP Linux Team,
Pengutronix Kernel Team, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190807082556.5013-10-philippe.schenker@toradex.com>
On Wed, Aug 07, 2019 at 08:26:23AM +0000, Philippe Schenker wrote:
> Add the phy-node and mdio bus to the fec-node, represented as is on
> hardware.
> This commit includes micrel,led-mode that is set to the default
> value, prepared for someone who wants to change this.
>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/boot/dts/imx6qdl-colibri.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-colibri.dtsi b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> index 1beac22266ed..019dda6b88ad 100644
> --- a/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> @@ -140,7 +140,18 @@
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_enet>;
> phy-mode = "rmii";
> + phy-handle = <ðphy>;
> status = "okay";
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy: ethernet-phy@0 {
> + reg = <0>;
> + micrel,led-mode = <0>;
Doesn't that need a compatible entry to be actually used?
Best regards
Uwe
>
>
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] ARM: dts: dra74x: Fix iodelay configuration for mmc3
From: Faiz Abbas @ 2019-08-07 10:52 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-omap
Cc: mark.rutland, robh+dt, tony, bcousson, kishon, faiz_abbas
According to the latest am572x[1] and dra74x[2] data manuals, mmc3
default, hs, sdr12 and sdr25 modes use iodelay values given in
MMC3_MANUAL1. Set the MODE_SELECT bit for these so that manual mode is
selected and correct iodelay values can be configured.
[1] http://www.ti.com/lit/ds/symlink/am5728.pdf
[2] http://www.ti.com/lit/ds/symlink/dra746.pdf
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi | 50 +++++++++++------------
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi b/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
index 28ebb4eb884a..214b9e6de2c3 100644
--- a/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
+++ b/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
@@ -32,7 +32,7 @@
*
* Datamanual Revisions:
*
- * AM572x Silicon Revision 2.0: SPRS953B, Revised November 2016
+ * AM572x Silicon Revision 2.0: SPRS953F, Revised May 2019
* AM572x Silicon Revision 1.1: SPRS915R, Revised November 2016
*
*/
@@ -229,45 +229,45 @@
mmc3_pins_default: mmc3_pins_default {
pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x377c, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_clk.mmc3_clk */
- DRA7XX_CORE_IOPAD(0x3780, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_cmd.mmc3_cmd */
- DRA7XX_CORE_IOPAD(0x3784, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat0.mmc3_dat0 */
- DRA7XX_CORE_IOPAD(0x3788, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat1.mmc3_dat1 */
- DRA7XX_CORE_IOPAD(0x378c, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat2.mmc3_dat2 */
- DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat3.mmc3_dat3 */
+ DRA7XX_CORE_IOPAD(0x377c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_clk.mmc3_clk */
+ DRA7XX_CORE_IOPAD(0x3780, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_cmd.mmc3_cmd */
+ DRA7XX_CORE_IOPAD(0x3784, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat0.mmc3_dat0 */
+ DRA7XX_CORE_IOPAD(0x3788, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat1.mmc3_dat1 */
+ DRA7XX_CORE_IOPAD(0x378c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat2.mmc3_dat2 */
+ DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat3.mmc3_dat3 */
>;
};
mmc3_pins_hs: mmc3_pins_hs {
pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x377c, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_clk.mmc3_clk */
- DRA7XX_CORE_IOPAD(0x3780, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_cmd.mmc3_cmd */
- DRA7XX_CORE_IOPAD(0x3784, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat0.mmc3_dat0 */
- DRA7XX_CORE_IOPAD(0x3788, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat1.mmc3_dat1 */
- DRA7XX_CORE_IOPAD(0x378c, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat2.mmc3_dat2 */
- DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat3.mmc3_dat3 */
+ DRA7XX_CORE_IOPAD(0x377c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_clk.mmc3_clk */
+ DRA7XX_CORE_IOPAD(0x3780, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_cmd.mmc3_cmd */
+ DRA7XX_CORE_IOPAD(0x3784, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat0.mmc3_dat0 */
+ DRA7XX_CORE_IOPAD(0x3788, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat1.mmc3_dat1 */
+ DRA7XX_CORE_IOPAD(0x378c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat2.mmc3_dat2 */
+ DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat3.mmc3_dat3 */
>;
};
mmc3_pins_sdr12: mmc3_pins_sdr12 {
pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x377c, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_clk.mmc3_clk */
- DRA7XX_CORE_IOPAD(0x3780, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_cmd.mmc3_cmd */
- DRA7XX_CORE_IOPAD(0x3784, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat0.mmc3_dat0 */
- DRA7XX_CORE_IOPAD(0x3788, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat1.mmc3_dat1 */
- DRA7XX_CORE_IOPAD(0x378c, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat2.mmc3_dat2 */
- DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat3.mmc3_dat3 */
+ DRA7XX_CORE_IOPAD(0x377c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_clk.mmc3_clk */
+ DRA7XX_CORE_IOPAD(0x3780, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_cmd.mmc3_cmd */
+ DRA7XX_CORE_IOPAD(0x3784, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat0.mmc3_dat0 */
+ DRA7XX_CORE_IOPAD(0x3788, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat1.mmc3_dat1 */
+ DRA7XX_CORE_IOPAD(0x378c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat2.mmc3_dat2 */
+ DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat3.mmc3_dat3 */
>;
};
mmc3_pins_sdr25: mmc3_pins_sdr25 {
pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x377c, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_clk.mmc3_clk */
- DRA7XX_CORE_IOPAD(0x3780, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_cmd.mmc3_cmd */
- DRA7XX_CORE_IOPAD(0x3784, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat0.mmc3_dat0 */
- DRA7XX_CORE_IOPAD(0x3788, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat1.mmc3_dat1 */
- DRA7XX_CORE_IOPAD(0x378c, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat2.mmc3_dat2 */
- DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MUX_MODE0)) /* mmc3_dat3.mmc3_dat3 */
+ DRA7XX_CORE_IOPAD(0x377c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_clk.mmc3_clk */
+ DRA7XX_CORE_IOPAD(0x3780, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_cmd.mmc3_cmd */
+ DRA7XX_CORE_IOPAD(0x3784, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat0.mmc3_dat0 */
+ DRA7XX_CORE_IOPAD(0x3788, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat1.mmc3_dat1 */
+ DRA7XX_CORE_IOPAD(0x378c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat2.mmc3_dat2 */
+ DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat3.mmc3_dat3 */
>;
};
--
2.19.2
^ permalink raw reply related
* Re: [PATCH 0/3] Add basic support for RTC on Allwinner H6 SoC
From: Alexandre Belloni @ 2019-08-07 10:55 UTC (permalink / raw)
To: Chen-Yu Tsai, Mark Rutland, Alessandro Zummo, devicetree,
Maxime Ripard, linux-kernel, linux-sunxi, Rob Herring,
linux-arm-kernel, linux-rtc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20190806183045.edhm3qzpegscf2z7-9v8tmBix7cb9zxVx7UNMDg@public.gmane.org>
Hi,
On 06/08/2019 20:30:45+0200, Ondřej Jirman wrote:
> Maybe whether XO or DCXO is used also matters if you want to do some fine
> tunning of DCXO (control register has pletny of options), but that's probably
> better done in u-boot. And there's still no need to read HOSC source from DT.
> The driver can just check compatible, and if it is H6 and OSC_CLK_SRC_SEL is 1,
> it can do it's DCXO tunning, or whatever. But neither OS nor bootloader will
> be using this info to gate/disable the osciallator.
>
It is actually useful to be able to tweak the crystal tuning at
runtime to be able to reduce clock drift and compare with a reliable
source (e.g. NTP).
I'm curious, what kind of options does this RTC have?
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190807105502.GK3600%40piout.net.
^ permalink raw reply
* Re: [v2,0/2] PCI: mediatek: Add support for MT7629
From: Lorenzo Pieralisi @ 2019-08-07 10:57 UTC (permalink / raw)
To: Jianjun Wang
Cc: Ryder Lee, Bjorn Helgaas, Rob Herring, Mark Rutland,
Matthias Brugger, linux-pci, linux-mediatek, devicetree,
linux-kernel, linux-arm-kernel, youlin.pei
In-Reply-To: <20190628073425.25165-1-jianjun.wang@mediatek.com>
On Fri, Jun 28, 2019 at 03:34:23PM +0800, Jianjun Wang wrote:
> These series patches modify pcie-mediatek.c and dt-bindings compatible
> string to support MT7629 PCIe host.
>
> Jianjun Wang (2):
> dt-bindings: PCI: Add support for MT7629
> PCI: mediatek: Add controller support for MT7629
>
> .../devicetree/bindings/pci/mediatek-pcie.txt | 1 +
> drivers/pci/controller/pcie-mediatek.c | 18 ++++++++++++++++++
> include/linux/pci_ids.h | 1 +
> 3 files changed, 20 insertions(+)
Applied to pci/mediatek for v5.4.
Thanks,
Lorenzo
^ permalink raw reply
* Re: [PATCH 1/4] mailbox: arm_mhuv2: add device tree binding documentation
From: Tushar Khandelwal @ 2019-08-07 11:11 UTC (permalink / raw)
To: Sudeep Holla, Jassi Brar
Cc: Linux Kernel Mailing List, tushar.2nov@gmail.com,
morten_bp@live.dk, nd, Morten Petersen, Rob Herring, Mark Rutland,
Devicetree List
In-Reply-To: <20190802105357.GF23424@e107155-lin>
On 02/08/2019, 11:54, "Sudeep Holla" <sudeep.holla@arm.com> wrote:
On Thu, Jul 25, 2019 at 12:49:58AM -0500, Jassi Brar wrote:
> On Sun, Jul 21, 2019 at 4:58 PM Jassi Brar <jassisinghbrar@gmail.com> wrote:
> >
[...]
> > If the mhuv2 instance implements, say, 3 channel windows between
> > sender (linux) and receiver (firmware), and Linux runs two protocols
> > each requiring 1 and 2-word sized messages respectively. The hardware
> > supports that by assigning windows [0] and [1,2] to each protocol.
> > However, I don't think the driver can support that. Or does it?
> >
> Thinking about it, IMO, the mbox-cell should carry a 128 (4x32) bit
> mask specifying the set of windows (corresponding to the bits set in
> the mask) associated with the channel.
> And the controller driver should see any channel as associated with
> variable number of windows 'N', where N is [0,124]
>
> mhu_client1: proto1@2e000000 {
> .....
> mboxes = <&mbox 0x0 0x0 0x0 0x1>
> }
>
> mhu_client2: proto2@2f000000 {
> .....
> mboxes = <&mbox 0x0 0x0 0x0 0x6>
> }
>
This still doesn't address the overhead I mentioned in my arm_mhu_v1
series.
As per you suggestion, we will have one channel with all possible
bit mask value to specify the window. Let's imagine that 2 protocols
share the same channel, then the requests are serialised.
E.g. if bits 0 and 1 are allocated for say protocol#1 and bits 2 and 3
for protocol#2.
At a given time only one protocol can be used by a client. No mix-match
of protocols are handled by the driver currently. Also its not possible to address all
possible scenarios offered by the IP. That's why the current driver design is
based on the implementation in the existing platforms.
Further protocol#1 has higher latency requirements like sched-governor
DVFS and there are 3-4 pending requests on protocol#2, then the incoming
requests for protocol#1 is blocked.
This is definitely overhead and I have seen lots of issue around this
and hence I was requesting that we need to create individual channels
for each of these. Having abstraction on top to multiplex or arbitrate
won't help.
Also the (mbox-cells) approach will not allow us to differentiate between
single-word and doorbell which is required to make the controller driver
aware of the data expected whether it's a pointer to a location or in
register itself.
--Tushar
--
Regards,
Sudeep
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: a64: Drop PMU node
From: Mark Rutland @ 2019-08-07 11:12 UTC (permalink / raw)
To: Robin Murphy
Cc: devicetree, Jared D . McNeill, Maxime Ripard, Chen-Yu Tsai,
Rob Herring, Harald Geyer, arm-linux
In-Reply-To: <36e60078-7dd5-9c07-ffa1-6092d8c70fa8@arm.com>
On Tue, Aug 06, 2019 at 10:14:39PM +0100, Robin Murphy wrote:
> On 2019-08-06 9:52 pm, Vasily Khoruzhick wrote:
> > On Tue, Aug 6, 2019 at 1:19 PM Harald Geyer <harald@ccbib.org> wrote:
> > >
> > > Vasily Khoruzhick writes:
> > > > On Tue, Aug 6, 2019 at 7:35 AM Robin Murphy <robin.murphy@arm.com> wrote:
> > > > >
> > > > > On 06/08/2019 15:01, Vasily Khoruzhick wrote:
> > > > > > Looks like PMU in A64 is broken, it generates no interrupts at all and
> > > > > > as result 'perf top' shows no events.
> > > > >
> > > > > Does something like 'perf stat sleep 1' at least count cycles correctly?
> > > > > It could well just be that the interrupt numbers are wrong...
> > > >
> > > > Looks like it does, at least result looks plausible:
> > >
> > > I'm using perf stat regularly (cache benchmarks) and it works fine.
> > >
> > > Unfortunately I wasn't aware that perf stat is a poor test for
> > > the interrupts part of the node, when I added it. So I'm not too
> > > surprised I got it wrong.
> > >
> > > However, it would be unfortunate if the node got removed completely,
> > > because perf stat would not work anymore. Maybe we can only remove
> > > the interrupts or just fix them even if the HW doesn't work?
> >
> > I'm not familiar with PMU driver. Is it possible to get it working
> > without interrupts?
>
> Yup - you get a grumpy message from the driver, it will refuse sampling
> events (the ones which weren't working anyway), and if you measure anything
> for long enough that a counter overflows you'll get wonky results. But for
> counting hardware events over relatively short periods it'll still do the
> job.
Even that's stupidly dodgy; a CPU_CYCLES event could easily overflow
several times between the kernel sampling it, so you can lose billions
of events without any idea that happened.
For other PMUs we can fix that with a hrtimer, but I think for a CPU PMU
it has to be at such a high frequency that it imposes a ridiculous
overhead, even assuming we can choose a sufficient frequency. :/
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH 1/4] mailbox: arm_mhuv2: add device tree binding documentation
From: Tushar Khandelwal @ 2019-08-07 11:17 UTC (permalink / raw)
To: Sudeep Holla, Jassi Brar
Cc: Linux Kernel Mailing List, tushar.2nov@gmail.com,
morten_bp@live.dk, nd, Morten Petersen, Rob Herring, Mark Rutland,
Devicetree List
In-Reply-To: <20190802105938.GG23424@e107155-lin>
On 02/08/2019, 11:59, "Sudeep Holla" <sudeep.holla@arm.com> wrote:
On Sun, Jul 21, 2019 at 04:58:04PM -0500, Jassi Brar wrote:
> On Wed, Jul 17, 2019 at 2:26 PM Tushar Khandelwal
> <tushar.khandelwal@arm.com> wrote:
>
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
> > new file mode 100644
> > index 000000000000..3a05593414bc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
> > @@ -0,0 +1,108 @@
> > +Arm MHUv2 Mailbox Driver
> > +========================
> > +
> > +The Arm Message-Handling-Unit (MHU) Version 2 is a mailbox controller that has
> > +between 1 and 124 channel windows to provide unidirectional communication with
> > +remote processor(s).
> > +
> > +Given the unidirectional nature of the device, an MHUv2 mailbox may only be
> > +written to or read from. If a pair of MHU devices is implemented between two
> > +processing elements to provide bidirectional communication, these must be
> > +specified as two separate mailboxes.
> > +
> > +A device tree node for an Arm MHUv2 device must specify either a receiver frame
> > +or a sender frame, indicating which end of the unidirectional MHU device which
> > +the device node entry describes.
> > +
> > +An MHU device must be specified with a transport protocol. The transport
> > +protocol of an MHU device determines the method of data transmission as well as
> > +the number of provided mailboxes.
> > +Following are the possible transport protocol types:
> > +- Single-word: An MHU device implements as many mailboxes as it
> > + provides channel windows. Data is transmitted through
> > + the MHU registers.
> > +- Multi-word: An MHU device implements a single mailbox. All channel windows
> > + will be used during transmission. Data is transmitted through
> > + the MHU registers.
> > +- Doorbell: An MHU device implements as many mailboxes as there are flag
> > + bits available in its channel windows. Optionally, data may
> > + be transmitted through a shared memory region, wherein the MHU
> > + is used strictly as an interrupt generation mechanism.
> > +
> > +Mailbox Device Node:
> > +====================
> > +
> > +Required properties:
> > +--------------------
> > +- compatible: Shall be "arm,mhuv2" & "arm,primecell"
> > +- reg: Contains the mailbox register address range (base
> > + address and length)
> > +- #mbox-cells Shall be 1 - the index of the channel needed.
> > +- mhu-frame Frame type of the device.
> > + Shall be either "sender" or "receiver"
> > +- mhu-protocol Transport protocol of the device. Shall be one of the
> > + following: "single-word", "multi-word", "doorbell"
> > +
> > +Required properties (receiver frame):
> > +-------------------------------------
> > +- interrupts: Contains the interrupt information corresponding to the
> > + combined interrupt of the receiver frame
> > +
> > +Example:
> > +--------
> > +
> > + mbox_mw_tx: mhu@10000000 {
> > + compatible = "arm,mhuv2","arm,primecell";
> > + reg = <0x10000000 0x1000>;
> > + clocks = <&refclk100mhz>;
> > + clock-names = "apb_pclk";
> > + #mbox-cells = <1>;
> > + mhu-protocol = "multi-word";
> > + mhu-frame = "sender";
> > + };
> > +
> > + mbox_sw_tx: mhu@10000000 {
> > + compatible = "arm,mhuv2","arm,primecell";
> > + reg = <0x11000000 0x1000>;
> > + clocks = <&refclk100mhz>;
> > + clock-names = "apb_pclk";
> > + #mbox-cells = <1>;
> > + mhu-protocol = "single-word";
> > + mhu-frame = "sender";
> > + };
> > +
> > + mbox_db_rx: mhu@10000000 {
> > + compatible = "arm,mhuv2","arm,primecell";
> > + reg = <0x12000000 0x1000>;
> > + clocks = <&refclk100mhz>;
> > + clock-names = "apb_pclk";
> > + #mbox-cells = <1>;
> > + interrupts = <0 45 4>;
> > + interrupt-names = "mhu_rx";
> > + mhu-protocol = "doorbell";
> > + mhu-frame = "receiver";
> > + };
> > +
> > + mhu_client: scb@2e000000 {
> > + compatible = "fujitsu,mb86s70-scb-1.0";
> > + reg = <0 0x2e000000 0x4000>;
> > + mboxes =
> > + // For multi-word frames, client may only instantiate a single
> > + // mailbox for a mailbox controller
> > + <&mbox_mw_tx 0>,
> > +
> > + // For single-word frames, client may instantiate as many
> > + // mailboxes as there are channel windows in the MHU
> > + <&mbox_sw_tx 0>,
> > + <&mbox_sw_tx 1>,
> > + <&mbox_sw_tx 2>,
> > + <&mbox_sw_tx 3>,
> > +
> > + // For doorbell frames, client may instantiate as many mailboxes
> > + // as there are bits available in the combined number of channel
> > + // windows ((channel windows * 32) mailboxes)
> > + <mbox_db_rx 0>,
> > + <mbox_db_rx 1>,
> > + ...
> > + <mbox_db_rx 17>;
> > + };
>
> If the mhuv2 instance implements, say, 3 channel windows between
> sender (linux) and receiver (firmware), and Linux runs two protocols
> each requiring 1 and 2-word sized messages respectively. The hardware
> supports that by assigning windows [0] and [1,2] to each protocol.
> However, I don't think the driver can support that. Or does it?
>
FWIW, the IP is designed to cover wide range of usecase from IoT to servers
with variable window length. I don't see the need to complicate the driver
supporting mix-n-match at the cost of latency. Each platform choose one
transport protocol for all it's use.
The driver design is to address the most probable scenarios and not all.
Single-word : Client gets one 32-bit window
Doorbell : Client gets 32 data pointers (arm_message)
Multi-word: Client gets all channels available in the platform.
--Tushar
--
Regards,
Sudeep
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* Re: [PATCH v3 07/21] ARM: dts: imx7-colibri: fix 1.8V/UHS support
From: Fabio Estevam @ 2019-08-07 11:19 UTC (permalink / raw)
To: Philippe Schenker
Cc: Marcel Ziswiler, Max Krummenacher, stefan@agner.ch,
devicetree@vger.kernel.org, Rob Herring, Shawn Guo, Mark Rutland,
Michal Vokáč, Stefan Agner,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Pengutronix Kernel Team,
NXP Linux Team, Sascha Hauer
In-Reply-To: <20190807082556.5013-8-philippe.schenker@toradex.com>
Hi Philippe,
On Wed, Aug 7, 2019 at 5:26 AM Philippe Schenker
<philippe.schenker@toradex.com> wrote:
>
> From: Stefan Agner <stefan.agner@toradex.com>
>
> Add pinmuxing and do not specify voltage restrictions for the usdhc
> instance available on the modules edge connector. This allows to use
> SD-cards with higher transfer modes if supported by the carrier board.
>
> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
>
> ---
>
> Changes in v3:
> - Add new commit message from Stefan's proposal on ML
The commit message has been improved, but there is also another point
I mentioned earlier:
>
> Changes in v2: None
>
> arch/arm/boot/dts/imx7-colibri.dtsi | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
> index 16d1a1ed1aff..67f5e0c87fdc 100644
> --- a/arch/arm/boot/dts/imx7-colibri.dtsi
> +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
> @@ -326,7 +326,6 @@
> &usdhc1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usdhc1 &pinctrl_cd_usdhc1>;
> - no-1-8-v;
> cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
> disable-wp;
> vqmmc-supply = <®_LDO2>;
> @@ -671,6 +670,28 @@
> >;
> };
>
> + pinctrl_usdhc1_100mhz: usdhc1grp_100mhz {
This new entry has been added and it is not referenced.
> + fsl,pins = <
> + MX7D_PAD_SD1_CMD__SD1_CMD 0x5a
> + MX7D_PAD_SD1_CLK__SD1_CLK 0x1a
> + MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5a
> + MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5a
> + MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5a
> + MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5a
> + >;
> + };
> +
> + pinctrl_usdhc1_200mhz: usdhc1grp_200mhz {
Same here.
^ permalink raw reply
* [PATCH 0/2] Add OSM L3 Interconnect Provider
From: Sibi Sankar @ 2019-08-07 11:24 UTC (permalink / raw)
To: robh+dt, georgi.djakov
Cc: bjorn.andersson, agross, linux-kernel, devicetree, linux-arm-msm,
mark.rutland, evgreen, daidavid1, saravanak, Sibi Sankar
This patch series aims to add Operating State Manager (OSM) L3
interconnect provider support on SDM845 SoCs to handle bandwidth
requests from CPU/GPU to scale L3 caches.
Sibi Sankar (2):
dt-bindings: interconnect: Add OSM L3 DT bindings
interconnect: qcom: Add OSM L3 interconnect provider support
.../bindings/interconnect/qcom,osm-l3.yaml | 55 ++++
drivers/interconnect/qcom/Kconfig | 7 +
drivers/interconnect/qcom/Makefile | 2 +
drivers/interconnect/qcom/osm-l3.c | 292 ++++++++++++++++++
.../dt-bindings/interconnect/qcom,osm-l3.h | 13 +
5 files changed, 369 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
create mode 100644 drivers/interconnect/qcom/osm-l3.c
create mode 100644 include/dt-bindings/interconnect/qcom,osm-l3.h
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 1/2] dt-bindings: interconnect: Add OSM L3 DT bindings
From: Sibi Sankar @ 2019-08-07 11:24 UTC (permalink / raw)
To: robh+dt, georgi.djakov
Cc: bjorn.andersson, agross, linux-kernel, devicetree, linux-arm-msm,
mark.rutland, evgreen, daidavid1, saravanak, Sibi Sankar
In-Reply-To: <20190807112432.26521-1-sibis@codeaurora.org>
Add bindings for Operating State Manager (OSM) L3 interconnect provider
on SDM845 SoCs.
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
.../bindings/interconnect/qcom,osm-l3.yaml | 55 +++++++++++++++++++
.../dt-bindings/interconnect/qcom,osm-l3.h | 13 +++++
2 files changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
create mode 100644 include/dt-bindings/interconnect/qcom,osm-l3.h
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
new file mode 100644
index 0000000000000..51a4722e1a69f
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,osm-l3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Operating State Manager (OSM) L3 Interconnect Provider
+
+maintainers:
+ - Sibi Sankar <sibis@codeaurora.org>
+
+description:
+ L3 cache bandwidth requirements on Qualcomm SoCs is serviced by the OSM.
+ The OSM L3 interconnect provider aggregates the L3 bandwidth requests
+ from CPU/GPU and relays it to the OSM.
+
+properties:
+ compatible:
+ const: "qcom,sdm845-osm-l3"
+
+ reg:
+ maxItems: 1
+ description: OSM L3 registers
+
+ clocks:
+ items:
+ - description: xo clock
+ - description: alternate clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: alternate
+
+ '#interconnect-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clocks-names
+ - '#interconnect-cells'
+
+examples:
+ - |
+ osm_l3: interconnect@17d41000 {
+ compatible = "qcom,sdm845-osm-l3";
+ reg = <0 0x17d41000 0 0x1400>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+ clock-names = "xo", "alternate";
+
+ #interconnect-cells = <1>;
+ };
diff --git a/include/dt-bindings/interconnect/qcom,osm-l3.h b/include/dt-bindings/interconnect/qcom,osm-l3.h
new file mode 100644
index 0000000000000..6662134c84248
--- /dev/null
+++ b/include/dt-bindings/interconnect/qcom,osm-l3.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 The Linux Foundation. All rights reserved.
+ */
+
+#ifndef __DT_BINDINGS_INTERCONNECT_QCOM_OSM_L3_H
+#define __DT_BINDINGS_INTERCONNECT_QCOM_OSM_L3_H
+
+#define MASTER_OSM_L3_APPS 0
+#define MASTER_OSM_L3_GPU 1
+#define SLAVE_OSM_L3 2
+
+#endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 2/2] interconnect: qcom: Add OSM L3 interconnect provider support
From: Sibi Sankar @ 2019-08-07 11:24 UTC (permalink / raw)
To: robh+dt, georgi.djakov
Cc: bjorn.andersson, agross, linux-kernel, devicetree, linux-arm-msm,
mark.rutland, evgreen, daidavid1, saravanak, Sibi Sankar
In-Reply-To: <20190807112432.26521-1-sibis@codeaurora.org>
On some Qualcomm SoCs, Operating State Manager (OSM) controls the
resources of scaling L3 caches. Add a driver to handle bandwidth
requests to OSM L3 from CPU/GPU.
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
drivers/interconnect/qcom/Kconfig | 7 +
drivers/interconnect/qcom/Makefile | 2 +
drivers/interconnect/qcom/osm-l3.c | 292 +++++++++++++++++++++++++++++
3 files changed, 301 insertions(+)
create mode 100644 drivers/interconnect/qcom/osm-l3.c
diff --git a/drivers/interconnect/qcom/Kconfig b/drivers/interconnect/qcom/Kconfig
index d5e70ebc24108..f6c2a11a1a2c9 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -5,6 +5,13 @@ config INTERCONNECT_QCOM
help
Support for Qualcomm's Network-on-Chip interconnect hardware.
+config INTERCONNECT_QCOM_OSM_L3
+ tristate "Qualcomm OSM L3 interconnect driver"
+ depends on INTERCONNECT_QCOM || COMPILE_TEST
+ help
+ Say y here to support the Operating State Manager (OSM) interconnect
+ driver which controls the scaling of L3 caches on Qualcomm SoCs.
+
config INTERCONNECT_QCOM_SDM845
tristate "Qualcomm SDM845 interconnect driver"
depends on INTERCONNECT_QCOM
diff --git a/drivers/interconnect/qcom/Makefile b/drivers/interconnect/qcom/Makefile
index 1c1cea690f922..9078af5fed109 100644
--- a/drivers/interconnect/qcom/Makefile
+++ b/drivers/interconnect/qcom/Makefile
@@ -1,5 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
+icc-osm-l3-objs := osm-l3.o
qnoc-sdm845-objs := sdm845.o
+obj-$(CONFIG_INTERCONNECT_QCOM_OSM_L3) += icc-osm-l3.o
obj-$(CONFIG_INTERCONNECT_QCOM_SDM845) += qnoc-sdm845.o
diff --git a/drivers/interconnect/qcom/osm-l3.c b/drivers/interconnect/qcom/osm-l3.c
new file mode 100644
index 0000000000000..1e7dfce6f4f9b
--- /dev/null
+++ b/drivers/interconnect/qcom/osm-l3.c
@@ -0,0 +1,292 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ *
+ */
+
+#include <dt-bindings/interconnect/qcom,osm-l3.h>
+#include <dt-bindings/interconnect/qcom,sdm845.h>
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/interconnect-provider.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#define LUT_MAX_ENTRIES 40U
+#define LUT_SRC GENMASK(31, 30)
+#define LUT_L_VAL GENMASK(7, 0)
+#define LUT_ROW_SIZE 32
+#define CLK_HW_DIV 2
+
+/* Register offsets */
+#define REG_ENABLE 0x0
+#define REG_FREQ_LUT 0x110
+#define REG_PERF_STATE 0x920
+
+#define OSM_L3_MAX_LINKS 1
+
+#define to_qcom_provider(_provider) \
+ container_of(_provider, struct qcom_icc_provider, provider)
+
+enum {
+ SDM845_MASTER_OSM_L3_APPS = SLAVE_TCU + 1,
+ SDM845_MASTER_OSM_L3_GPU,
+ SDM845_SLAVE_OSM_L3,
+};
+
+struct qcom_icc_provider {
+ void __iomem *base;
+ unsigned int max_state;
+ unsigned long lut_tables[LUT_MAX_ENTRIES];
+ struct icc_provider provider;
+};
+
+/**
+ * struct qcom_icc_node - Qualcomm specific interconnect nodes
+ * @name: the node name used in debugfs
+ * @links: an array of nodes where we can go next while traversing
+ * @id: a unique node identifier
+ * @num_links: the total number of @links
+ * @buswidth: width of the interconnect between a node and the bus
+ */
+struct qcom_icc_node {
+ const char *name;
+ u16 links[OSM_L3_MAX_LINKS];
+ u16 id;
+ u16 num_links;
+ u16 buswidth;
+};
+
+struct qcom_icc_desc {
+ struct qcom_icc_node **nodes;
+ size_t num_nodes;
+};
+
+#define DEFINE_QNODE(_name, _id, _buswidth, ...) \
+ static struct qcom_icc_node _name = { \
+ .name = #_name, \
+ .id = _id, \
+ .buswidth = _buswidth, \
+ .num_links = ARRAY_SIZE(((int[]){ __VA_ARGS__ })), \
+ .links = { __VA_ARGS__ }, \
+ }
+
+DEFINE_QNODE(osm_apps_l3, SDM845_MASTER_OSM_L3_APPS, 16, SDM845_SLAVE_OSM_L3);
+DEFINE_QNODE(osm_gpu_l3, SDM845_MASTER_OSM_L3_GPU, 16, SDM845_SLAVE_OSM_L3);
+DEFINE_QNODE(osm_l3, SDM845_SLAVE_OSM_L3, 16);
+
+static struct qcom_icc_node *sdm845_osm_l3_nodes[] = {
+ [MASTER_OSM_L3_APPS] = &osm_apps_l3,
+ [MASTER_OSM_L3_GPU] = &osm_gpu_l3,
+ [SLAVE_OSM_L3] = &osm_l3,
+};
+
+static struct qcom_icc_desc sdm845_osm_l3 = {
+ .nodes = sdm845_osm_l3_nodes,
+ .num_nodes = ARRAY_SIZE(sdm845_osm_l3_nodes),
+};
+
+static int qcom_icc_aggregate(struct icc_node *node, u32 avg_bw,
+ u32 peak_bw, u32 *agg_avg, u32 *agg_peak)
+{
+ *agg_avg += avg_bw;
+ *agg_peak = max_t(u32, *agg_peak, peak_bw);
+
+ return 0;
+}
+
+static int qcom_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+ struct icc_provider *provider;
+ struct qcom_icc_provider *qp;
+ struct qcom_icc_node *qn;
+ struct icc_node *n;
+ unsigned int index;
+ u32 agg_peak = 0;
+ u32 agg_avg = 0;
+ u64 rate;
+
+ qn = src->data;
+ provider = src->provider;
+ qp = to_qcom_provider(provider);
+
+ list_for_each_entry(n, &provider->nodes, node_list)
+ qcom_icc_aggregate(n, n->avg_bw, n->peak_bw,
+ &agg_avg, &agg_peak);
+
+ rate = max(agg_avg, agg_peak);
+ rate = icc_units_to_bps(rate);
+ do_div(rate, qn->buswidth);
+
+ for (index = 0; index < qp->max_state; index++) {
+ if (qp->lut_tables[index] >= rate)
+ break;
+ }
+
+ writel_relaxed(index, qp->base + REG_PERF_STATE);
+
+ return 0;
+}
+
+static int qcom_osm_l3_probe(struct platform_device *pdev)
+{
+ u32 info, src, lval, i, prev_freq = 0, freq;
+ static unsigned long hw_rate, xo_rate;
+ const struct qcom_icc_desc *desc;
+ struct icc_onecell_data *data;
+ struct icc_provider *provider;
+ struct qcom_icc_node **qnodes;
+ struct qcom_icc_provider *qp;
+ struct icc_node *node;
+ size_t num_nodes;
+ struct clk *clk;
+ int ret;
+
+ clk = clk_get(&pdev->dev, "xo");
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ xo_rate = clk_get_rate(clk);
+ clk_put(clk);
+
+ clk = clk_get(&pdev->dev, "alternate");
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ hw_rate = clk_get_rate(clk) / CLK_HW_DIV;
+ clk_put(clk);
+
+ qp = devm_kzalloc(&pdev->dev, sizeof(*qp), GFP_KERNEL);
+ if (!qp)
+ return -ENOMEM;
+
+ qp->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(qp->base))
+ return PTR_ERR(qp->base);
+
+ /* HW should be in enabled state to proceed */
+ if (!(readl_relaxed(qp->base + REG_ENABLE) & 0x1)) {
+ dev_err(&pdev->dev, "error hardware not enabled\n");
+ return -ENODEV;
+ }
+
+ for (i = 0; i < LUT_MAX_ENTRIES; i++) {
+ info = readl_relaxed(qp->base + REG_FREQ_LUT +
+ i * LUT_ROW_SIZE);
+ src = FIELD_GET(LUT_SRC, info);
+ lval = FIELD_GET(LUT_L_VAL, info);
+ if (src)
+ freq = xo_rate * lval;
+ else
+ freq = hw_rate;
+
+ /*
+ * Two of the same frequencies with the same core counts means
+ * end of table
+ */
+ if (i > 0 && prev_freq == freq)
+ break;
+
+ qp->lut_tables[i] = freq;
+ prev_freq = freq;
+ }
+ qp->max_state = i;
+
+ desc = of_device_get_match_data(&pdev->dev);
+ if (!desc)
+ return -EINVAL;
+
+ qnodes = desc->nodes;
+ num_nodes = desc->num_nodes;
+
+ data = devm_kcalloc(&pdev->dev, num_nodes, sizeof(*node), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ provider = &qp->provider;
+ provider->dev = &pdev->dev;
+ provider->set = qcom_icc_set;
+ provider->aggregate = qcom_icc_aggregate;
+ provider->xlate = of_icc_xlate_onecell;
+ INIT_LIST_HEAD(&provider->nodes);
+ provider->data = data;
+
+ ret = icc_provider_add(provider);
+ if (ret) {
+ dev_err(&pdev->dev, "error adding interconnect provider\n");
+ return ret;
+ }
+
+ for (i = 0; i < num_nodes; i++) {
+ size_t j;
+
+ node = icc_node_create(qnodes[i]->id);
+ if (IS_ERR(node)) {
+ ret = PTR_ERR(node);
+ goto err;
+ }
+
+ node->name = qnodes[i]->name;
+ node->data = qnodes[i];
+ icc_node_add(node, provider);
+
+ dev_dbg(&pdev->dev, "registered node %p %s %d\n", node,
+ qnodes[i]->name, node->id);
+
+ /* populate links */
+ for (j = 0; j < qnodes[i]->num_links; j++)
+ icc_link_create(node, qnodes[i]->links[j]);
+
+ data->nodes[i] = node;
+ }
+ data->num_nodes = num_nodes;
+
+ platform_set_drvdata(pdev, qp);
+
+ return ret;
+err:
+ list_for_each_entry(node, &provider->nodes, node_list) {
+ icc_node_del(node);
+ icc_node_destroy(node->id);
+ }
+
+ icc_provider_del(provider);
+ return ret;
+}
+
+static int qcom_osm_l3_remove(struct platform_device *pdev)
+{
+ struct qcom_icc_provider *qp = platform_get_drvdata(pdev);
+ struct icc_provider *provider = &qp->provider;
+ struct icc_node *n;
+
+ list_for_each_entry(n, &provider->nodes, node_list) {
+ icc_node_del(n);
+ icc_node_destroy(n->id);
+ }
+
+ return icc_provider_del(provider);
+}
+
+static const struct of_device_id osm_l3_of_match[] = {
+ { .compatible = "qcom,sdm845-osm-l3", .data = &sdm845_osm_l3 },
+ { },
+};
+MODULE_DEVICE_TABLE(of, osm_l3_of_match);
+
+static struct platform_driver osm_l3_driver = {
+ .probe = qcom_osm_l3_probe,
+ .remove = qcom_osm_l3_remove,
+ .driver = {
+ .name = "osm-l3",
+ .of_match_table = osm_l3_of_match,
+ },
+};
+module_platform_driver(osm_l3_driver);
+
+MODULE_DESCRIPTION("Qualcomm OSM L3 interconnect driver");
+MODULE_LICENSE("GPL v2");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: [PATCH 1/2] Input: ili210x - Add DT binding for the Ilitek ILI2117 touch controller
From: Marek Vasut @ 2019-08-07 11:27 UTC (permalink / raw)
To: Rob Herring
Cc: linux-input, Dmitry Torokhov, Henrik Rydberg, Olivier Sobrie,
Philipp Puschmann, devicetree
In-Reply-To: <20190327194425.GA641@bogus>
On 3/27/19 8:44 PM, Rob Herring wrote:
> On Sat, 2 Mar 2019 15:17:03 +0100, Marek Vasut wrote:
>> Add DT binding for the Ilitek ILI2117 touch controller, which is yet
>> again a slightly different device in the ILI21xx family.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> Cc: Henrik Rydberg <rydberg@bitmath.org>
>> Cc: Olivier Sobrie <olivier@sobrie.be>
>> Cc: Philipp Puschmann <pp@emlix.com>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: devicetree@vger.kernel.org
>> To: linux-input@vger.kernel.org
>> ---
>> Documentation/devicetree/bindings/input/ilitek,ili2xxx.txt | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Bump ? I noticed these patches were never applied.
^ permalink raw reply
* Re: [PATCH 1/4] mailbox: arm_mhuv2: add device tree binding documentation
From: Tushar K @ 2019-08-07 11:32 UTC (permalink / raw)
To: Tushar Khandelwal
Cc: Sudeep Holla, Jassi Brar, Linux Kernel Mailing List,
morten_bp@live.dk, nd, Morten Petersen, Rob Herring, Mark Rutland,
Devicetree List
In-Reply-To: <998A97B0-D9D3-4F01-B5D4-56F875D38FC8@arm.com>
[-- Attachment #1: Type: text/plain, Size: 7885 bytes --]
Please ignore the disclaimers in the previous replies. This is a problem
with the server which I am looking into.
On Wed, 7 Aug 2019 at 12:17, Tushar Khandelwal <Tushar.Khandelwal@arm.com>
wrote:
>
>
> On 02/08/2019, 11:59, "Sudeep Holla" <sudeep.holla@arm.com> wrote:
>
> On Sun, Jul 21, 2019 at 04:58:04PM -0500, Jassi Brar wrote:
> > On Wed, Jul 17, 2019 at 2:26 PM Tushar Khandelwal
> > <tushar.khandelwal@arm.com> wrote:
> >
> > > diff --git
> a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
> b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
> > > new file mode 100644
> > > index 000000000000..3a05593414bc
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
> > > @@ -0,0 +1,108 @@
> > > +Arm MHUv2 Mailbox Driver
> > > +========================
> > > +
> > > +The Arm Message-Handling-Unit (MHU) Version 2 is a mailbox
> controller that has
> > > +between 1 and 124 channel windows to provide unidirectional
> communication with
> > > +remote processor(s).
> > > +
> > > +Given the unidirectional nature of the device, an MHUv2 mailbox
> may only be
> > > +written to or read from. If a pair of MHU devices is implemented
> between two
> > > +processing elements to provide bidirectional communication, these
> must be
> > > +specified as two separate mailboxes.
> > > +
> > > +A device tree node for an Arm MHUv2 device must specify either a
> receiver frame
> > > +or a sender frame, indicating which end of the unidirectional MHU
> device which
> > > +the device node entry describes.
> > > +
> > > +An MHU device must be specified with a transport protocol. The
> transport
> > > +protocol of an MHU device determines the method of data
> transmission as well as
> > > +the number of provided mailboxes.
> > > +Following are the possible transport protocol types:
> > > +- Single-word: An MHU device implements as many mailboxes as it
> > > + provides channel windows. Data is transmitted
> through
> > > + the MHU registers.
> > > +- Multi-word: An MHU device implements a single mailbox. All
> channel windows
> > > + will be used during transmission. Data is
> transmitted through
> > > + the MHU registers.
> > > +- Doorbell: An MHU device implements as many mailboxes as
> there are flag
> > > + bits available in its channel windows. Optionally,
> data may
> > > + be transmitted through a shared memory region,
> wherein the MHU
> > > + is used strictly as an interrupt generation
> mechanism.
> > > +
> > > +Mailbox Device Node:
> > > +====================
> > > +
> > > +Required properties:
> > > +--------------------
> > > +- compatible: Shall be "arm,mhuv2" & "arm,primecell"
> > > +- reg: Contains the mailbox register address range (base
> > > + address and length)
> > > +- #mbox-cells Shall be 1 - the index of the channel needed.
> > > +- mhu-frame Frame type of the device.
> > > + Shall be either "sender" or "receiver"
> > > +- mhu-protocol Transport protocol of the device. Shall be one of
> the
> > > + following: "single-word", "multi-word", "doorbell"
> > > +
> > > +Required properties (receiver frame):
> > > +-------------------------------------
> > > +- interrupts: Contains the interrupt information corresponding
> to the
> > > + combined interrupt of the receiver frame
> > > +
> > > +Example:
> > > +--------
> > > +
> > > + mbox_mw_tx: mhu@10000000 {
> > > + compatible = "arm,mhuv2","arm,primecell";
> > > + reg = <0x10000000 0x1000>;
> > > + clocks = <&refclk100mhz>;
> > > + clock-names = "apb_pclk";
> > > + #mbox-cells = <1>;
> > > + mhu-protocol = "multi-word";
> > > + mhu-frame = "sender";
> > > + };
> > > +
> > > + mbox_sw_tx: mhu@10000000 {
> > > + compatible = "arm,mhuv2","arm,primecell";
> > > + reg = <0x11000000 0x1000>;
> > > + clocks = <&refclk100mhz>;
> > > + clock-names = "apb_pclk";
> > > + #mbox-cells = <1>;
> > > + mhu-protocol = "single-word";
> > > + mhu-frame = "sender";
> > > + };
> > > +
> > > + mbox_db_rx: mhu@10000000 {
> > > + compatible = "arm,mhuv2","arm,primecell";
> > > + reg = <0x12000000 0x1000>;
> > > + clocks = <&refclk100mhz>;
> > > + clock-names = "apb_pclk";
> > > + #mbox-cells = <1>;
> > > + interrupts = <0 45 4>;
> > > + interrupt-names = "mhu_rx";
> > > + mhu-protocol = "doorbell";
> > > + mhu-frame = "receiver";
> > > + };
> > > +
> > > + mhu_client: scb@2e000000 {
> > > + compatible = "fujitsu,mb86s70-scb-1.0";
> > > + reg = <0 0x2e000000 0x4000>;
> > > + mboxes =
> > > + // For multi-word frames, client may only
> instantiate a single
> > > + // mailbox for a mailbox controller
> > > + <&mbox_mw_tx 0>,
> > > +
> > > + // For single-word frames, client may instantiate
> as many
> > > + // mailboxes as there are channel windows in the
> MHU
> > > + <&mbox_sw_tx 0>,
> > > + <&mbox_sw_tx 1>,
> > > + <&mbox_sw_tx 2>,
> > > + <&mbox_sw_tx 3>,
> > > +
> > > + // For doorbell frames, client may instantiate as
> many mailboxes
> > > + // as there are bits available in the combined
> number of channel
> > > + // windows ((channel windows * 32) mailboxes)
> > > + <mbox_db_rx 0>,
> > > + <mbox_db_rx 1>,
> > > + ...
> > > + <mbox_db_rx 17>;
> > > + };
> >
> > If the mhuv2 instance implements, say, 3 channel windows between
> > sender (linux) and receiver (firmware), and Linux runs two protocols
> > each requiring 1 and 2-word sized messages respectively. The hardware
> > supports that by assigning windows [0] and [1,2] to each protocol.
> > However, I don't think the driver can support that. Or does it?
> >
>
> FWIW, the IP is designed to cover wide range of usecase from IoT to
> servers
> with variable window length. I don't see the need to complicate the
> driver
> supporting mix-n-match at the cost of latency. Each platform choose one
> transport protocol for all it's use.
>
> The driver design is to address the most probable scenarios and not all.
> Single-word : Client gets one 32-bit window
> Doorbell : Client gets 32 data pointers (arm_message)
> Multi-word: Client gets all channels available in the platform.
>
> --Tushar
> --
> Regards,
> Sudeep
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
[-- Attachment #2: Type: text/html, Size: 10436 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: a64: Drop PMU node
From: Maxime Ripard @ 2019-08-07 11:56 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Jared D . McNeill, Chen-Yu Tsai,
Rob Herring, Harald Geyer, Robin Murphy, arm-linux
In-Reply-To: <CA+E=qVeAR4AFN99ZVy8EZLW6p_8ucTewOdMis37wnpV3DObaGg@mail.gmail.com>
On Tue, Aug 06, 2019 at 07:39:26PM -0700, Vasily Khoruzhick wrote:
> On Tue, Aug 6, 2019 at 2:14 PM Robin Murphy <robin.murphy@arm.com> wrote:
> >
> > On 2019-08-06 9:52 pm, Vasily Khoruzhick wrote:
> > > On Tue, Aug 6, 2019 at 1:19 PM Harald Geyer <harald@ccbib.org> wrote:
> > >>
> > >> Vasily Khoruzhick writes:
> > >>> On Tue, Aug 6, 2019 at 7:35 AM Robin Murphy <robin.murphy@arm.com> wrote:
> > >>>>
> > >>>> On 06/08/2019 15:01, Vasily Khoruzhick wrote:
> > >>>>> Looks like PMU in A64 is broken, it generates no interrupts at all and
> > >>>>> as result 'perf top' shows no events.
> > >>>>
> > >>>> Does something like 'perf stat sleep 1' at least count cycles correctly?
> > >>>> It could well just be that the interrupt numbers are wrong...
> > >>>
> > >>> Looks like it does, at least result looks plausible:
> > >>
> > >> I'm using perf stat regularly (cache benchmarks) and it works fine.
> > >>
> > >> Unfortunately I wasn't aware that perf stat is a poor test for
> > >> the interrupts part of the node, when I added it. So I'm not too
> > >> surprised I got it wrong.
> > >>
> > >> However, it would be unfortunate if the node got removed completely,
> > >> because perf stat would not work anymore. Maybe we can only remove
> > >> the interrupts or just fix them even if the HW doesn't work?
> > >
> > > I'm not familiar with PMU driver. Is it possible to get it working
> > > without interrupts?
> >
> > Yup - you get a grumpy message from the driver, it will refuse sampling
> > events (the ones which weren't working anyway), and if you measure
> > anything for long enough that a counter overflows you'll get wonky
> > results. But for counting hardware events over relatively short periods
> > it'll still do the job.
>
> I tried to drop interrupts completely from the node but 'perf top' is
> still broken. Though now in different way: it complains "cycles: PMU
> Hardware doesn't support sampling/overflow-interrupts. Try 'perf
> stat'"
I have no idea if that's the culprit, but what is the state of the
0x09010000 register?
(in particular, are the bits 16-19 and 24 set or not?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: a64: Drop PMU node
From: Robin Murphy @ 2019-08-07 11:59 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Jared D . McNeill, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Harald Geyer, arm-linux
In-Reply-To: <CA+E=qVeAR4AFN99ZVy8EZLW6p_8ucTewOdMis37wnpV3DObaGg@mail.gmail.com>
On 07/08/2019 03:39, Vasily Khoruzhick wrote:
> On Tue, Aug 6, 2019 at 2:14 PM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 2019-08-06 9:52 pm, Vasily Khoruzhick wrote:
>>> On Tue, Aug 6, 2019 at 1:19 PM Harald Geyer <harald@ccbib.org> wrote:
>>>>
>>>> Vasily Khoruzhick writes:
>>>>> On Tue, Aug 6, 2019 at 7:35 AM Robin Murphy <robin.murphy@arm.com> wrote:
>>>>>>
>>>>>> On 06/08/2019 15:01, Vasily Khoruzhick wrote:
>>>>>>> Looks like PMU in A64 is broken, it generates no interrupts at all and
>>>>>>> as result 'perf top' shows no events.
>>>>>>
>>>>>> Does something like 'perf stat sleep 1' at least count cycles correctly?
>>>>>> It could well just be that the interrupt numbers are wrong...
>>>>>
>>>>> Looks like it does, at least result looks plausible:
>>>>
>>>> I'm using perf stat regularly (cache benchmarks) and it works fine.
>>>>
>>>> Unfortunately I wasn't aware that perf stat is a poor test for
>>>> the interrupts part of the node, when I added it. So I'm not too
>>>> surprised I got it wrong.
>>>>
>>>> However, it would be unfortunate if the node got removed completely,
>>>> because perf stat would not work anymore. Maybe we can only remove
>>>> the interrupts or just fix them even if the HW doesn't work?
>>>
>>> I'm not familiar with PMU driver. Is it possible to get it working
>>> without interrupts?
>>
>> Yup - you get a grumpy message from the driver, it will refuse sampling
>> events (the ones which weren't working anyway), and if you measure
>> anything for long enough that a counter overflows you'll get wonky
>> results. But for counting hardware events over relatively short periods
>> it'll still do the job.
>
> I tried to drop interrupts completely from the node but 'perf top' is
> still broken. Though now in different way: it complains "cycles: PMU
> Hardware doesn't support sampling/overflow-interrupts. Try 'perf
> stat'"
>
> Is there any way to make it working?
As the message implies, 'perf top' can't work because it uses sampling
events, which are based on periodic interrupts. If the IRQs aren't
there, then too bad, as there's no alternative.
One other possibility is that the IRQs really are wired up, but the
firmware is somehow leaving them configured as Secure group 0, such that
Linux has no visibility of them.
Robin.
^ permalink raw reply
* Re: [PATCH v2 10/15] arm64: dts: imx8qm: add conn ss support
From: Oliver Graute @ 2019-08-07 12:04 UTC (permalink / raw)
To: Dong Aisheng
Cc: Mark Rutland, devicetree, dongas86, catalin.marinas, will.deacon,
robh+dt, linux-imx, kernel, fabio.estevam, shawnguo,
linux-arm-kernel
In-Reply-To: <1563290089-11085-11-git-send-email-aisheng.dong@nxp.com>
On 16/07/19, Dong Aisheng wrote:
> The CONN SS of MX8QM is mostly the same as MX8QXP except it has one more
> USB HSIC module support. So we can fully reuse the exist CONN SS dtsi.
> Add <soc>-ss-conn.dtsi with compatible string updated according to
> imx8-ss-conn.dtsi.
> +&usdhc1 {
> + compatible = "fsl,imx8qm-usdhc", "fsl,imx7d-usdhc";
> +};
> +
> +&usdhc2 {
> + compatible = "fsl,imx8qm-usdhc", "fsl,imx7d-usdhc";
> +};
I need to add here for my imx8qm-rom7720-a1 board:
&usdhc3 {
compatible = "fsl,imx8qm-usdhc", "fsl,imx7d-usdhc";
};
I'll prepare a patch for that on top of yours.
Best Regards,
Oliver
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: net: snps,dwmac: update reg minItems maxItems
From: Maxime Ripard @ 2019-08-07 12:04 UTC (permalink / raw)
To: Rob Herring
Cc: Neil Armstrong, Martin Blumenstingl, devicetree, netdev,
linux-amlogic,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_Jsq+6kCO8x53d1670VjgEjfs5opKY+R3OgsAo0WsXqq512Q@mail.gmail.com>
Hi,
On Tue, Aug 06, 2019 at 09:22:12AM -0600, Rob Herring wrote:
> +Maxime
>
> On Tue, Aug 6, 2019 at 6:50 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
> >
> > The Amlogic Meson DWMAC glue bindings needs a second reg cells for the
> > glue registers, thus update the reg minItems/maxItems to allow more
> > than a single reg cell.
> >
> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> > ---
> > Documentation/devicetree/bindings/net/snps,dwmac.yaml | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
>
> I haven't checked, but the derivative schema could be assuming this
> schema enforced reg is 1 item.
Yeah, we do for
Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
(but somehow not allwinner,sun8i-a83t-emac.yaml)
Neil, can you add it to sun7i-a20-gmac?
> I don't think that's a major issue
> though.
>
> Acked-by: Rob Herring <robh@kernel.org>
With that fixed,
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox